[JBoss JIRA] (JGRP-2454) Documentation is wrong for ForkChannel creation / Initial messages on fork channel are lost
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2454?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2454:
---------------------------
Fix Version/s: 4.2.1
(was: 4.2.0)
> Documentation is wrong for ForkChannel creation / Initial messages on fork channel are lost
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-2454
> URL: https://issues.redhat.com/browse/JGRP-2454
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.1
>
>
> The documentation at
> http://www.jgroups.org/manual/html/user-advanced.html#ForkChannelCreation
> has the following example:
> {code}
> JChannel main_ch=new JChannel("/home/bela/udp.xml").name("A");
> ForkChannel fork_ch=new ForkChannel(main_ch, "lock", "fork-ch4",
> new CENTRAL_LOCK(), new STATS());
> fork_ch.connect("bla");
> main_ch.connect("cluster");
> {code}
> This does not work as "fork_ch.connect" will throw an IllegalStateException because the main channel is not connected at that point.
> But if the connects are reversed, messages for the fork channel may arrive before the fork channel is fully established and cause warnings like
> {code}
> Feb 20, 2020 6:15:37 PM org.jgroups.protocols.FORK$1 handleUnknownForkChannel
> WARNING: marian-20309: fork-channel for id=fork-ch4 not found; discarding message
> {code}
> My application will send a message to every new member in the cluster on a specific fork channel (in ReceiverAdapter.viewAccepted). These message usually get lost. Is there an alternate pattern for that?
> I can provide example code if required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[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: 5.0
4.2.1
(was: 4.2.0)
> 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: 5.0, 4.2.1
>
>
> 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)
6 years, 2 months
[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: 5.0
4.2.1
(was: 4.2.0)
> 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: 5.0, 4.2.1
>
>
> 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)
6 years, 2 months
[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: 5.0
4.2.1
(was: 4.2.0)
> 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: 5.0, 4.2.1
>
>
> 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)
6 years, 2 months
[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: 5.0
4.2.1
(was: 4.2.0)
> 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: 5.0, 4.2.1
>
> 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)
6 years, 2 months