[JBoss JIRA] (ISPN-11101) Purge on JDBC shared stores can cause deadlocks
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11101?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11101:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/7692, https://github.com/infinispan/infinispan/pull/7701, https://github.com/infinispan/infinispan/pull/7704 (was: https://github.com/infinispan/infinispan/pull/7692, https://github.com/infinispan/infinispan/pull/7701)
> Purge on JDBC shared stores can cause deadlocks
> -----------------------------------------------
>
> Key: ISPN-11101
> URL: https://issues.redhat.com/browse/ISPN-11101
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.4.17.Final, 10.1.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final, 9.4.18.Final
>
>
> ISPN-10337 ensured that the JdbcStringBasedStore correctly acquired the locks of expired rows during the purging of store entries, however it has exposed an issue with shared stores. When the jdbc store is shared, the coordinator locks the rows of the affected entries and releases them once they have all been removed as part of the purge transaction. However, the call to {{ExpirationManager::handleInStoreExpiration}} also sends a {{RemoveExpiredCommand}} to ensure that entries are removed from memory. This results in a {{java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction}} being thrown by the store's delete method when the purge process is still in progress, because the expired rows are still locked and the purge process cannot complete until the {{RemoveExpiredCommand}} has been executed.
> In summary:
> # purge locks all the rows
> # purge sends a RemoveExpiredCommand and waits for it to complete
> # RemoveExpiredCommand tries to remove the row but it can't as it is locked
> Solution, send the {{RemoveExpiredCommand}} with the {{SKIP_CACHE_STORE}} flag when a store is shared,so that it only removes entries from memory.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10830) Client Testsuite should utilise SerializationContextInitializers via configuration
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-10830?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-10830:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.0.Final
Resolution: Done
> Client Testsuite should utilise SerializationContextInitializers via configuration
> ----------------------------------------------------------------------------------
>
> Key: ISPN-10830
> URL: https://issues.redhat.com/browse/ISPN-10830
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> The client testsuite makes extensive use of the {{ProtobufMetadataManagerImpl::registerMarshaller}} method to register ProtoStream marshallers, however this is no longer necessary as we now expose the SerializationContextInitializer via our server configuration.
> Furthermore, it's also possible to directly use SerializationContextInitializer instances via the client configuration.
> The client testsuite should be updated to utilise ^ mechanisms.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11076) ParticipantFailsAfterPrepareTest.testNonOriginatorFailsAfterPrepare random failures
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11076?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11076:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ParticipantFailsAfterPrepareTest.testNonOriginatorFailsAfterPrepare random failures
> -----------------------------------------------------------------------------------
>
> Key: ISPN-11076
> URL: https://issues.redhat.com/browse/ISPN-11076
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.0.Final
>
>
> The test checks that all locks are released properly after a tx participant is killed, but doesn't consider the fact that {{TxCompletionNotificationCommand}} is invoked asynchronously.
> {noformat}
> 00:55:29,005 TRACE (testng-Test:[]) [DefaultLockManager] Lock key=MagicKey{745/083A744A/71@Test-NodeA-51773} for owner=GlobalTx:Test-NodeA-51773:9335. timeout=10000 (MILLISECONDS)
> 00:55:29,177 TRACE (remote-thread-Test-NodeB-p22871-t2:[]) [DefaultLockManager] Lock key=MagicKey{745/083A744A/71@Test-NodeA-51773} for owner=GlobalTx:Test-NodeA-51773:9335. timeout=10000 (MILLISECONDS)
> 00:55:29,178 TRACE (jgroups-8,Test-NodeA-51773:[]) [DefaultLockManager] Release locks for keys=[MagicKey{745/083A744A/71@Test-NodeA-51773}]. owner=GlobalTx:Test-NodeA-51773:9335
> 00:55:29,179 TRACE (testng-Test:[]) [JGroupsTransport] Test-NodeA-51773 sending command to [Test-NodeD-59848, Test-NodeA-51773, Test-NodeB-24298, Test-NodeC-43307]: TxCompletionNotificationCommand{ xid=null, internalId=0, topologyId=18, gtx=GlobalTx:Test-NodeA-51773:9335, cacheName=Test}
> 00:55:29,184 TRACE (remote-thread-Test-NodeD-p22929-t2:[]) [DefaultLockManager] Release locks for keys=[]. owner=GlobalTx:Test-NodeA-51773:9335
> 00:55:29,184 TRACE (remote-thread-Test-NodeB-p22871-t2:[]) [DefaultLockManager] Release locks for keys=[MagicKey{745/083A744A/71@Test-NodeA-51773}]. owner=GlobalTx:Test-NodeA-51773:9335
> 00:55:29,186 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.tx.ParticipantFailsAfterPrepareTest.testNonOriginatorFailsAfterPrepare
> java.lang.AssertionError: expected [0] but found [1]
> at org.testng.Assert.fail(Assert.java:96) ~[testng-6.14.3.jar:?]
> at org.testng.Assert.failNotEquals(Assert.java:776) ~[testng-6.14.3.jar:?]
> at org.testng.Assert.assertEqualsImpl(Assert.java:137) ~[testng-6.14.3.jar:?]
> at org.testng.Assert.assertEquals(Assert.java:118) ~[testng-6.14.3.jar:?]
> at org.testng.Assert.assertEquals(Assert.java:652) ~[testng-6.14.3.jar:?]
> at org.testng.Assert.assertEquals(Assert.java:662) ~[testng-6.14.3.jar:?]
> at org.infinispan.tx.ParticipantFailsAfterPrepareTest.testNonOriginatorFailsAfterPrepare(ParticipantFailsAfterPrepareTest.java:90) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-9101) EncryptProtocolIT.testEncryptProtocolRegistered random failures
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-9101?page=com.atlassian.jira.plugin... ]
Tristan Tarrant closed ISPN-9101.
---------------------------------
Fix Version/s: (was: 10.1.0.Final)
Resolution: Out of Date
> EncryptProtocolIT.testEncryptProtocolRegistered random failures
> ---------------------------------------------------------------
>
> Key: ISPN-9101
> URL: https://issues.redhat.com/browse/ISPN-9101
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
>
> {noformat}
> java.lang.RuntimeException: Could not retrieve HotRod host
> at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63)
> Caused by: java.lang.IllegalArgumentException: Could not retrieve attribute HostName on MBean jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport
> at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63)
> Caused by: javax.management.InstanceNotFoundException: jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport
> {noformat}
> The log shows this exception:
> {noformat}
> [0m[31m13:36:29,258 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.datagrid-jgroups.channel.cluster: org.jboss.msc.service.StartException in service jboss.datagrid-jgroups.channel.cluster: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format
> at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:79)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:623)
> at org.infinispan.server.jgroups.JChannelFactory.createChannel(JChannelFactory.java:104)
> at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:77)
> ... 8 more
> Caused by: java.io.IOException: Invalid secret key format
> at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:856)
> at java.security.KeyStore.load(KeyStore.java:1445)
> at org.jgroups.protocols.SYM_ENCRYPT.readSecretKeyFromKeystore(SYM_ENCRYPT.java:97)
> at org.jgroups.protocols.SYM_ENCRYPT.init(SYM_ENCRYPT.java:78)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:840)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:479)
> at org.jgroups.JChannel.init(JChannel.java:992)
> at org.jgroups.JChannel.<init>(JChannel.java:148)
> at org.infinispan.server.jgroups.JChannelFactory.lambda$createChannel$0(JChannelFactory.java:103)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years