[JBoss JIRA] (ISPN-11113) ScatteredDelayedAvailabilityUpdateTest takes too long
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11113?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11113:
-----------------------------------
Fix Version/s: 10.1.2.Final
(was: 10.1.1.Final)
> ScatteredDelayedAvailabilityUpdateTest takes too long
> -----------------------------------------------------
>
> Key: ISPN-11113
> URL: https://issues.redhat.com/browse/ISPN-11113
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 10.1.2.Final, 11.0.0.Final
>
>
> Partition handling tests use {{LOCAL_PING.setClusterName()}} with a unique name to disable discovery, otherwise partitions would try to merge while they are supposed to stay separate.
> But {{LOCAL_PING}} uses the cluster name on stop to remove the node from the static discovery map. If the test doesn't change the cluster name back, {{LOCAL_PING}} doesn't remove the node, the next test method sees an existing coordinator, and tries to connect to it. When a test has lots of test methods, like {{ScatteredDelayedAvailabilityUpdateTest}}, each test method leaves one more coordinator in the discovery map, and each test method takes longer to start the first method.
> {noformat}
> 09:08:52,758 DEBUG (testng:[]) [GMS] address=NodeA-30899, cluster=org.infinispan.partitionhandling.ScatteredDelayedAvailabilityUpdateTest[SCATTERED_SYNC, bias=NEVER, DENY_READ_WRITES], physical address=127.0.0.1:51941
> 09:08:52,774 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:08:52,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:08:54,774 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 0
> 09:08:54,774 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-64297
> 09:08:56,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-64297 timed out (after 2000 ms), on try 0
> 09:08:56,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-48475
> 09:08:58,775 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-48475 timed out (after 2000 ms), on try 0
> 09:08:58,775 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-17288
> 09:09:00,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-17288 timed out (after 2000 ms), on try 0
> 09:09:00,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:02,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 0
> 09:09:02,776 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:02,776 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-5606
> 09:09:04,776 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-5606 timed out (after 2000 ms), on try 1
> ...
> 09:09:12,777 TRACE (testng:[]) [GMS] NodeA-30899: discovery took 0 ms, members: 21 rsps (5 coords) [done]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: found multiple coords: [NodeA-2608, NodeA-5606, NodeA-17288, NodeA-64297, NodeA-48475]
> 09:09:12,778 DEBUG (testng:[]) [GMS] NodeA-30899: sending JOIN(NodeA-30899) to NodeA-2608
> 09:09:14,778 WARN (testng:[]) [GMS] NodeA-30899: JOIN(NodeA-30899) sent to NodeA-2608 timed out (after 2000 ms), on try 2
> ...
> 09:09:22,780 WARN (testng:[]) [GMS] NodeA-30899: too many JOIN attempts (3): becoming singleton
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11127) Protocol servers don't pre-start caches when transport is disabled
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11127?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11127:
-----------------------------------
Fix Version/s: 10.1.2.Final
(was: 10.1.1.Final)
> Protocol servers don't pre-start caches when transport is disabled
> ------------------------------------------------------------------
>
> Key: ISPN-11127
> URL: https://issues.redhat.com/browse/ISPN-11127
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.2.Final
>
>
> The various protocol servers have different initialization steps to ensures that caches are pre-started which don't work in all cases. In particular the REST server doesn't pre-start caches and the Hot Rod server pre-starts only if the transport is enabled.
> This should be handled uniformly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11114) NonTxBackupOwnerBecomingPrimaryOwnerTest takes too long
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11114?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11114:
-----------------------------------
Fix Version/s: 10.1.2.Final
(was: 10.1.1.Final)
> NonTxBackupOwnerBecomingPrimaryOwnerTest takes too long
> -------------------------------------------------------
>
> Key: ISPN-11114
> URL: https://issues.redhat.com/browse/ISPN-11114
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 10.1.2.Final, 11.0.0.Final
>
>
> {{NonTxBackupOwnerBecomingPrimaryOwnerTest}} installs a {{LocalTopologyManagerImpl}} to block topology updates, and never stops blocking. That makes cluster shutdown very slow, as each node leaving triggers a topology updates, and since ISPN-10310 the coordinator doesn't spawn a new thread for the topology update.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11170) Infinispan directory does not work with pre-declared indexed entities
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11170?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11170:
-----------------------------------
Fix Version/s: 10.1.2.Final
(was: 10.1.1.Final)
> Infinispan directory does not work with pre-declared indexed entities
> ---------------------------------------------------------------------
>
> Key: ISPN-11170
> URL: https://issues.redhat.com/browse/ISPN-11170
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.2.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 9.4.18.Final, 10.1.2.Final
>
>
> This config combination leads to a circular initialisation dependency of the infinispan directory which has the potential to lead to deadlock, depending on the order the user cache and the infinispan directory's internal caches are started.
> This problem of cache dependencies was always known and the LifecycleManager of query module has code to mitigate it. Unfortunately the code is wrong.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months