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

2013-06-10 Thread Dan Berindei
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 owned by threads. A separate lock command would acquire a lock

Re: [infinispan-dev] Infinispan Modularization

2013-06-10 Thread Tristan Tarrant
The Infinispan Modularization doc has received several updates, and I'd really like your opinion as soon as possible, since this work will start happening soon after 5.3 is branched. Thanks Tristan On 05/23/2013 01:40 PM, Tristan Tarrant wrote: > Dear all, > > I've written up some of the ideas

Re: [infinispan-dev] Suppressing state transfer via JMX

2013-06-10 Thread Dan Berindei
Erik, I think in your case you'd be better served by a ConsistentHashFactory that always assigns at most one owner from each machine for each segment. I guess the fix for ISPN-3140 should work as well, but it wouldn't be very straightforward: you'd have to keep the rebalancingEnabled attribute set

Re: [infinispan-dev] Suppressing state transfer via JMX

2013-06-10 Thread Manik Surtani
It didn't solve the issue for partial shutdown. And doesn't solve the issue for starting up nodes. You still have a mesh of messages attempting to coordinate the transfer of a null state. On 4 Jun 2013, at 10:44, Mircea Markus wrote: > Manik, what's wrong with Dan's suggestion with clearing

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

2013-06-10 Thread Manik Surtani
Agreed. It does sound pretty heavy. We should investigate a better implementation - the two approaches you suggest both sound good, could you create a JIRA for this? Adding infinispan-dev, that's the correct place to discuss this. Cheers Manik On 7 Jun 2013, at 13:39, Radim Vansa wrote: >

Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

2013-06-10 Thread Adrian Nistor
Maybe we could just clarify the javadoc of IGNORE_RETURN_VALUES and say that it only applies to write operations and is ignored for everything else? Why punish the user with an exception when doing a 'get'? We already document there's a (very common-sense) exception for conditional writes were

Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

2013-06-10 Thread Dan Berindei
On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang wrote: > On Jun 6, 2013, at 13:26, Mircea Markus wrote: > > > > > On 4 Jun 2013, at 13:55, Dan Berindei wrote: > > > CacheLoaderInterceptor and DistributionInterceptor both honour the > IGNORE_RETURN_VALUES flag for get commands, but I think it wou