January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2416) Native image: test IPv6 addresses

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2416?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2416: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Native image: test IPv6 addresses > --------------------------------- > > Key: JGRP-2416 > URL: https://issues.redhat.com/browse/JGRP-2416 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Currently, we're using IPv4 because of flag {{-J-Djava.net.preferIPv4Stack=true}} in the generation of the native image with GraalVM. > Remove this flag and test IPv6 addresses with UDP, TCP and TCP_NIO2. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2410) TestNG: upgrade to 7.0.0

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2410?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2410: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > TestNG: upgrade to 7.0.0 > ------------------------ > > Key: JGRP-2410 > URL: https://issues.redhat.com/browse/JGRP-2410 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > There were some issues running the stack-dependent tests in 7.0.0, that's why I reverted to 6.14.3. Need to revisit this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2404) Better configuration sanity checks

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2404?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2404: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Better configuration sanity checks > ---------------------------------- > > Key: JGRP-2404 > URL: https://issues.redhat.com/browse/JGRP-2404 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Investigate whether more sanity checks can be applied to a configuration, e.g. missing UNICAST3 when TCP is configured etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2430: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > GossipRouter: more efficient routing > ------------------------------------ > > Key: JGRP-2430 > URL: https://issues.redhat.com/browse/JGRP-2430 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address. > It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages. > Investigate whether this is possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2403) Dump information in panic scenarios

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2403?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2403: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Dump information in panic scenarios > ----------------------------------- > > Key: JGRP-2403 > URL: https://issues.redhat.com/browse/JGRP-2403 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > When there is a panic situation (e.g. thread pool exhausted), dump information to a file at FATAL level. > Also dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. > These files can be sent to support via an SOS report. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2374?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2374: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > TCP/TCP_NIO2: add TLS > --------------------- > > Key: JGRP-2374 > URL: https://issues.redhat.com/browse/JGRP-2374 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > Add TLS to the TCP and TCP_NIO2 transports. Look into wildfly-openssl [1] for the impl. > [1] https://github.com/wildfly-security/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2412) GMS: reduce likelyhood of merges on concurrent new member startup

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2412?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2412: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > GMS: reduce likelyhood of merges on concurrent new member startup > ----------------------------------------------------------------- > > Key: JGRP-2412 > URL: https://issues.redhat.com/browse/JGRP-2412 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > When multiple new members are started concurrently, and no coord is present yet, different clients get different discovery results, and this may lead to merging. > If we have no coord, we could run the discovery protocol multiple time, *with the current members list being cached*, and then might end up with a more similar list of new members. > This could be governed by an additional attribute in {{Discovery}} ({{num_discovery_runs}}?) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2402) SOS report

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2402?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2402: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > SOS report > ---------- > > Key: JGRP-2402 > URL: https://issues.redhat.com/browse/JGRP-2402 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Add the ability to dump the most important attributes to a file / log (configurable), e.g.: > * Max threads > * Number of rejected messages > * Size of retransmission tables (NAKACK2, UNICAST3) > This can be used to diagnose issues by telling the customer to invoke this command and attach the resulting file to a ticket -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2406: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > MERGE3 not working with TCP using ForkJoinPool > ---------------------------------------------- > > Key: JGRP-2406 > URL: https://issues.redhat.com/browse/JGRP-2406 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Olivier Peyrusse > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > Attachments: logs.tgz, project.zip, timeline.txt > > > With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3. > I consistently observed the following, from the point of view of a member M > - M asks for other coordinator views. It contacts A and B > - A and B send their views > - M waits and timeouts for receiving views and abort the merge > - immediately after aborting the merge, M process messages containing the views of A and B. > In [^timeline.txt], you will see the extracts for logs from the various members at play. > After many experiments, the one parameter causing this issue is in the TCP protocol. > {code:xml} > <TCP > ... > thread_pool.use_fork_join_pool="true" /> > {code} > Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine. > Project details: > - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol > - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs. > - [^logs.tgz] contains all logs from the various members involved in the test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2413) Probe: get rid of 'jmx' and 'op'

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2413?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2413: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Probe: get rid of 'jmx' and 'op' > -------------------------------- > > Key: JGRP-2413 > URL: https://issues.redhat.com/browse/JGRP-2413 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > Instead of {{probe.sh jmx=NAKACK2.level}} -> {{probe.sh NAKACK2.level}} and > {{probe.sh op=UNICAST3.dumpRoutingTable}} -> {{UNICAST3.dumpRoutingTable}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020