[JBoss JIRA] (ISPN-9028) Write-only segments should be invalidated during the READ_NEW phase
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9028?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9028:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> Write-only segments should be invalidated during the READ_NEW phase
> -------------------------------------------------------------------
>
> Key: ISPN-9028
> URL: https://issues.jboss.org/browse/ISPN-9028
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Final
>
>
> When a rebalance removes a segment X from node A, node A keeps updating entries in segment X until the rebalance finishes, and only deletes the entries of segment X after entering the NO_REBALANCE phase.
> This is problematic for tests that work with the data container directly, because {{waitForNoRebalance()}} doesn't wait for the removal of stale entries. The test will work without an explicit wait most of the time, so this is a recipe for random test failures (e.g. ISPN-8728).
> As described in ISPN-5021, we can prevent any writes to segment X at the start of the READ_NEW_WRITE_ALL phase, send the phase confirmation to the coordinator, and then remove the entries asynchronously. We just need to keep track of the removal task and only install/confirm the NO_REBALANCE phase once all the entries that we don't own have been removed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9018) SslTest.testClientAuth random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9018?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9018:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> SslTest.testClientAuth random failures
> --------------------------------------
>
> Key: ISPN-9018
> URL: https://issues.jboss.org/browse/ISPN-9018
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Final
>
>
> The test fails with a timeout exception. There is probably more, but before ISPN-9017 is fixed gathering logs is too difficult.
> {noformat}
> 09:34:03,524 DEBUG (testng-Test:[]) [ChannelFactory] Creating new channel pool for 127.0.0.1:12411
> 09:34:09,732 INFO (testng-Test:[]) [RemoteCacheManager] ISPN004021: Infinispan version: null
> 09:34:13,823 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.SslTest.testClientAuth
> org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: FaultTolerantPingOperation{(default), flags=0} timed out after 3000 ms
> at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:50) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.Util.await(Util.java:25) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:472) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:736) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:312) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:201) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:195) ~[classes/:?]
> at org.infinispan.client.hotrod.SslTest.initServerAndClient(SslTest.java:103) ~[test-classes/:?]
> at org.infinispan.client.hotrod.SslTest.testClientAuth(SslTest.java:131) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9017) HotRod client thread names should include the test name
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9017?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9017:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> HotRod client thread names should include the test name
> -------------------------------------------------------
>
> Key: ISPN-9017
> URL: https://issues.jboss.org/browse/ISPN-9017
> Project: Infinispan
> Issue Type: Task
> Components: Hot Rod, Test Suite - Server
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> I wanted to obtain a trace log for a {{SslTest}} failure I'm seeing locally, but when I filter by test name all I get is this:
> {noformat}
> 09:34:03,524 DEBUG (testng-Test:[]) [ChannelFactory] Creating new channel pool for 127.0.0.1:12411
> 09:34:09,732 INFO (testng-Test:[]) [RemoteCacheManager] ISPN004021: Infinispan version: null
> 09:34:13,823 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.SslTest.testClientAuth
> org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: FaultTolerantPingOperation{(default), flags=0} timed out after 3000 ms
> at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:50) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.Util.await(Util.java:25) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:472) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:736) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:312) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:201) ~[classes/:?]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:195) ~[classes/:?]
> at org.infinispan.client.hotrod.SslTest.initServerAndClient(SslTest.java:103) ~[test-classes/:?]
> at org.infinispan.client.hotrod.SslTest.testClientAuth(SslTest.java:131) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8890) TransactionXaAdapter does not implement Geronimo's NamedXaResource
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8890?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8890:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> TransactionXaAdapter does not implement Geronimo's NamedXaResource
> ------------------------------------------------------------------
>
> Key: ISPN-8890
> URL: https://issues.jboss.org/browse/ISPN-8890
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.CR2
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Geronimo uses its own interface for logging transaction resources, {{NamedXAResource}}. Our {{TransactionXaAdapter}} doesn't implement it, so this error is logged for each transaction in Karaf:
> {noformat}
> 2018-02-28T09:49:05,931 | ERROR | testng-TransactionsSpanningReplicatedCachesTest-9 | Transaction | 68 - org.apache.aries.transaction.manager - 1.3.3 | Please correct the integration and supply a NamedXAResource
> java.lang.IllegalStateException: Cannot log transactions as TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=[Xid:globalId=ffffff96ffffff9561ffffffdb611006f72672e6170616368652e61726965732e7472616e73616374696f6e0000000000000000000000000000,length=64,branchId=1000ffffff84ffffff9561ffffffdb611006170616368652e61726965732e7472616e73616374696f6e0000000000000000000000000000,length=64]} LocalTransaction{remoteLockedNodes=[TransactionsSpanningReplicatedCachesTest-NodeS-28818, TransactionsSpanningReplicatedCachesTest-NodeT-4724], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[a], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.xa.LocalXaTransaction@1f} is not a NamedXAResource.
> at org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java:781) ~[?:?]
> at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:287) ~[?:?]
> at org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java:467) ~[?:?]
> at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:312) ~[?:?]
> at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252) ~[?:?]
> at Proxy325c2276_ef50_4396_9e7d_5deaa002f72c.commit(Unknown Source) ~[?:?]
> at org.infinispan.tx.TransactionsSpanningReplicatedCachesTest.runTest(TransactionsSpanningReplicatedCachesTest.java:260) ~[?:?]
> at org.infinispan.tx.TransactionsSpanningReplicatedCachesTest.testDefaultCacheAndNamedCacheSameNode(TransactionsSpanningReplicatedCachesTest.java:240) ~[?:?]
> at org.infinispan.it.osgi.tx.TransactionsSpanningReplicatedCachesTest.testDefaultCacheAndNamedCacheSameNode(TransactionsSpanningReplicatedCachesTest.java:91) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9173) Availability mode should be updated atomically with the actual members
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9173?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9173:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> Availability mode should be updated atomically with the actual members
> ----------------------------------------------------------------------
>
> Key: ISPN-9173
> URL: https://issues.jboss.org/browse/ISPN-9173
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Final
>
>
> This is a follow-up on ISPN-7682, which asks for the topology itself to be updated atomically.
> {{LocalTopologyManagerImpl}} has additional logic to update the availability mode first when the cache becomes degraded and to update it last when the cache becomes available, which means any delay between the updates cannot cause data inconsistencies.
> But that logic doesn't really belong in {{LocalTopologyManagerImpl}}, and it's easy to forget it's there (and in fact we had a bug there related to the new rebalance phases).
> In addition, tests that want to check the cache behaviour in degraded mode and wait only for the availability mode change will fail if there's a big delay between the availability mode change. I actually hit this while testing my ISPN-8731/ISPN-7682 changes, and I had added a random delay in {{StateConsumerImpl}} before {{distributionManager.setCacheTopology()}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9161) Description of StateTransferManager attributes does not match the behaviour or show wrong content
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9161?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9161:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> Description of StateTransferManager attributes does not match the behaviour or show wrong content
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-9161
> URL: https://issues.jboss.org/browse/ISPN-9161
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Documentation-Core
> Reporter: Wolf-Dieter Fink
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
> Attachments: Screenshot from 2018-05-16 10-01-28.png
>
>
> Current description is:
> If true, the node has successfully joined the grid and is considered to hold state. If false, the join process is still in progress..
> But the behaviour is:
> It doesn't wait for the initial state transfer, it just waits for the coordinator to send it a topology before joinComplete is set to TRUE
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month