April 2014 - infinispan-issues - Jboss List Archives

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3920: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083635 > 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 > Affects Versions: 6.0.1.Final > Reporter: Ion Savin > Assignee: Ion Savin > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4018) Write skew should not be check if conditional operations does not change the value

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4018?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4018: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083610 > Write skew should not be check if conditional operations does not change the value > ---------------------------------------------------------------------------------- > > Key: ISPN-4018 > URL: https://issues.jboss.org/browse/ISPN-4018 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Currently, if a conditional operation does no perform the update, we still perform the check. however, the write never happened. It simple makes no sense. > However, if a write succeeds after, the write skew check must be performed for the key. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4182?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-4182: ------------------------------------- To be more specific, the collisions occur if a previous test did not succeed in stopping the cache store correctly and dropping the table. The next test will fail to create the table because it exists already. So we need to ensure db instances are unique for nodes of the same test cluster and also unique compared to the ones used by next test - thus global uniqueness is required. > ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4182 > URL: https://issues.jboss.org/browse/ISPN-4182 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4170) Upgrade to JGroups 3.5.0.Beta2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4170?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4170: ------------------------------- Assignee: Mircea Markus (was: Dan Berindei) > Upgrade to JGroups 3.5.0.Beta2 > ------------------------------ > > Key: ISPN-4170 > URL: https://issues.jboss.org/browse/ISPN-4170 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 7.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha3 > > > {quote} > Released. Major new feature compared to Beta1: > - Messages are now always looped back (mcasts are discarded when copies > are received) > https://issues.jboss.org/browse/JGRP-1765 > - DONT_LOOPBACK flag: mesages can now be dropped at the transport level > https://issues.jboss.org/browse/JGRP-1816 > - Removed bottleneck when sending a message to a non-existent dest > https://issues.jboss.org/browse/JGRP-1815 > - UNICAST3: connections to non-members are now closed more quickly > https://issues.jboss.org/browse/JGRP-1814 > - SHARED_LOOPBACK_PING: new discovery protocol which always discovers > members in the same JVM. Used by unit tests. > https://issues.jboss.org/browse/JGRP-1809 > - Hardened code for generating seqnos in UNICAST3 and NAKACK2 > https://issues.jboss.org/browse/JGRP-1807 > {quote} -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4182?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4182: -------------------------------- Labels: 630 (was: ) > ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4182 > URL: https://issues.jboss.org/browse/ISPN-4182 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-4182: ----------------------------------- Summary: ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests Key: ISPN-4182 URL: https://issues.jboss.org/browse/ISPN-4182 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 7.0.0.Alpha1 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 7.0.0.Alpha3, 7.0.0.Final The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4181) HotRod server throws CNFE javax/net/ssl/SSLException

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4181?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4181: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2475 > HotRod server throws CNFE javax/net/ssl/SSLException > ---------------------------------------------------- > > Key: ISPN-4181 > URL: https://issues.jboss.org/browse/ISPN-4181 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 7.0.0.Alpha2 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha3 > > > This is caused by io.netty server module missing the dependency on javax.api -- 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

11 years, 6 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 RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3873: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1083508|https://bugzilla.redhat.com/show_bug.cgi?id=1083508] from ASSIGNED to MODIFIED > 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 > Affects Versions: 6.0.1.Final > Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45 > Reporter: Karl von Randow > Assignee: Dan Berindei > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3771) HotRod SSL is not working properly with IBM JDKs -- SSLHandshakeException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3771?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3771: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1035759|https://bugzilla.redhat.com/show_bug.cgi?id=1035759] from NEW to MODIFIED > HotRod SSL is not working properly with IBM JDKs -- SSLHandshakeException > ------------------------------------------------------------------------- > > Key: ISPN-3771 > URL: https://issues.jboss.org/browse/ISPN-3771 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Final > Environment: Both RHEL x64 and x32 architecture using IBM JDK 6 or IBM JDK 7. > Test is passing for Open-jdk and Oracle-jdk. > Reporter: Tomas Sykora > Assignee: Martin Gencur > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > Attachments: hotRodSSLibmJDKsProblem > > > For reproducing, run mvn clean verify -Psuite.examples -DfailIfNoTests=false -Dtest=ExampleConfigsTest#testSSLHotRodConfig in Infinispan-server testsuite, using IBM JDK 7. > See attached file for stack trace. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4181) HotRod server throws CNFE javax/net/ssl/SSLException

by Martin Gencur (JIRA)

Martin Gencur created ISPN-4181: ----------------------------------- Summary: HotRod server throws CNFE javax/net/ssl/SSLException Key: ISPN-4181 URL: https://issues.jboss.org/browse/ISPN-4181 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 7.0.0.Alpha2 Reporter: Martin Gencur Assignee: Martin Gencur Fix For: 7.0.0.Alpha3 This is caused by io.netty server module missing the dependency on javax.api -- 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

11 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014