[infinispan-dev] Integrating Karsten's FCS

[Galder Zamarreño]

On Jul 9, 2013, at 11:07 AM, Radim Vansa <rvansa at redhat.com> wrote:

> 
> 
> ----- Original Message -----
> | From: "Galder Zamarreño" <galder at redhat.com>
> | To: "infinispan -Dev List" <infinispan-dev at 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.

^ 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.

> 
> | 
> | 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 at redhat.com
> | twitter.com/galderz
> | 
> | Project Lead, Escalante
> | http://escalante.io
> | 
> | Engineer, Infinispan
> | http://infinispan.org
> | 
> | 
> | _______________________________________________
> | infinispan-dev mailing list
> | infinispan-dev at lists.jboss.org
> | https://lists.jboss.org/mailman/listinfo/infinispan-dev
> | 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org