November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5940) Add CDI Remote module to Wildfly modules

by Vaclav Dedik (JIRA)

[ https://issues.jboss.org/browse/ISPN-5940?page=com.atlassian.jira.plugin.... ] Vaclav Dedik updated ISPN-5940: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3853 > Add CDI Remote module to Wildfly modules > ---------------------------------------- > > Key: ISPN-5940 > URL: https://issues.jboss.org/browse/ISPN-5940 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: Vaclav Dedik > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5940) Add CDI Remote module to Wildfly modules

by Vaclav Dedik (JIRA)

[ https://issues.jboss.org/browse/ISPN-5940?page=com.atlassian.jira.plugin.... ] Vaclav Dedik updated ISPN-5940: ------------------------------- Status: Open (was: New) > Add CDI Remote module to Wildfly modules > ---------------------------------------- > > Key: ISPN-5940 > URL: https://issues.jboss.org/browse/ISPN-5940 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: Vaclav Dedik > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5879) XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5879?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5879: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety > --------------------------------------------------------------------------------- > > Key: ISPN-5879 > URL: https://issues.jboss.org/browse/ISPN-5879 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Remote Protocols > Reporter: Matej Čimbora > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 8.1.0.CR1 > > > When reusing a HotRod client with several threads, site can be accidentally switched multiple times by threads invoking TcpTransportFactory.trySwitchCluster. This occurs when the threads attain 'maxRetries' limit at the same time, each of them being able to invoke TcpTransportFactory..updateServers with different 'clusterAddresses' parameter. This can lead to unpredictable result (e.g. switching back to failed cluster, while the other one (backup) is up and running). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5962) Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5962: ------------------------------------ [~sannegrinovero] the benchmark is attached to this issue :) The "tasks" I'm waiting for do almost the same thing as the spinning in {{CompletableFuture.get()}}, i.e. generate random values from {{ThreadLocalRandom}}. The difference is I do it a lot more times, to minimize the chance that the task finishes before the spinning. > Implementation of RpcManagerImpl.invokeRemotely causes high CPU usage > --------------------------------------------------------------------- > > Key: ISPN-5962 > URL: https://issues.jboss.org/browse/ISPN-5962 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > Attachments: CompletableFutureBenchmarks.java > > > The method {{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>, ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}}, but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by spending a significant amount of CPU time by spinning. > When implementing RPC calls and having to wait for remote operations, spinning is probably not a good idea. Could we try implementing this in some way to hint towards a more pessimistic lock? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5914) Unauthenticated connections should be closed immediately for mechs which specify NOANONYMOUS policy

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5914?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5914: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.CR1 Resolution: Done > Unauthenticated connections should be closed immediately for mechs which specify NOANONYMOUS policy > --------------------------------------------------------------------------------------------------- > > Key: ISPN-5914 > URL: https://issues.jboss.org/browse/ISPN-5914 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.CR1, 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5914) Unauthenticated connections should be closed immediately for mechs which specify NOANONYMOUS policy

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5914?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5914: ----------------------------------- Affects Version/s: 8.0.1.Final > Unauthenticated connections should be closed immediately for mechs which specify NOANONYMOUS policy > --------------------------------------------------------------------------------------------------- > > Key: ISPN-5914 > URL: https://issues.jboss.org/browse/ISPN-5914 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.CR1, 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5987) Create concurrent topology switch under failover unit test

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5987: -------------------------------------- Summary: Create concurrent topology switch under failover unit test Key: ISPN-5987 URL: https://issues.jboss.org/browse/ISPN-5987 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 8.1.0.Final Create a unit test for ISPN-5879. Matej built a very interesting one [here|https://raw.githubusercontent.com/mcimbora/infinispan/da971738e326a7...] but needs some further work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5927) Infinispan calling setRollbackOnly() when detecting write skew

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5927?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-5927: ------------------------------------- Assignee: Pedro Ruivo > Infinispan calling setRollbackOnly() when detecting write skew > -------------------------------------------------------------- > > Key: ISPN-5927 > URL: https://issues.jboss.org/browse/ISPN-5927 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Stephen Fikes > Assignee: Pedro Ruivo > Attachments: testcase.zip > > > In the context of Java Data Grid, when Infinispan detects [#write-skew] during prepare, it invokes [#setRollbackOnly]() on the transaction implementation. This results in an exception ({{com.arjuna.ats.jta.exceptions.InvalidTerminationStateException: ARJUNA016064: The transaction is in an invalid state!}}) because this operation is disallowed by Arjuna while in the {{PREPARING}} state. The result is that the causal error ({{org.infinispan.transaction.WriteSkewException}}) is lost and the error that propagates indicates that "invalid state" (of the transaction) is actually the cause of the failed commit. Only when debug logging was enabled could we see the root cause. > h3. {anchor:write-skew}Write skew exception > ... org.infinispan.transaction.WriteSkewException: Write skew detected on key <key> for transaction TransactionImple < ... status: ActionStatus.PREPARING > > at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:53) > ... > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104) > at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213) > ... > h3. {anchor:setRollbackOnly}Set Rollback > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:313) > at org.infinispan.interceptors.InvocationContextInterceptor.markTxForRollbackAndRethrow(InvocationContextInterceptor.java:163) > ... > at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:103) > ... > at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213) > ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5956) OptimisticTxPartitionAndMergeDuringRollbackTest.testDegradedPartition random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5956?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5956: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > OptimisticTxPartitionAndMergeDuringRollbackTest.testDegradedPartition random failures > ------------------------------------------------------------------------------------- > > Key: ISPN-5956 > URL: https://issues.jboss.org/browse/ISPN-5956 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.1.0.CR1 > > > Unlike ISPN-5883, this is an issue with the tests themselves. The {{BasePartitionHandlingTest.Partition.merge(partition)}} method merges two partitions and waits for the default cache to rebalance with all the members in the merged partition. The test then assumes that all caches have been rebalanced, and fails when that is not true: > {noformat} > 22:16:37,902 ERROR (testng-PessimisticTxPartitionAndMergeDuringRollbackTest:[]) [UnitTestTestNGListener] Test testDegradedPartition(org.infinispan.partitionhandling.PessimisticTxPartitionAndMergeDuringRollbackTest) failed. > org.infinispan.partitionhandling.AvailabilityException: ISPN000306: Key 'MagicKey#k1{bbea31da@NodeB-47846/40}' is not available. Not all owners are in this partition > at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.doCheck(PartitionHandlingManagerImpl.java:250) ~[classes/:?] > at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.checkRead(PartitionHandlingManagerImpl.java:98) ~[classes/:?] > at org.infinispan.partitionhandling.impl.PartitionHandlingInterceptor.postOperationPartitionCheck(PartitionHandlingInterceptor.java:184) ~[classes/:?] > at org.infinispan.partitionhandling.impl.PartitionHandlingInterceptor.visitGetKeyValueCommand(PartitionHandlingInterceptor.java:131) ~[classes/:?] > ... > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) ~[classes/:?] > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) ~[classes/:?] > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411) ~[classes/:?] > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403) ~[classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.assertValue(BaseTxPartitionAndMergeTest.java:114) ~[test-classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:94) ~[test-classes/:?] > at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:81) ~[test-classes/:?] > at org.infinispan.partitionhandling.PessimisticTxPartitionAndMergeDuringRollbackTest.testDegradedPartition(PessimisticTxPartitionAndMergeDuringRollbackTest.java:29) ~[test-classes/:?] > {noformat} > Example in CI: > http://ci.infinispan.org/viewLog.html?buildId=32028&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5738) Upgrade to JGroups 3.6.6

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5738?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5738: -------------------------------- Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/3703) > Upgrade to JGroups 3.6.6 > ------------------------ > > Key: ISPN-5738 > URL: https://issues.jboss.org/browse/ISPN-5738 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Core > Reporter: Adrian Nistor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2015