January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3887) Server tests should be automatically skipped during distribution profile

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3887?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3887: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Server tests should be automatically skipped during distribution profile > ------------------------------------------------------------------------ > > Key: ISPN-3887 > URL: https://issues.jboss.org/browse/ISPN-3887 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > -- 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-3889) L1 Synchronizer should have a timeout

by William Burns (JIRA)

William Burns created ISPN-3889: ----------------------------------- Summary: L1 Synchronizer should have a timeout Key: ISPN-3889 URL: https://issues.jboss.org/browse/ISPN-3889 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 6.0.0.Final Reporter: William Burns Assignee: Mircea Markus Fix For: 7.0.0.Final The L1 Synchronizer currently does a get when waiting for a concurrent request to complete. If for some reason the other request doesn't complete this can block forever as well. This has only been seen on IBM JDK 6 though and I think it is related to some issues with that JVM. -- 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-3889) L1 Synchronizer should have a timeout

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3889?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3889: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > L1 Synchronizer should have a timeout > ------------------------------------- > > Key: ISPN-3889 > URL: https://issues.jboss.org/browse/ISPN-3889 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > The L1 Synchronizer currently does a get when waiting for a concurrent request to complete. If for some reason the other request doesn't complete this can block forever as well. This has only been seen on IBM JDK 6 though and I think it is related to some issues with that JVM. -- 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-3888) Enums are not serialized properly with IBM JDK 6

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3888?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3888: -------------------------------- Fix Version/s: 7.0.0.Final > Enums are not serialized properly with IBM JDK 6 > ------------------------------------------------ > > Key: ISPN-3888 > URL: https://issues.jboss.org/browse/ISPN-3888 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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-3888) Enums are not serialized properly with IBM JDK 6

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3888?page=com.atlassian.jira.plugin.... ] Work on ISPN-3888 started by William Burns. > Enums are not serialized properly with IBM JDK 6 > ------------------------------------------------ > > Key: ISPN-3888 > URL: https://issues.jboss.org/browse/ISPN-3888 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Reporter: William Burns > Assignee: William Burns > > This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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-3888) Enums are not serialized properly with IBM JDK 6

by William Burns (JIRA)

William Burns created ISPN-3888: ----------------------------------- Summary: Enums are not serialized properly with IBM JDK 6 Key: ISPN-3888 URL: https://issues.jboss.org/browse/ISPN-3888 Project: Infinispan Issue Type: Bug Components: Marshalling Reporter: William Burns Assignee: Galder Zamarreño This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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-3888) Enums are not serialized properly with IBM JDK 6

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3888?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3888: ----------------------------------- Assignee: William Burns (was: Galder Zamarreño) > Enums are not serialized properly with IBM JDK 6 > ------------------------------------------------ > > Key: ISPN-3888 > URL: https://issues.jboss.org/browse/ISPN-3888 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Reporter: William Burns > Assignee: William Burns > > This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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 Karl von Randow (JIRA)

[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ] Karl von Randow commented on ISPN-3873: --------------------------------------- I have implemented and confirmed the success of a workaround - basically I throw an IllegalStateException if the AbstractInvocationContextFactory.createRemoteInvocationContextForCommand(VisitableCommand, Address) method is called before the context factory has been started. Because this fault resulted in a hung lock this has been a serious issue for us in production. I'm not sure if this is a permanent fix - it appears to work in production for us: there is no hung lock and no other observed ill effects. As you noted above, there is nothing to invalidate so the fact that we drop the message is probably okay. I'll submit a pull request so it can be considered, but I'll understand if it doesn't make the cut as a proper solution! > 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 > > > 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

[JBoss JIRA] (ISPN-800) Infinispan inside OSGI

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant commented on ISPN-800: -------------------------------------- Would that also mean creating a similar bundle for the hotrod client ? > Infinispan inside OSGI > ---------------------- > > Key: ISPN-800 > URL: https://issues.jboss.org/browse/ISPN-800 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Reporter: Luca Stancapiano > Assignee: Galder Zamarreño > > We need to import infinispan inside a OSGI repository. Tests are made with Felix. > I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan > I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI. > Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc) > Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles: > jboss transaction api 1.0.1.GA > We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... ) > jgroups 2.10.1.GA > (it's a osgi bundle since the 3.x version) > river 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml ) > marshalling-api 1.2.3.GA > (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml ) > jboss logging spi 2.0.5.GA > (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version) > rhq plugin annotations 1.4.0.B01 > (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 ) > i18nlog 1.0.9 > (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15) > log4j 1.2.16 > (that's ok...it is a osgi bundle ;)) > jcip-annotations 1.0 > (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project) > We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that: > 1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan. > 2 - it does not fail due to the dependency that is not really essential. -- 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-3875) JMX related chapter of user guide is not up to date

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3875?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3875: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2331 > JMX related chapter of user guide is not up to date > ---------------------------------------------------- > > Key: ISPN-3875 > URL: https://issues.jboss.org/browse/ISPN-3875 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The text implies the user needs to follow certain steps in order to enable jmx (ie enable stats), but mbeans are currently created and registered even if statistics are not enabled. -- 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