[JBoss JIRA] (ISPN-10938) Expose data store metrics
by Diego Lovison (Jira)
Diego Lovison created ISPN-10938:
------------------------------------
Summary: Expose data store metrics
Key: ISPN-10938
URL: https://issues.jboss.org/browse/ISPN-10938
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 10.0.1.Final
Reporter: Diego Lovison
Allow expose data store metrics.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10937) CleanupAfterMethod tests take a very long time
by Dan Berindei (Jira)
Dan Berindei created ISPN-10937:
-----------------------------------
Summary: CleanupAfterMethod tests take a very long time
Key: ISPN-10937
URL: https://issues.jboss.org/browse/ISPN-10937
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 10.0.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.1.0.Beta1
Because of JGRP-2398, every time the cluster is stopped and re-created the new coordinator first tries to connect to the old coordinator:
{noformat}
13:53:39,024 DEBUG (testng-Test:[]) [GMS] address=Test-NodeA-57106, cluster=org.infinispan.partitionhandling.Test, physical address=127.0.0.1:55320
13:53:39,026 TRACE (testng-Test:[]) [GMS] Test-NodeA-57106: discovery took 0 ms, members: 17 rsps (4 coords) [done]
13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, Test-NodeA-37104, Test-NodeA-8303]
13:53:39,026 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca
13:53:41,026 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca timed out (after 2000 ms), on try 0
...
13:53:45,027 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
13:53:47,027 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 0
...
13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: found multiple coords: [054b27e3-9308-65bf-de26-d6cdd4f6bdd3, 6d7f9fb2-f56b-1b88-7f9d-cdee430ac8ca, 0eb381de-3e9a-0320-b2d9-5db3cb39bb34, Test-NodeA-8303]
13:54:51,036 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3
13:54:53,036 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to 054b27e3-9308-65bf-de26-d6cdd4f6bdd3 timed out (after 2000 ms), on try 9
...
13:54:57,037 DEBUG (testng-Test:[]) [GMS] Test-NodeA-57106: sending JOIN(Test-NodeA-57106) to Test-NodeA-8303
13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: JOIN(Test-NodeA-57106) sent to Test-NodeA-8303 timed out (after 2000 ms), on try 9
13:54:59,037 WARN (testng-Test:[]) [GMS] Test-NodeA-57106: too many JOIN attempts (10): becoming singleton
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10929) ClusterPublisher reduction combineStages concurrency level is too high
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10929?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10929:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.0.Beta1
Resolution: Done
> ClusterPublisher reduction combineStages concurrency level is too high
> ----------------------------------------------------------------------
>
> Key: ISPN-10929
> URL: https://issues.jboss.org/browse/ISPN-10929
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> The combineStages method in ClusterPublisherImpl currently uses flatMap without an explicit concurrency level. That means it will subscribe to up to 128 futures at the same time. This isn't a problem when only in memory is used as the stages are completed as they are received. However when a segmented store is in play, this means it will process 128 segments at the same time, even when doing sequential publisher.
> We should instead limit the concurrency to the cpuCount when the publisher is parallel and just 1 when it is sequential. The latter matches how many threads the upstream publisher will use as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months