Re: [infinispan-dev] Stale locks: stress test for the ReplaceCommand
On 30 Oct 2012, at 14:00, Sanne Grinovero sa...@infinispan.org wrote: Funnily enough while writing this it just failed a run even in single thread mode: in one iteration it was spotted that the lock wasn't cleaned up; this was REPL_SYNC+TX; I find this particularly concerning, but also potentially easy to debug. Do you have TRACE logs from this run? And I presume this is on master, with the fix for ISPN-2381 in? Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Transaction table cleanup
On 12-10-29 8:49 PM, Manik Surtani wrote: On 19 Oct 2012, at 17:40, Mircea Markus mircea.mar...@jboss.com mailto:mircea.mar...@jboss.com wrote: On 19 Oct 2012, at 07:41, Vladimir Blagojevic wrote: On 12-10-19 4:15 AM, Manik Surtani wrote: You're right actually, the temporary cache created is transactional. it is built in the CreateCacheCommand and relies on the DummyTransactionManager, might be better to use batching perhaps? Or even not require for this cache to be transactional? Yes, we should keep such internal caches as simple as possible. Mircea/Manik, it could be batch I believe. If you recall Mircea, you and I talked about how to effectively move data across cluster deadlock free - we even agreed we should blog post about it :-) https://issues.jboss.org/browse/ISPN-2156 Mircea/Manik could I get some advice and code review for MapReduceManagerImpl#combine? Thanks Vladimir. The only change to make is CreateCacheCommand.create, configure the cache to be batchable[1]. Then in the MapReduceManagerImpl#combine, don't use the TransactionManager.beggin/commit but the batch API. Is this in? Have we redone M/R not to rely on transactions and instead to use batching yet? Vladimir? Manik, not yet. I am done with cancellation now and I am moving onto this one. I've tried it over the weekend and it still deadlocks from time to time as described here https://issues.jboss.org/browse/ISPN-2439 This was not the case before (no changes whatsoever to m/r codebase) and I requested Mircea's help here. We'll convert it to batches and see to make sure these deadlocks do not occur. Vladimir ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Stale locks: stress test for the ReplaceCommand
So the fix for ISPN-2381 is not complete? On 30 Oct 2012, at 14:09, Manik Surtani wrote: On 30 Oct 2012, at 14:00, Sanne Grinovero sa...@infinispan.org wrote: Funnily enough while writing this it just failed a run even in single thread mode: in one iteration it was spotted that the lock wasn't cleaned up; this was REPL_SYNC+TX; I find this particularly concerning, but also potentially easy to debug. Do you have TRACE logs from this run? And I presume this is on master, with the fix for ISPN-2381 in? Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Stale locks: stress test for the ReplaceCommand
Yes I was running on master as of 5cf3494a3ccd59eb7675c2caff4a7f0b75f244c5 It's trivial to cherry-pick the test where you want, as I didn't change any code and it just adds the single file needed for the test. I don't have TRACE logs enabled, no; you're very welcome to run it in all modes you want. On 30 October 2012 14:29, Mircea Markus mircea.mar...@jboss.com wrote: So the fix for ISPN-2381 is not complete? That's unclear, there might be multiple subtle problems going on. ISPN-2381 might be resolved, seems there are more issues of similar nature. This test started as a testcase for ISPN-2435 (also quite critical imho), but now I'll track this new locking problem separately: ISPN-2453 Cheers, Sanne On 30 Oct 2012, at 14:09, Manik Surtani wrote: On 30 Oct 2012, at 14:00, Sanne Grinovero sa...@infinispan.org wrote: Funnily enough while writing this it just failed a run even in single thread mode: in one iteration it was spotted that the lock wasn't cleaned up; this was REPL_SYNC+TX; I find this particularly concerning, but also potentially easy to debug. Do you have TRACE logs from this run? And I presume this is on master, with the fix for ISPN-2381 in? Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] iOS client lib
any interest? Otherwise I will keep it my personal github repo -M On Mon, Oct 29, 2012 at 10:22 AM, Matthias Wessendorf mat...@apache.org wrote: HEllo, For a WebSocket demo, I created the following iOS lib (basically a port of the infinispan-ws.js file) https://github.com/matzew/infinispan-ios. I was wondering if there is interest in moving that project over to the umbrella infinispan repo at github. Thx, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Fixing ISPN-2384 (data loss with concurrent activation/passivation)
Hi all, Re: https://issues.jboss.org/browse/ISPN-2384 I've created a unit test in https://github.com/galderz/infinispan/commit/01230d40df6f26720039986916c38de8be33b44b That was the easy part :). How to fix it is no so clear. In pseudo-code, the race condition happens when: 1. T1. passivate entry X to cache store 2. T2. retrieve X from memory 3. T2. activation interceptor removes X from store 4. T1. evicts X from memory The end result is that X is gone from both memory and cache store. I've thought of several ways of fixing it, but not convinced with any: One way to fix this is by making step 1 4 atomic, and I was hoping to pigyback on the segment lock, but for that to work, step 2 (data container get() op) would need to wait for this segment lock, which would be detrimental for performance. Another way would be if activation only happened if the data was retrieved from the cache store (and not from memory) since removing from cache store when the value came from memory is rather pointless. The problem with this solution is that the source of the data is not currently ship around in the interceptor stack. IOW, the activation interceptor doesn't know if the data came from memory or the cache store. This could be potentially recorded in the cache entry stored in the context, but requires some refactoring and it could still be vunerable to this sequence of events: 1. T1. passivate entry X to cache store 2. T2. retrieve X from cache store 3. T2. store X in memory 4. T2. activation interceptor removes X from store 5. T1. evicts X from memory So, to get around this sequence of events, since the the store acquires a segment lock, passivate and evict X could be done within the segment lock, and that would make sure that the evict happens before the storage in memory: 1. T1. acquire segment lock 2. T1. passivate entry X to cache store 3. T2. retrieve X from cache store 4. T1. evicts X from memory 5. T1. releases segment lock 6. T2. acquires segment lock 7. T2. store X in memory 8. T2. activation interceptor removes X from store 9. T2. releases segment lock I think this could work, but I was wondering if you could see other potential solutions? Cheers, -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] iOS client lib
Hey, I'll try and channel the team as they are busy on too many fronts these days. The contribution looks cool. I am not sure what is the strategy going to be on the various clients. Hosted under the Infinispan org or left separate. My guess is hosting in the org makes more sense. Can you open a JIRA and point to your work. That will make sure things are not forgotten in the grand email black hole. Emmanuel On 30 oct. 2012, at 18:30, Matthias Wessendorf mat...@apache.org wrote: any interest? Otherwise I will keep it my personal github repo -M On Mon, Oct 29, 2012 at 10:22 AM, Matthias Wessendorf mat...@apache.org wrote: HEllo, For a WebSocket demo, I created the following iOS lib (basically a port of the infinispan-ws.js file) https://github.com/matzew/infinispan-ios. I was wondering if there is interest in moving that project over to the umbrella infinispan repo at github. Thx, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Infinispan 5.2.0.Beta3 is out!
Hopefully the last Beta of the 5.2 series, it contains a set of critical bug fixes (especially around non blocking state transfer) and some performance improvements: http://goo.gl/S8S0e Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
