[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.2
(was: 5.0)
(was: 4.2.1)
> 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.2
>
>
> 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, 4 months
[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.2
(was: 5.0)
(was: 4.2.1)
> 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.2
>
>
> 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.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 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: 4.2.2
(was: 5.0)
(was: 4.2.1)
> 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.2
>
>
> 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, 4 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: 4.2.2
(was: 5.0)
(was: 4.2.1)
> 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.2
>
>
> When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) 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, 4 months
[JBoss JIRA] (WFLY-13210) open-tracing layer must depend on microprofile-config
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13210?page=com.atlassian.jira.plugi... ]
Jean Francois Denise commented on WFLY-13210:
---------------------------------------------
The stack when deploying a simple JAXRS deployment inside a server that contains open-tracing but not mp-config.
Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125)
at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110)
at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:91)
at org.wildfly.microprofile.opentracing.smallrye.TracerDynamicFeature.configure(TracerDynamicFeature.java:49)
at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:111)
at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:351)
at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:278)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:229)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:201)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:187)
at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:164)
at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:81)
at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:485)
at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:286)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:92)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
... 8 more
> open-tracing layer must depend on microprofile-config
> -----------------------------------------------------
>
> Key: WFLY-13210
> URL: https://issues.redhat.com/browse/WFLY-13210
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2435.
----------------------------
Resolution: Done
[~dan.berindei] Do you want me to release 4.2.1?
> ClientGmsImpl ignores newer view during join
> --------------------------------------------
>
> Key: JGRP-2435
> URL: https://issues.redhat.com/browse/JGRP-2435
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.1
>
>
> We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed.
> The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out.
> I added some logs in TP and GMS for debugging, and this is what I see:
> {noformat}
> 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC]
> 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB
> 1:
> #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### GmsImpl.handleViewChange() {}
> 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD]
> 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> ### The ack for the JOIN_RSP is only sent here
> 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest]
> 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2
> {noformat}
> To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months