[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

Re: [infinispan-dev] Integrating Karsten's FCS

hi, On 07/09/2013 09:32 AM, Galder Zamarreño wrote: > 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

Re: [infinispan-dev] Integrating Karsten's FCS

- Original Message - | From: "Galder Zamarreño" | To: "infinispan -Dev List" | 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 fi

Re: [infinispan-dev] Integrating Karsten's FCS

+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 f

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 15:40, Manik Surtani wrote: > On 19 Jun 2013, at 14:34, Pedro Ruivo wrote: > >> >> I don't think so. We should only query the L1DC just before performing >> the remote get. This way, only the DistributionInterceptor (and >> sub-classes) will keep a reference to L1DC to qu

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 17:56, Sanne Grinovero wrote: > On 19 June 2013 16:44, cotton-ben wrote: >> >> />>At the opposite site, I don't see how - as a user - I could optimally tune a separate container. >> >>> I agree that is more difficult to configure, this was one of my points as >>>

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 16:19, Sanne Grinovero wrote: > On 19 June 2013 13:44, William Burns wrote: >> All the L1 data for a DIST cache is stored in the same data container as the >> actual distributed data itself. I wanted to propose breaking this out so >> there is a separate data container for t

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 17:28, William Burns wrote: > > > > On Wed, Jun 19, 2013 at 10:19 AM, Sanne Grinovero > wrote: > On 19 June 2013 13:44, William Burns wrote: > > All the L1 data for a DIST cache is stored in the same data container as the > > actual distributed data itself. I wanted to

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 16:43, Sanne Grinovero wrote: > On 19 June 2013 15:35, cotton-ben wrote: >> / Benefits: 1. L1 cache can be separately tuned - L1 maxEntries for example >> >>> -1! >>> I don't think thats a benefit actually, from the point of view of a user: >>> [...] >>> At the opp

Re: [infinispan-dev] Add another dependency?

Does it come with other indirect dependencies or is just that? On 2 Jul 2013, at 16:18, Galder Zamarreño wrote: > If it's in a separate module, I'm fine with it. +1. > > I'll comment on specifics about the stats in the pull req... Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)

Re: [infinispan-dev] Appending to file

On 28 Jun 2013, at 17:16, Radim Vansa wrote: > Hi, > > I was playing with efficient ways to write to append-only log and I have some > results below. This sounds a lot like what the loggers do, might be worth looking at some FileAppender impls for inspiration ;) > > I've used three impleme

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 20:49, Sanne Grinovero wrote: > On 19 June 2013 19:00, Dan Berindei wrote: >> >> >> >> On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero >> wrote: >>> >>> On 19 June 2013 13:44, William Burns wrote: All the L1 data for a DIST cache is stored in the same data contain

Re: [infinispan-dev] RELAY2 using shorts as site-ids

On 1 Jul 2013, at 16:33, Bela Ban wrote: > This is re [1]. > > I want to replace shorts as site-ids with strings. This would make EAP > and JDG configuration simpler, as both configure the mapping from site > string (e.g. "sfo") to ID (e.g. 1) on the fly. If we have sites sfo, lon > and nyc

Re: [infinispan-dev] MongoDB cachestore 5.3.0.Final now in jboss maven repo

Thanks for updating the release doc :-) On 5 Jul 2013, at 10:02, Tristan Tarrant wrote: > Dearl all, > > I have released to maven the missing MongoDB cachestore for 5.3.0.Final. > I have not re-released the zip distributions to avoid confusion, but > let's make sure it is included in future r

Re: [infinispan-dev] L1 Data Container

On 19 Jun 2013, at 19:27, Sanne Grinovero wrote: > On 19 June 2013 17:17, William Burns wrote: >> >> >> >> On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero >> wrote: >>> >>> On 19 June 2013 16:44, cotton-ben wrote: />>At the opposite site, I don't see how - as a user - I c

Re: [infinispan-dev] protobuf as a marshalling format for infinispan remote-query

On 28 Jun 2013, at 20:39, Manik Surtani wrote: > > On 28 Jun 2013, at 19:33, Adrian Nistor wrote: > >> And finally, if anyone could suggest a better name for the stream-like >> package? I can't think of any other option except streamlike :) (which might >> be trade-marked) So any other opti

Re: [infinispan-dev] New bundler performance

Indeed adding the DONT_BUNDLE flag back and using the new bundler yielded the same performance as the old setup. Interesting enough, using the DONT_BUNDLE + old bundler made performance not look good. Radim can provide the exact numbers. On 25 Jun 2013, at 16:37, Bela Ban wrote: > So the new

Re: [infinispan-dev] RemoteCache vs BasicCache

TBH I think having the RemoteCache implementing Cache wasn't such a good idea as it caused confusion through users: e.g. people trying to use transactions with a remote cache. I like the multiple interfaces idea as it clearly indicates what's actually supported in both remote and embedded modes.

Re: [infinispan-dev] protobuf as a marshalling format for infinispan remote-query

On 1 Jul 2013, at 09:29, Emmanuel Bernard wrote: > Ah it's quite sad protostuff does not live up to the expectation :( > > Compared to the google libs, streamlike is definitely a nice approach but I > feel a bit sad to have to use marshallers and the read/write pattern. Having > maintained co

Re: [infinispan-dev] [infinispan-internal] PutMapCommand is ineffective

On 10 Jun 2013, at 17:30, Dan Berindei wrote: > Yes, putAll is really heavy in non-tx (concurrent) mode, because the same > PutMapCommand is forwarded from each primary owner to all the backup owners > of the keys it primary-owns. However, I don't think > > However, in non-tx mode locks are

Re: [infinispan-dev] Cachestores performance

On 2 Jul 2013, at 19:39, Erik Salter wrote: > I concur with part of the below, but with a few changes: > > - The cache is the primary storage, similar to Sanne's case. (DIST mode) > - My customers are not interested in extra components to the system, like > databases or Cassandra nodes. They

Re: [infinispan-dev] configuring fetchInMemoryState for topology caches

On 21 May 2013, at 17:09, Dan Berindei wrote: > I wouldn't want to deprecate CCL, I think it definitely has a purpose - at > least in invalidation mode. The only use case I'm aware of for invalidation is 2nd level cache and I don't think that needs a remote cache, Galder wdyt? > > Even in rep

Re: [infinispan-dev] [infinispan-internal] LevelDB performance testing

On 24 Jun 2013, at 13:56, Radim Vansa wrote: > - Original Message - > | From: "Galder Zamarreño" > | To: "Radim Vansa" > | Cc: "infinispan -Dev List" > | Sent: Monday, June 24, 2013 12:46:52 PM > | Subject: Re: [infinispan-internal] LevelDB performance testing > | > | Putting Infinis

Re: [infinispan-dev] Cachestores performance

On 2 Jul 2013, at 15:32, Radim Vansa wrote: > | Given such a scenario, I am not interested at all in synchronous > | storage. Before we commit into a design which is basically assuming > | the need for synchronous storage guarantees, I'd like to understand > | what kind of use case it's aiming t

Re: [infinispan-dev] RemoteCache vs BasicCache

On 8 July 2013 20:37, Mircea Markus wrote: > TBH I think having the RemoteCache implementing Cache wasn't such a good idea > as it caused confusion through users: e.g. people trying to use transactions > with a remote cache. I like the multiple interfaces idea as it clearly > indicates what's a

Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 Jul 2013, at 13:15, Sanne Grinovero wrote: > On 8 July 2013 20:37, Mircea Markus wrote: >> TBH I think having the RemoteCache implementing Cache wasn't such a good >> idea as it caused confusion through users: e.g. people trying to use >> transactions with a remote cache. I like the mult

Re: [infinispan-dev] Isolation level in Repeatable Read + remote get

On Jul 8, 2013, at 11:02 AM, Pedro Ruivo wrote: > Hi guys, > > re: ISPN-2840, ISPN-3235, ISPN-3236 > short: transaction isolation in repeatable read > > Dan came up with an idea (a good idea IMO) to change a little the logic > how entries are put in the context for transactional caches. > >

Re: [infinispan-dev] RemoteCache vs BasicCache

Indeed that's an excellent idea. But I would add also a common parent interface having the basic functionality common to all. On 9 July 2013 11:39, Mircea Markus wrote: > > On 9 Jul 2013, at 13:15, Sanne Grinovero wrote: > >> On 8 July 2013 20:37, Mircea Markus wrote: >>> TBH I think having the

Re: [infinispan-dev] Isolation level in Repeatable Read + remote get

On 07/09/2013 11:46 AM, Galder Zamarreño wrote: > > On Jul 8, 2013, at 11:02 AM, Pedro Ruivo wrote: > >> Hi guys, >> >> re: ISPN-2840, ISPN-3235, ISPN-3236 >> short: transaction isolation in repeatable read >> >> Dan came up with an idea (a good idea IMO) to change a little the logic >> how entr

Re: [infinispan-dev] protobuf as a marshalling format for infinispan remote-query

On 8 juil. 2013, at 21:06, Mircea Markus wrote: > > On 1 Jul 2013, at 09:29, Emmanuel Bernard wrote: > >> Ah it's quite sad protostuff does not live up to the expectation :( >> >> Compared to the google libs, streamlike is definitely a nice approach but I >> feel a bit sad to have to use m

Re: [infinispan-dev] New bundler performance

On 7/8/13 7:32 PM, Mircea Markus wrote: > Indeed adding the DONT_BUNDLE flag back and using the new bundler yielded the > same performance as the old setup. That's bad, we should look into it ! I get exactly the same or even better performance with the new bundler and DONT_BUNDLE removed. > I

Re: [infinispan-dev] Integrating Karsten's FCS

On Jul 9, 2013, at 4:07 AM, Radim Vansa wrote: > - Original Message - > | From: "Galder Zamarreño" > | 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

Re: [infinispan-dev] Cachestores performance

On Jul 8, 2013, at 3:03 PM, Mircea Markus wrote: > > On 2 Jul 2013, at 19:39, Erik Salter wrote: > >> I concur with part of the below, but with a few changes: >> >> - The cache is the primary storage, similar to Sanne's case. (DIST mode) >> - My customers are not interested in extra componen

Re: [infinispan-dev] Integrating Karsten's FCS

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 encodin

Re: [infinispan-dev] Integrating Karsten's FCS

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 j

Re: [infinispan-dev] L1 consistency for transactional caches.

On Mon, Jul 8, 2013 at 12:19 AM, Sanne Grinovero wrote: > On 3 July 2013 10:26, Dan Berindei wrote: > > > > > > > > On Tue, Jul 2, 2013 at 8:41 PM, Sanne Grinovero > > wrote: > >> > >> On 2 July 2013 17:24, Dan Berindei wrote: > >> > It's not wrong, sending the invalidation only from the primar

Re: [infinispan-dev] Isolation level in Repeatable Read + remote get

fine by me :) On 07/09/2013 05:44 PM, Dan Berindei wrote: > Pedro, I'll integrate the PR as it is, and then you can experiment with > my proposal in another branch/PR. > > > On Tue, Jul 9, 2013 at 1:48 PM, Pedro Ruivo > wrote: > > > > On 07/09/2013 11:46 AM, Galde

Re: [infinispan-dev] Isolation level in Repeatable Read + remote get

Pedro, I'll integrate the PR as it is, and then you can experiment with my proposal in another branch/PR. On Tue, Jul 9, 2013 at 1:48 PM, Pedro Ruivo wrote: > > > On 07/09/2013 11:46 AM, Galder Zamarreño wrote: > > > > On Jul 8, 2013, at 11:02 AM, Pedro Ruivo wrote: > > > >> Hi guys, > >> > >>

Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 July 2013 18:01, Mircea Markus wrote: > > On 9 Jul 2013, at 13:47, Sanne Grinovero wrote: > >> Indeed that's an excellent idea. But I would add also a common parent >> interface having the basic functionality common to all. > > If ConcurrentMap doesn't have what we need, of course :-) Concu

Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 Jul 2013, at 13:47, Sanne Grinovero wrote: > Indeed that's an excellent idea. But I would add also a common parent > interface having the basic functionality common to all. If ConcurrentMap doesn't have what we need, of course :-) > > On 9 July 2013 11:39, Mircea Markus wrote: >> >> On

Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 Jul 2013, at 20:07, Sanne Grinovero wrote: > On 9 July 2013 18:01, Mircea Markus wrote: >> >> On 9 Jul 2013, at 13:47, Sanne Grinovero wrote: >> >>> Indeed that's an excellent idea. But I would add also a common parent >>> interface having the basic functionality common to all. >> >> I

Re: [infinispan-dev] L1 Data Container

/> This would only affect the Cache internals (use two DataContainers instead of one). Users still won't have direct access to the L1 cache. / This comment prompts me to ask the Infinispan DEV team if they believe the following potential user API additions have merit: Given that a user's DIST_SY

Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 July 2013 18:13, Mircea Markus wrote: > > On 9 Jul 2013, at 20:07, Sanne Grinovero wrote: > >> On 9 July 2013 18:01, Mircea Markus wrote: >>> >>> On 9 Jul 2013, at 13:47, Sanne Grinovero wrote: >>> Indeed that's an excellent idea. But I would add also a common parent interface ha

Re: [infinispan-dev] Integrating Karsten's FCS

- Original Message - | From: "Randall Hauch" | To: "infinispan -Dev List" | 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 wrote: | | > - Original Message - | > | From: "Galder Zam