August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-2976: ---------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > Log4J dependencies in codebase to be cleaned up > ----------------------------------------------- > > Key: ISPN-2976 > URL: https://issues.jboss.org/browse/ISPN-2976 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: Dan Berindei > Labels: core > > When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes. > {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly. > {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}. > {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Work on ISPN-3076 started by Dan Berindei. > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 5.2.5.Final, 6.0.0.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Dan Berindei > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4517) RollbackCommands should ignore leavers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4517?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4517: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1119350 > RollbackCommands should ignore leavers > -------------------------------------- > > Key: ISPN-4517 > URL: https://issues.jboss.org/browse/ISPN-4517 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Beta1 > > > When one of the targets of a PrepareCommand leaves, the originator receives a SuspectException and tries to roll back the transaction. However, the RollbackCommand can also fail with with a SuspectException if: > * syncRollbackPhase = true (the default, since ISPN-4137) > * The cache topology hasn't been updated to exclude the leaver yet (maybe because it was the old coordinator that left) > In that case, we could throw a SuspectException in JGroupsTransport.invokeRemotely without sending the RollbackCommand to the other owner: > {noformat} > 23:34:01,219 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (PrivateLogChecker-4) ISPN000136: Execution error > org.infinispan.remoting.transport.jgroups.SuspectException: One or more nodes have left the cluster while replicating command RollbackCommand {gtx=GlobalTransaction:<edg-perf08-52473>:1077:local, cacheName='testCache', topologyId=8} > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:486) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281) > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRollbackCommand(TxDistributionInterceptor.java:223) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > 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.visitRollbackCommand(AbstractVisitor.java:101) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitRollbackCommand(AbstractTxLockingInterceptor.java:51) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.NotificationInterceptor.visitRollbackCommand(NotificationInterceptor.java:50) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.TxInterceptor.visitRollbackCommand(TxInterceptor.java:207) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > 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.visitRollbackCommand(AbstractVisitor.java:101) > at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitRollbackCommand(TransactionSynchronizerInterceptor.java:66) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:222) > at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:153) > at org.infinispan.statetransfer.StateTransferInterceptor.visitRollbackCommand(StateTransferInterceptor.java:91) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > 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.visitRollbackCommand(AbstractVisitor.java:101) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > 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.visitRollbackCommand(AbstractVisitor.java:101) > at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.transaction.TransactionCoordinator.rollbackInternal(TransactionCoordinator.java:237) > at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:172) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104) > at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1436) > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:904) > at org.infinispan.CacheImpl.put(CacheImpl.java:896) > at org.infinispan.CacheImpl.put(CacheImpl.java:1471) > at org.infinispan.CacheImpl.put(CacheImpl.java:231) > at org.radargun.cachewrappers.InfinispanBasicOperations.put(InfinispanBasicOperations.java:25) > at org.radargun.cachewrappers.Infinispan51BasicOperations.put(Infinispan51BasicOperations.java:31) > at org.radargun.cachewrappers.Infinispan52BasicOperations.put(Infinispan52BasicOperations.java:16) > at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:185) > at org.radargun.stressors.LogChecker.run(LogChecker.java:106) > {noformat} > The RollbackCommand should have the SYNCHRONOUS_IGNORE_LEAVERS ResponseMode, so that the owner still alive receives the the command. Otherwise, that stale transaction will never be completed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4571) JmxManagementIT.testRpcManagerAttributes random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4571?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4571: ----------------------------------- Assignee: Dan Berindei (was: Galder Zamarreño) > JmxManagementIT.testRpcManagerAttributes random failures > -------------------------------------------------------- > > Key: ISPN-4571 > URL: https://issues.jboss.org/browse/ISPN-4571 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > JmxManagementIT sometimes can't find the JGroups MBean: > {noformat} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.infinispan.server.test.jmx.management.JmxManagementIT.testRpcManagerAttributes(JmxManagementIT.java:273) > {noformat} > Unfortunately the server integration tests don't seem to use the {{-Dlog4j.configuration}} build parameter, so the CI builds don't have other logs. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4571) JmxManagementIT.testRpcManagerAttributes random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4571?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-4571. ------------------------------------ Resolution: Done > JmxManagementIT.testRpcManagerAttributes random failures > -------------------------------------------------------- > > Key: ISPN-4571 > URL: https://issues.jboss.org/browse/ISPN-4571 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > JmxManagementIT sometimes can't find the JGroups MBean: > {noformat} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.infinispan.server.test.jmx.management.JmxManagementIT.testRpcManagerAttributes(JmxManagementIT.java:273) > {noformat} > Unfortunately the server integration tests don't seem to use the {{-Dlog4j.configuration}} build parameter, so the CI builds don't have other logs. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4571) JmxManagementIT.testRpcManagerAttributes random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4571?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-4571: ---------------------------------------- The InterruptedExceptions appear to be caused by the fix in ISPN-4484. Dan's fixed these with https://github.com/infinispan/infinispan/commit/22fe365151d008b97d6e93e48... > JmxManagementIT.testRpcManagerAttributes random failures > -------------------------------------------------------- > > Key: ISPN-4571 > URL: https://issues.jboss.org/browse/ISPN-4571 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > JmxManagementIT sometimes can't find the JGroups MBean: > {noformat} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.infinispan.server.test.jmx.management.JmxManagementIT.testRpcManagerAttributes(JmxManagementIT.java:273) > {noformat} > Unfortunately the server integration tests don't seem to use the {{-Dlog4j.configuration}} build parameter, so the CI builds don't have other logs. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2932) Preloading a read only index in a cache will never hit the cacheloader

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2932?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2932: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Preloading a read only index in a cache will never hit the cacheloader > ---------------------------------------------------------------------- > > Key: ISPN-2932 > URL: https://issues.jboss.org/browse/ISPN-2932 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > With a warm cache (with no eviction) we should never need to hit the CacheLoader again. > Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) > I'm suspecting demand of null valued entries. > mailing list thread: http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012261.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2932) Preloading a read only index in a cache will never hit the cacheloader

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2932?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2932: ---------------------------------- Summary: Preloading a read only index in a cache will never hit the cacheloader (was: Verify that preloading a read only index in a cache will never hit the cacheloader) > Preloading a read only index in a cache will never hit the cacheloader > ---------------------------------------------------------------------- > > Key: ISPN-2932 > URL: https://issues.jboss.org/browse/ISPN-2932 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > With a warm cache (with no eviction) we should never need to hit the CacheLoader again. > Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) > I'm suspecting demand of null valued entries. > mailing list thread: http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012261.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4548) Revamp AbstractInfinispanTest thread handling to use pooling

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4548?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4548: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta1 Resolution: Done > Revamp AbstractInfinispanTest thread handling to use pooling > ------------------------------------------------------------ > > Key: ISPN-4548 > URL: https://issues.jboss.org/browse/ISPN-4548 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > > Our base AbstractInfinispanTest class forks a new thread every time fork is called. It would provide better performance and memory usage if instead we used a pool for threads spawned in this way in the same the test. > Also we have support for running tests concurrently which currently don't work properly due to the usage of CountDownLatch which isn't quite sufficient for what it was trying to achieve. The usage of a CyclicBarrier would be more appropriate. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4597) Query interceptor should update index during commit

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4597?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4597: ------------------------------------ I haven't really seen problems in a test, I was just reading the QueryInterceptor code and thought it was unusual that the {{visitCommitCommand}} method didn't do anything. > Query interceptor should update index during commit > --------------------------------------------------- > > Key: ISPN-4597 > URL: https://issues.jboss.org/browse/ISPN-4597 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Dan Berindei > Assignee: Sanne Grinovero > > {{QueryInterceptor}} updates indexes during {{visitPrepareCommand}}. However, a tx that was prepared successfully is not guaranteed to be actually committed (e.g. if another node fails to prepare, or if another XA resource fails). The index should only be updated during {{visitPrepareCommand}} if the prepare is 1-phase, otherwise it should be updated during {{visitCommitCommand}}. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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 August 2014