[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.4.Final
(was: 10.1.3.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.4.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)
4 years, 11 months
[JBoss JIRA] (ISPN-11377) Change default flow control protocol back to UFC/MFC
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11377?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11377:
-----------------------------------
Fix Version/s: 10.1.4.Final
(was: 10.1.3.Final)
> Change default flow control protocol back to UFC/MFC
> ----------------------------------------------------
>
> Key: ISPN-11377
> URL: https://issues.redhat.com/browse/ISPN-11377
> Project: Infinispan
> Issue Type: Task
> Components: Configuration, Core
> Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.4.Final, 11.0.0.Alpha2
>
>
> The server default configuration started using {{UFC_NB}} and {{MFC_NB}} in order to avoid blocking on the Netty event loop threads, slowing client requests, and then the core default configurations started using {{UFC_NB}} and {{MFC_NB}} as well with ISPN-9886.
> Unfortunately the _NB variants aren't really non-blocking: they have an extra queue for messages that require more credits, but that queue is limited (2MB by default), and once the queue is full, they also block. They also have much more complex locking than the blocking variants: we actually had to increase max_credits from 2MB to 3MB in order to get the same performance with {{UFC_NB}} that we had with {{UFC}}.
> We're changing the defaults back to {{UFC}} and {{MFC}} while we investigate possible alternatives to avoid blocking.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11383) Upgrade minor deps for Spring for 2.2.x.
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-11383?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-11383:
--------------------------------
Status: Open (was: New)
> Upgrade minor deps for Spring for 2.2.x.
> ----------------------------------------
>
> Key: ISPN-11383
> URL: https://issues.redhat.com/browse/ISPN-11383
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Spring Integration
> Affects Versions: 10.1.2.Final, 11.0.0.Alpha1
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
>
> Upgrade minor versions to be aligned with SB
> from
> <version.spring.boot>2.2.0.RELEASE</version.spring.boot>
> <version.spring.security>5.2.0.RELEASE</version.spring.security>
> <version.spring5>5.2.0.RELEASE</version.spring5>
> <version.spring.session>2.2.0.RELEASE</version.spring.session>
> to
> <version.spring.boot>2.2.4.RELEASE</version.spring.boot>
> <version.spring.security>5.2.2.RELEASE</version.spring.security>
> <version.spring5>5.2.4.RELEASE</version.spring5>
> <version.spring.session>2.2.1.RELEASE</version.spring.session>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months