Keeping a healthy changelog
by Sanne Grinovero
Hi all,
I noticed occasionally some pull requests and JIRAs are resolved
without updating the true nature of the resolved issues; of course one
might start thinking to work on one thing which then turns out to be a
different problem, these things are frequent but as soon as you notice
the mismatch it would be great to update the JIRA description, or
create a separate one.
Example:
https://github.com/infinispan/infinispan/pull/1450
the issue isn't just fixing a broken test but dealing with an
important to trace bug, so that people searching for similar problems
can find it.
good idea?
Cheers,
Sanne
11 years, 5 months
Lock ordering under optimistic locking
by Radim Vansa
Hi,
in OptimisticLockingInterceptor, the keys are ordered according to their hash. However, the hashes can still collide, which may result in a deadlock if two keys with identical hash (only 32-bit) are sorted to different order. The locks would time-out, but shouldn't we at least try to check if the keys are Comparable or let user provide some comparator class in config, and use the compare of hash only as the last resort? (and in all cases emit warning into log if the compare operation had non-strict result).
It's a minor problem (considering other current locking issues), but I wouldn't want to investigate why such deadlock happened :)
Btw., in OLE.visitPrepareCommand the log.tracef("Using lock reordering, order is: %s", orderedKeys); does not work, only the first key is printed out.
Radim
-----------------------------------------------------------
Radim Vansa
Quality Assurance Engineer
JBoss Datagrid
tel. +420532294559 ext. 62559
Red Hat Czech, s.r.o.
Brno, Purkyňova 99/71, PSČ 612 45
Czech Republic
11 years, 6 months
Infinispan and SwitchYard
by Keith Babo
Hey Infinispan Peeps,
We just buttoned up our initial implementation of a clustered service registry based on Infinispan and I would love some feedback from y'all. One particular area of concern is the use of TreeCache in our implementation. I have to admit that this API matched my conceptual view of our clustered service topology best, but I've heard from a few people that a little kitten cries every time you use TreeCache. If there's an obvious way to get the same thing done using vanilla Cache, then I'm all ears!
Here's a brief write-up of what we've done:
https://community.jboss.org/wiki/ClusteredRegistryArchitecture
Any feedback you can provide would be most welcome.
cheers,
keith
11 years, 6 months
Fixing ISPN-2384 (data loss with concurrent activation/passivation)
by Galder Zamarreño
Hi all,
Re: https://issues.jboss.org/browse/ISPN-2384
I've created a unit test in https://github.com/galderz/infinispan/commit/01230d40df6f26720039986916c3...
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
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
11 years, 6 months
Test for state transfer hanging
by Sanne Grinovero
Hi all,
I was trying to fix some Query related issues but I have to either give up
or engage "commit and pray" driven development: the testsuite hangs very
consistently.
Anyone else having this? I hope so, that would make it easier to debug!
Name: testng-MultiNodeDistributedTest
State: TIMED_WAITING on java.util.concurrent.CountDownLatch$Sync@28ab6530
Total blocked: 178 Total waited: 50
Stack trace:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1011)
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1303)
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:253)
org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:200)
sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
- locked org.infinispan.factories.ComponentRegistry@6012c643
org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199)
org.infinispan.CacheImpl.start(CacheImpl.java:520)
org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:690)
org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:653)
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549)
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:521)
org.infinispan.query.distributed.MultiNodeDistributedTest.createCacheManager(MultiNodeDistributedTest.java:60)
org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:95)
11 years, 6 months
