January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-3920: ---------------------------- Attachment: server.log.gz Server log covering the put/get hotrod requests done by Simple.cpp > Server initialization race condition - cache config defaults not used > --------------------------------------------------------------------- > > Key: ISPN-3920 > URL: https://issues.jboss.org/browse/ISPN-3920 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Ion Savin > Assignee: Mircea Markus > Attachments: server.log.gz > > > The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. > The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Ion Savin (JIRA)

Ion Savin created ISPN-3920: ------------------------------- Summary: Server initialization race condition - cache config defaults not used Key: ISPN-3920 URL: https://issues.jboss.org/browse/ISPN-3920 Project: Infinispan Issue Type: Bug Components: Server Reporter: Ion Savin Assignee: Mircea Markus The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3124) AtomicHashMap.put is not atomic with pessimistic locking

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3124?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3124: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/1874 > AtomicHashMap.put is not atomic with pessimistic locking > -------------------------------------------------------- > > Key: ISPN-3124 > URL: https://issues.jboss.org/browse/ISPN-3124 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.7.Final, 5.3.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.3.0.CR2, 5.3.0.Final > > > When the user calls {{AtomicHashMap.put(k, v)}}, {{AtomicHashMapProxy.getDeltaMapForWrite()}} first reads the atomic map in the invocation context, and only acquires a lock afterwards. > Between the read and the lock, another transaction can write something to the atomic map, and that write will be lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3916) Expiration reaper is not enabled until lifespan or max-idle is set

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3916?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3916: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 7.0.0.Final Resolution: Done > Expiration reaper is not enabled until lifespan or max-idle is set > ------------------------------------------------------------------ > > Key: ISPN-3916 > URL: https://issues.jboss.org/browse/ISPN-3916 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If a cache is added where entities are with and without expiration by external processes it is expected that the reaper purge the data from memory and datastore. > As the reaper is only enabled for the cache if the element > <expiration interval="millis" lifespan="millis" max-idle="millis"/> > has one of the attributes lifespan or max-idle set to a value >0 > The expired entities will not be removed from the memory or datastore. > This is an unexpected behaviour and might end in a memory bottleneck if a server is up for a long time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3918: ------------------------------- Component/s: State transfer (was: Locking and Concurrency) > Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer > --------------------------------------------------------------------------------------- > > Key: ISPN-3918 > URL: https://issues.jboss.org/browse/ISPN-3918 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, State transfer > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > Attachments: ntpiadjst.log.gz > > > In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls. > Say \[B, A, C] are the owners of k (C just joined) > 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B > 2. B forwards the command to A and C > 3. C writes {{k=v1}} > 4. C becomes the primary owner of k (owners are now \[C, A]) > 5. A/B see the new topology before committing and throw an outdatedTopologyException > 6. A retries the command, sends it to C > 7. C forwards the command to A, which writes {{k=v1}} > 8. C doesn't have to update the entry, returns null > If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3919) verify that the hotrod client can specify marshallers using the @SerializeWith annotation

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3919?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3919: ---------------------------------------- No need to verify, it won't work. This requires advanced externalizers which were left out of the Hot Rod client. You'd need to bring in the externalizer table and a lot of other JBoss Marshalling related components to make this work. Is it really needed? > verify that the hotrod client can specify marshallers using the @SerializeWith annotation > ----------------------------------------------------------------------------------------- > > Key: ISPN-3919 > URL: https://issues.jboss.org/browse/ISPN-3919 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Mircea Markus > Assignee: Galder Zamarreño > > An unit test in the remote java client would do, imo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3919) verify that the hotrod client can specify marshallers using the @SerializeWith annotation

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3919: ----------------------------------- Summary: verify that the hotrod client can specify marshallers using the @SerializeWith annotation Key: ISPN-3919 URL: https://issues.jboss.org/browse/ISPN-3919 Project: Infinispan Issue Type: Feature Request Components: Remote protocols Reporter: Mircea Markus Assignee: Galder Zamarreño An unit test in the remote java client would do, imo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3918: ---------------------------------- Summary: Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer Key: ISPN-3918 URL: https://issues.jboss.org/browse/ISPN-3918 Project: Infinispan Issue Type: Bug Components: Distributed Cache, Locking and Concurrency Affects Versions: 6.0.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Final Attachments: ntpiadjst.log.gz In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls. Say \[B, A, C] are the owners of k (C just joined) 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B 2. B forwards the command to A and C 3. C writes {{k=v1}} 4. C becomes the primary owner of k (owners are now \[C, A]) 5. A/B see the new topology before committing and throw an outdatedTopologyException 6. A retries the command, sends it to C 7. C forwards the command to A, which writes {{k=v1}} 8. C doesn't have to update the entry, returns null If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3918: ------------------------------- Attachment: ntpiadjst.log.gz This is causing a random failure in NonTxPutIfAbsentDuringJoinStressTest. > Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer > --------------------------------------------------------------------------------------- > > Key: ISPN-3918 > URL: https://issues.jboss.org/browse/ISPN-3918 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Locking and Concurrency > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > Attachments: ntpiadjst.log.gz > > > In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls. > Say \[B, A, C] are the owners of k (C just joined) > 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B > 2. B forwards the command to A and C > 3. C writes {{k=v1}} > 4. C becomes the primary owner of k (owners are now \[C, A]) > 5. A/B see the new topology before committing and throw an outdatedTopologyException > 6. A retries the command, sends it to C > 7. C forwards the command to A, which writes {{k=v1}} > 8. C doesn't have to update the entry, returns null > If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3873: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2345 Initialize the key Equivalence in AbstractInvocationContextFactory in the init() method (instead of start()). StateTransferLock.waitForTransactionData() should never return before the initial topology was installed. RpcManagerImpl must set the topology id for non-tx TopologyAffectedCommands that are wrapped in SingleRpcCommands. Invalidation commands should have their topology id set in StateTransferInterceptor. > Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup) > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3873 > URL: https://issues.jboss.org/browse/ISPN-3873 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.1.Final > Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45 > Reporter: Karl von Randow > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha1 > > Attachments: infinispan.trace.gz > > > Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional. > The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar. > At this point I'm not sure how to fix it! > java.lang.NullPointerException > at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176) > at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109) > at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84) > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665) > at org.jgroups.JChannel.up(JChannel.java:730) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) > at org.jgroups.stack.Protocol.up(Protocol.java:409) > at org.jgroups.stack.Protocol.up(Protocol.java:409) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) > at org.jgroups.protocols.RSVP.up(RSVP.java:221) > at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919) > at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800) > at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147) > at org.jgroups.protocols.FD.up(FD.java:255) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) > at org.jgroups.protocols.MERGE2.up(MERGE2.java:209) > at org.jgroups.protocols.Discovery.up(Discovery.java:379) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1399) > at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014