3:32 a.m.
Hi,
I think we all agree that Karsten's file cache store is a good base replacement for
the current file cache store, particularly for caches with relatively small keys, or not a
huge amount of them.
I'm working with Radim to try to figure out what would be the tipping point at which
LevelDB based cache store behaves better compared to Karsten's cache store.
In the mean time, I think we should integrate Karsten's FCS into master and have it
ready for people to try from Alpha1. There's one or two things that do require a bit
of review, but I can pin point them in the pull req.
The question is, how should we name it? And what should we do about the current FCS
implementation?
Shall we keep the current FCS implementation, deprecate it, and get rid of it in the next
minor/major version? Some users might have data stored in the current FCS and would be
quite abrupt to just get rid of it right now.
If so, what do we name karsten's file cache store? AppendOnlyFileCacheStore?
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3:51 a.m.
hi,
On 07/09/2013 09:32 AM, Galder Zamarreño wrote:
+1 to have in Alpha1
The question is, how should we name it? And what should we do about the current FCS
implementation?
IMO, deprecate it in next Alpha and remove it in Final.
Also it would be better to create some tool to convert the files from
current FCS to the karsten's FCS.
If so, what do we name karsten's file cache store? AppendOnlyFileCacheStore?
not so good with names but KarstenFileCacheStore or
AppendOnlyFileCacheStore looks good to me...
Cheers,
Pedro
4:43 a.m.
On 9 Jul 2013, at 11:51, Pedro Ruivo <pedro(a)infinispan.org> wrote:
+1
the rolling upgrade functionality should have that already.
there's an @author tag
already in that file :-)
AppendOnlyFileCacheStore looks good to me...
or name it FileCacheStore but move it in another package, e.g.
org.infinispan.loaders.filestore
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
2:17 a.m.
On Jul 10, 2013, at 11:43 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
^ So, you're suggesting have two FileCacheStore classes? That sounds confusing, and
we're already have a package called org.infinispan.loaders.file.
I might just call it SingleFileCacheStore for the moment, since it uses a single file to
store all data.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:48 a.m.
On 11 Jul 2013, at 10:17, Galder Zamarreño <galder(a)redhat.com> wrote:
if the plan is to remote the old implementation entirely by the end of 6.0 then I
don't see a problem with having different packages.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10:54 a.m.
On Jul 11, 2013, at 11:48 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
Sure, but as I already indicated earlier, I don't see how you can remove it and still
do some kind of migration or rolling upgrade from one cache store to the other.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:07 a.m.
----- Original Message -----
| From: "Galder Zamarreño" <galder(a)redhat.com>
| To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
| Sent: Tuesday, July 9, 2013 10:32:52 AM
| Subject: [infinispan-dev] Integrating Karsten's FCS
|
| Hi,
|
| I think we all agree that Karsten's file cache store is a good base
| replacement for the current file cache store, particularly for caches with
| relatively small keys, or not a huge amount of them.
|
| I'm working with Radim to try to figure out what would be the tipping point
| at which LevelDB based cache store behaves better compared to Karsten's
| cache store.
|
| In the mean time, I think we should integrate Karsten's FCS into master and
| have it ready for people to try from Alpha1. There's one or two things that
| do require a bit of review, but I can pin point them in the pull req.
|
| The question is, how should we name it? And what should we do about the
| current FCS implementation?
|
| Shall we keep the current FCS implementation, deprecate it, and get rid of it
| in the next minor/major version? Some users might have data stored in the
| current FCS and would be quite abrupt to just get rid of it right now.
I'd remove it in Final, it cannot be seriously used either. Users can migrate the data
using rolling upgrades.
|
| If so, what do we name karsten's file cache store? AppendOnlyFileCacheStore?
You must have mixed something, Karsten is far from append-only, it writes to first big
enough empty space in the data file.
I'd emphasise that the keys are still in memory, therefore something like
InMemoryKeysFCS or MemKeysFCS. Or, we will not be as descriptive and call it HotFCS or
NextFCS...
|
| Cheers,
| --
| Galder Zamarreño
| galder(a)redhat.com
| twitter.com/galderz
|
| Project Lead, Escalante
| http://escalante.io
|
| Engineer, Infinispan
| http://infinispan.org
|
|
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/infinispan-dev
|
4:44 a.m.
+1 to integrate it.
Also, +1 on Radim's comment to remove the existing one: just yesterday
I had a problem with Infinispan blowing up with weird Externalizer
exceptions because I was attempting to activate data from a
FilesystemCacheStore which was stored with version 5.2.x, and I was
loading it from 5.3.0 : that doesn't work as apparently some encoding
changed, so unless we want to fix that there is no point in keeping
the existing CacheStore around.
Sanne
On 9 July 2013 10:07, Radim Vansa <rvansa(a)redhat.com> wrote:
4:58 a.m.
On 9 Jul 2013, at 12:44, Sanne Grinovero <sanne(a)infinispan.org> wrote:
I wonder why's that..might have to do with the change in the InternalCacheEntrie's
implementation, including serialization format (Metadata..CacheEntry). Do you have a stack
trace for that?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
8:37 a.m.
On Jul 9, 2013, at 4:07 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
Can you describe this process, especially for how it can be accomplished with a single
(local) cache?
A migration mechanism is absolutely a must. There are ModeShape users that have used the
FCS simply because it suits their needs - primarily because there are no extra
dependencies and no additional "system" underneath. There HAS to be a migration
path, especially if the old FCS is going to be removed.
Why does Infinispan not have a general-purpose mechanism for converting from one (offline)
cache store to another (offline) cache store?
8:44 a.m.
Hi Randall,
I would agree with you that this should be a priority, but keep in
mind that just migrating data from a CacheStore to another won't be
enough: as I pointed out in my previous mail, binary encoding also
changed, making it impossible to deserialize the values.
I'm not sure if the encoding change was meant to happen, but
apparently there is currently no effort in place to test for this kind
of backward compatibility.
If you need such a thing for ModeShape it would likely be easier for
you to provide such a tool in ModeShape to extract all data and dump
it to some external file, than to provide the hooks in Infinispan as
the transcoding tool would need to depend on multiple Infinispan
versions.
Sanne
On 9 July 2013 14:37, Randall Hauch <rhauch(a)redhat.com> wrote:
9:20 a.m.
ModeShape does have a backup/restore feature that scans the whole contents of a repository
to a file system, which later can be read back in to populate an empty installation.
I'm just surprised that Infinispan doesn't provide or want to provide something
like this out-of-the-box.
Also, is it just me, or does KFCS remind me of fried chicken? (Get it, KFCS … KFC Store …
fried chicken. :-)
On Jul 9, 2013, at 8:44 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
5:07 a.m.
On 9 Jul 2013, at 16:44, Sanne Grinovero <sanne(a)infinispan.org> wrote:
We should really see what has happened there Sanne, thanks for the heads up.
Ideally we should preserver backward compatibility for same store implementations, or if
we don't document it and provide the tooling for allow users to upgrade. Galder
something to look at together with the tooling for migrating data between FCS impls
perhaps?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
2:18 a.m.
On Jul 10, 2013, at 12:07 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
^ That sounds very coarse grained to me. This kind of upgrade from a cache store to
another should be something we should cover in the rolling upgrades, and not as part of a
cache store specific migration kit, thoughts?
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
2:22 a.m.
On Jul 11, 2013, at 9:18 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
s/coarse/fine
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:51 a.m.
On 11 Jul 2013, at 10:18, Galder Zamarreño <galder(a)redhat.com> wrote:
In Sanne's case it is from the same cache store between different infinispan
versions.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:11 a.m.
On Jul 11, 2013, at 11:51 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
http://issues.jboss.org/browse/ISPN-3318
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
1:24 a.m.
----- Original Message -----
| From: "Randall Hauch" <rhauch(a)redhat.com>
| To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
| Sent: Tuesday, July 9, 2013 3:37:36 PM
| Subject: Re: [infinispan-dev] Integrating Karsten's FCS
|
|
| On Jul 9, 2013, at 4:07 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
|
| > ----- Original Message -----
| > | From: "Galder Zamarreño" <galder(a)redhat.com>
| > | Shall we keep the current FCS implementation, deprecate it, and get rid
| > | of it
| > | in the next minor/major version? Some users might have data stored in the
| > | current FCS and would be quite abrupt to just get rid of it right now.
| >
| > I'd remove it in Final, it cannot be seriously used either. Users can
| > migrate the data using rolling upgrades.
|
| Can you describe this process, especially for how it can be accomplished with
| a single (local) cache?
You're right, after looking into rolling upgrades I've realized that in order to
do so the cache would have to be accessible via HotRod (currently). ISPN-2637 and
ISPN-2638 should allow rolling upgrades for Memcached and REST as well - I hope that these
in cooperation with inter-client compatibility will allow library-mode rolling upgrades as
well.
Still, I'd prefer any migration to happen via rolling upgrades over some custom
cache-store migration, if that would be possible.
Radim
|
| A migration mechanism is absolutely a must. There are ModeShape users that
| have used the FCS simply because it suits their needs - primarily because
| there are no extra dependencies and no additional "system" underneath. There
| HAS to be a migration path, especially if the old FCS is going to be
| removed.
|
| Why does Infinispan not have a general-purpose mechanism for converting from
| one (offline) cache store to another (offline) cache store?
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/infinispan-dev
|
5:08 a.m.
On 10 Jul 2013, at 09:24, Radim Vansa <rvansa(a)redhat.com> wrote:
+1. Curious to see Tristan's thoughts on this :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:18 a.m.
This is the requested stacktrace; it's easy to reproduce in case you need it:
- checkout Hibernate Search at tag 4.3.0.Final and run
org.hibernate.search.infinispan.StoredIndexTest
- switch to commit id dfc8bff and run the same test again
Cheers,
Sanne
org.hibernate.search.SearchException: HSEARCH000103: Unable to
initialize IndexManager emails
at
org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
at
org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:101)
at
org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:413)
at
org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
at
org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
at
org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
at
org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1769)
at
org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:181)
at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:132)
at
org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.infinispan.CacheException:
org.infinispan.loaders.CacheLoaderException: Error while reading from
file
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:351)
at org.infinispan.CacheImpl.get(CacheImpl.java:391)
at org.infinispan.DecoratedCache.get(DecoratedCache.java:415)
at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:66)
at org.infinispan.lucene.InfinispanDirectory.list(InfinispanDirectory.java:168)
at org.infinispan.lucene.InfinispanDirectory.listAll(InfinispanDirectory.java:328)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:602)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
at
org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
at
org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
at
org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
at
org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:226)
... 36 more
Caused by: org.infinispan.loaders.CacheLoaderException: Error while
reading from file
at org.infinispan.loaders.file.FileCacheStore.loadBucket(FileCacheStore.java:311)
at org.infinispan.loaders.file.FileCacheStore.loadBucket(FileCacheStore.java:280)
at
org.infinispan.loaders.bucket.BucketBasedCacheStore.loadLockSafe(BucketBasedCacheStore.java:60)
at
org.infinispan.loaders.bucket.BucketBasedCacheStore.loadLockSafe(BucketBasedCacheStore.java:49)
at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:142)
at
org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:189)
at
org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:263)
at
org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:122)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
at
org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:119)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
at
org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:57)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
at
org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:96)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
at
org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:113)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
at
org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:96)
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
... 49 more
Caused by: org.infinispan.CacheException: Type of data read is
unknown. Id=-2147482348 is not amongst known reader indexes.
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222)
at
org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at
org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:173)
at
org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:164)
at
org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:412)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:228)
at
org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.loaders.bucket.Bucket$Externalizer.readObject(Bucket.java:170)
at org.infinispan.loaders.bucket.Bucket$Externalizer.readObject(Bucket.java:146)
at
org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:412)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:228)
at
org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at
org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:163)
at
org.infinispan.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:191)
at
org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromObjectStream(AbstractDelegatingMarshaller.java:79)
at
org.infinispan.loaders.file.FileCacheStore.objectFromInputStreamInReentrantMode(FileCacheStore.java:433)
at org.infinispan.loaders.file.FileCacheStore.loadBucket(FileCacheStore.java:306)
... 76 more
On 10 July 2013 11:08, Mircea Markus <mmarkus(a)redhat.com> wrote:
2:14 a.m.
I've created a JIRA: https://issues.jboss.org/browse/ISPN-3311
On Jul 10, 2013, at 1:18 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
5:03 a.m.
On 9 Jul 2013, at 16:37, Randall Hauch <rhauch(a)redhat.com> wrote:
+1.
There hasn't been a lot of demand for this: the last time I remember having this
problem was when re-implementing the JDBC store for JBossCache in 2007 :-) I think users
don't generally switch the cache store implementation and generally cache stores are
backward compatible. At least up to Infinispan 5.3.0 as per Sanne's email.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
2:22 a.m.
On Jul 9, 2013, at 11:07 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
^ I don't think you can remove it in 6.0 Final. If you wanna do any kind of migration
or rolling upgrade from the curren FCS to the new one, you need to have the current FCS
around, to be able to read data in that format/setup and then write it to the new cache
store. The moment you can remove it is the moment you've decided that no more
migrations are gonna happen.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:53 a.m.
On 11 Jul 2013, at 10:22, Galder Zamarreño <galder(a)redhat.com> wrote:
You can have the logic around but don't expose it to the users as a shipped cache
store. E.g. move it to a different package and rename it to whatever you want.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
5:14 a.m.
Thanks Galder for opening the JIRA; but I wonder if we actually have a way out.
5.3.0.Final was released already, so if you want to "fix" its format
to be compatible with 5.2 in a minor patch version - probably 5.3.1 -
then that would break compatibility with 5.3.0 which is maybe even
worse.
Probably the lesser evil is to clearly warn about this and suggest an
external dump; this way we also save some work as we could drop the
existing CacheStore implementation and move on.. the saved dev time
could be spent on tests to make sure this problem won't occur again as
it clearly is a major problem if it slips into a released version
without being spotted on time.
Cheers,
Sanne
On 11 July 2013 10:53, Mircea Markus <mmarkus(a)redhat.com> wrote:
11:26 a.m.
New subject: Keeping formats compatible
Too many paralell discussions in this email thread… changing title…
On Jul 11, 2013, at 12:14 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
Hold on till we've figured out the cause… and if you're a rigt, a potential fix
could be investigated to make 5.3.0 and 5.3.1 compatible...
When we started investigating rolling upgrades we played with the idea of having a
serialized format that's readable between different versions and we created [1]. I
actually created some branches to investigate the feasibility of adding such tests: [2, 3,
4, 5, 6], and of course found incompatibilities. This idea was abandoned and instead we
decided on a Hot Rod based mechanism to transfer the data from one cluster to the other.
Such tests could be added, but there needs to be a limit on how far we want to be
backwards compatible with. IOW, trying for Infinispan 5.3 to be backwards compatible with
4.0 would be a lot of work. The minimum req would possibly be that we're backwards
compatible between minors.
This is something we can try to start imposing from 6.0 onwards. It's a good moment to
start doing it, at the beginning of a major release.
[1] https://issues.jboss.org/browse/ISPN-2034
[2] https://github.com/galderz/infinispan/tree/archive/t_2034_40x
[3] https://github.com/galderz/infinispan/tree/archive/t_2034_41x
[4] https://github.com/galderz/infinispan/tree/archive/t_2034_42x
[5] https://github.com/galderz/infinispan/tree/archive/t_2034_50x
[6] https://github.com/galderz/infinispan/tree/archive/t_2034_51x
Cheers,
Sanne
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
11:58 a.m.
New subject: Keeping formats compatible
On 11 July 2013 17:26, Galder Zamarreño <galder(a)redhat.com> wrote:
Too many paralell discussions in this email thread… changing title…
+1
Right.
That was my understanding as well, and why I suggest to not give too
much importance to the CacheStore: we somehow agreed that this wasn't
expected to work. To be clear, I was not agreeing on that but since
that was the consensus based on what we can practically do I'm just
sticking to it now: we decided it would be incompatible.
+1 If we make this as an external tool released with each version to
migrate from the previous version, then people can "chain" them up to
migrate across longer version gaps. This could eventually evolve in a
set of helper scripts which help migrate from any version (since we
start this practice) to any other version.
This is something we can try to start imposing from 6.0 onwards. It's a good moment
to start doing it, at the beginning of a major release.
+1 Which again implies dropping older version's compatibility.
Cheers,
Sanne
8:41 a.m.
On Jul 11, 2013, at 4:53 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
Let's look at this from a user's perspective. Is it possible that the new file
store **replaces** the old one, so that the user doesn't (really) need to know the
difference?
How similar are the configuration properties of each? Might it be possible to:
rename and deprecate the existing one (e.g.,
"org.infinispan.loaders.file.LegacyFileCacheStore"), changing it to
'package' or 'protected' (iff the new one is stable enough that the old
one should definitely not be used anymore),
rename the new one to "org.infinispan.loaders.file.FileCacheStore" (so that
existing configurations work without change),
have some code in the new one detect the old file structure and automatically run a
migration to convert from the old file structure to the new format (and possibly move the
old files into a subdirectory)
If this is possible, this is by far the best option for users since it provides a simple
(perhaps even transparent) migration path with little if any changes required to
configurations, but at the same time it allows the developers to get what they want: a new
FCS that replaces the old one (which goes away).
11:31 a.m.
On Jul 11, 2013, at 3:41 PM, Randall Hauch <rhauch(a)redhat.com> wrote:
Interesting idea. I'm adding it to https://issues.jboss.org/browse/ISPN-3318
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
11:14 a.m.
On Jul 11, 2013, at 11:53 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
That's even more confusing cos it means that a configuration that is valid previously
will no longer be (particularly in those scenarios where people have defined the full FCS
class name in the configuration) without extra code. Much simpler to leave FCS around and
remove it in 6.1.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4280
days inactive
4282
days old
infinispan-dev@lists.jboss.org
29 comments
6 participants
participants (6)
-
Galder Zamarreño -
Mircea Markus -
Pedro Ruivo -
Radim Vansa -
Randall Hauch -
Sanne Grinovero