[JBoss JIRA] (ISPN-5142) Cross site state transfer - retry mechanism not working correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5142?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5142:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1181129|https://bugzilla.redhat.com/show_bug.cgi?id=1181129] from MODIFIED to ON_QA
> Cross site state transfer - retry mechanism not working correctly
> -----------------------------------------------------------------
>
> Key: ISPN-5142
> URL: https://issues.jboss.org/browse/ISPN-5142
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Beta1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.CR1
>
>
> 2 sites - main (2 nodes), backup (3 nodes)
> Scenario:
> 1. take consumer site offline
> 2. write data into producer site
> 3. invoke push(backup) operation
> 4. write data into consumer site (such that key set overlaps with the one used in step#2)
> Configuration:
> - sync backup, 2pc
> - Pessimistic TX, multiple operations in a single TX (e.g. 20)
> Consumer site logs indicate occuring lock acquisition problems, leading to chunk not being applied. In that case, the chunk should be re-sent, however, the retry mechanism does not wait for the reply from the retry.
> pruivo's note: retry mechanism can end up in an infinite loop
> 11:25:53,549 WARN [org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl] (remote-thread-3) ISPN000291: Unable to apply X-Site state chunk.
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [key_0000000000002652] for requestor [GlobalTransaction:<localhost-17627>:25:local]! Lock held by [GlobalTransaction:<localhost-11416>:43:remote]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lockAndRegisterBackupLock(PessimisticLockingInterceptor.java:304)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:101)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:241)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:183)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:119)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:104)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.applyStateInTransaction(XSiteStateConsumerImpl.java:111)
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.applyState(XSiteStateConsumerImpl.java:92)
> at org.infinispan.xsite.statetransfer.XSiteStatePushCommand.perform(XSiteStatePushCommand.java:50)
> at org.infinispan.remoting.LocalInvocation.call(LocalInvocation.java:43)
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferState(BackupReceiverImpl.java:140)
> at org.infinispan.xsite.statetransfer.XSiteStatePushCommand.performInLocalSite(XSiteStatePushCommand.java:32)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:250)
> 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:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4051) ProtoStream should provide guidelines when it fails to resolve dependencies correctly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4051?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4051:
--------------------------------
Fix Version/s: 7.0.0.Final
> ProtoStream should provide guidelines when it fails to resolve dependencies correctly
> -------------------------------------------------------------------------------------
>
> Key: ISPN-4051
> URL: https://issues.jboss.org/browse/ISPN-4051
> Project: Infinispan
> Issue Type: Bug
> Reporter: Tristan Tarrant
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Final
>
>
> Attempting to import a ProtoBuf definition which uses imports fails with:
> Caused by: com.google.protobuf.Descriptors$DescriptorValidationException: AeiReaderMessage_M.proto: Dependencies passed to FileDescriptor.buildFrom() don't match those listed in the FileDescriptorProto.
> at com.google.protobuf.Descriptors$FileDescriptor.buildFrom(Descriptors.java:240)
> at org.infinispan.protostream.impl.SerializationContextImpl.registerProtofile(SerializationContextImpl.java:61)
> at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.registerProtofile(ProtobufMetadataManager.java:154)
> at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.modified(ProtobufMetadataManager.java:149)
> This is caused by the fact that SerializationContextImpl#resolveDeps returns an empty array even though the inlcuded file is actually in the definition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5048) Relocate some imported packages in uberjars and remove any javax.* classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5048:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1170663|https://bugzilla.redhat.com/show_bug.cgi?id=1170663] from POST to MODIFIED
> Relocate some imported packages in uberjars and remove any javax.* classes
> --------------------------------------------------------------------------
>
> Key: ISPN-5048
> URL: https://issues.jboss.org/browse/ISPN-5048
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Final, 7.0.3.Final
>
>
> There is a readme in the jar for infinispan-embedded-query which states: "Copyright (c) 2008, 2009 Sun Microsystems, Oracle Corporation. All rights reserved."
> In /META-INF there are notices claiming that all of this is licensed as ASL2 which is not correct.
> we also include things like javax.persistence and javax.servlet, those are going to cause trouble for sure as I don't think it's reasonable to expect the users to not have duplicates of such things in their classpath.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5126) DistributedExecutorService ignores unsuccessful responses
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5126?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5126:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1182678|https://bugzilla.redhat.com/show_bug.cgi?id=1182678] from POST to MODIFIED
> DistributedExecutorService ignores unsuccessful responses
> ---------------------------------------------------------
>
> Key: ISPN-5126
> URL: https://issues.jboss.org/browse/ISPN-5126
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Distributed Execution and Map/Reduce
> Affects Versions: 7.1.0.Alpha1, 7.0.3.Final
> Reporter: Dan Berindei
> Assignee: Vladimir Blagojevic
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 7.1.0.CR1, 7.1.0.Final
>
>
> I got a failure in {{DistributedExecutorFailureTest}} (master only) on my machine because the distributed executor ignores {{CacheNotFoundResponse}} responses:
> {noformat}
> 15:18:45,516 TRACE (transport-thread-NodeA-p30129-t4:) [CommandAwareRpcDispatcher] Response: CacheNotFoundResponse
> 15:18:45,516 TRACE (transport-thread-NodeA-p30129-t4:) [RpcManagerImpl] Response(s) to DistributedExecuteCommand [cache=null, keys=[], callable=org.infinispan.distexec.DistributedExecutorFailoverTest$SleepingSimpleCallable@23a9b62a] is {NodeB-4305=CacheNotFoundResponse}
> 15:18:45,517 ERROR (testng-DistributedExecutorFailoverTest:) [UnitTestTestNGListener] Test testBasicTargetRemoteDistributedCallable(org.infinispan.distexec.DistributedExecutorFailoverTest) failed.
> java.lang.AssertionError: expected:<1> but was:<null>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.distexec.DistributedExecutorFailoverTest.testBasicTargetRemoteDistributedCallable(DistributedExecutorFailoverTest.java:74)
> {noformat}
> {{RemoteDistributedTaskPart.retrieveResult()}} ignores any response that's not a {{SuccessfulResponse}} and returns {{null}}. It should throw an exception instead, so that the failover policy can retry it on another node.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4726) Compatibility mode: modules
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4726?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4726:
----------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3221
I don't think there's a better way of resolving this. Opened a PR for documenting the steps.
> Compatibility mode: modules
> ---------------------------
>
> Key: ISPN-4726
> URL: https://issues.jboss.org/browse/ISPN-4726
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Servers
> Affects Versions: 7.0.0.Beta1
> Reporter: Radim Vansa
>
> I've tried to run the server in compatibility mode, but haven't included the JAR with class uploaded by HotRod client - and boom, I got ClassNotFoundExceptions.
> To resolve this, I've modified modules.xml for infinispan-commons and added the JAR with my classes there, but I don't think this is a correct solution - nor creating a new module and adding this as dependency to infinispan-commons. IMO I am using Infinispan as service, therefore, I should not put application classes as dependencies into modules.
> The recommended approach is not described neither in User Guide nor Server Guide - these specify just the configuration option.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4726) Compatibility mode: modules
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4726?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4726:
----------------------------
Status: Open (was: New)
> Compatibility mode: modules
> ---------------------------
>
> Key: ISPN-4726
> URL: https://issues.jboss.org/browse/ISPN-4726
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Servers
> Affects Versions: 7.0.0.Beta1
> Reporter: Radim Vansa
>
> I've tried to run the server in compatibility mode, but haven't included the JAR with class uploaded by HotRod client - and boom, I got ClassNotFoundExceptions.
> To resolve this, I've modified modules.xml for infinispan-commons and added the JAR with my classes there, but I don't think this is a correct solution - nor creating a new module and adding this as dependency to infinispan-commons. IMO I am using Infinispan as service, therefore, I should not put application classes as dependencies into modules.
> The recommended approach is not described neither in User Guide nor Server Guide - these specify just the configuration option.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months