[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
I don't see any kind of interesting failure or error. Not sure where the problem might be as I'm not sure what SL.war is actually doing. How it's reading messages from queue? I guess it's using {{RemoteConnectionFactory}} to do that so it most likely does not use MDB (message driven beans).
What is interesting is that {{<connection-ttl>-1</connection-ttl>}} in configuration of {{RemoteConnectionFactory}}. Could you set it to 60000ms and try again? With -1 dead connections never timeout.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6797) Is there a way to have more than one logging subystem belonging to one profile
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6797?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-6797:
-----------------------------------
Description:
I have "ha" profile in my domain.xml which has many subsystems.
Below is the structure I have:-
<server-groups>
<server-group name="main-server-group" profile="ha">
<socket-binding-group ref="ha-sockets"/>
<deployments>
<deployment name="RC.war" runtime-name="RC.war"/>
</deployments>
</server-group>
<server-group name="other-server-group" profile="ha">
<socket-binding-group ref="standard-sockets"/>
<deployments>
<deployment name="SL.war" runtime-name="SL.war"/>
</deployments>
</server-group>
</server-groups>
There is a logging subsystem which needs to be different for RC.war and SL.war. Both RC.war and SL.war belong to same profile.
Is there a way to have 2 logging related subsystems defined in "ha" profile, such that RC can point to one and SL to the other although they belong to same profile?
Thanks,
Preeta
> Is there a way to have more than one logging subystem belonging to one profile
> ------------------------------------------------------------------------------
>
> Key: WFLY-6797
> URL: https://issues.jboss.org/browse/WFLY-6797
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Brian Stansberry
>
> I have "ha" profile in my domain.xml which has many subsystems.
> Below is the structure I have:-
> <server-groups>
> <server-group name="main-server-group" profile="ha">
> <socket-binding-group ref="ha-sockets"/>
> <deployments>
> <deployment name="RC.war" runtime-name="RC.war"/>
> </deployments>
> </server-group>
> <server-group name="other-server-group" profile="ha">
> <socket-binding-group ref="standard-sockets"/>
> <deployments>
> <deployment name="SL.war" runtime-name="SL.war"/>
> </deployments>
> </server-group>
> </server-groups>
> There is a logging subsystem which needs to be different for RC.war and SL.war. Both RC.war and SL.war belong to same profile.
>
> Is there a way to have 2 logging related subsystems defined in "ha" profile, such that RC can point to one and SL to the other although they belong to same profile?
> Thanks,
> Preeta
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ]
Kabir Khan reassigned WFCORE-710:
---------------------------------
Assignee: Brian Stansberry (was: Kabir Khan)
> Make ServerOperationResolver handle deployment-overlays similarly to deployments
> --------------------------------------------------------------------------------
>
> Key: WFCORE-710
> URL: https://issues.jboss.org/browse/WFCORE-710
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha2
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha4
>
>
> Currently in domain mode a
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> results in a deployment overlay on ALL servers.
> However for deployments
> {code}
> /deployment=xxx:add(...)
> {code}
> does not get pushed to the servers. This happens when it is associated with a server group:
> {code}
> /server-group=zzz/deployment=xxx:add(...)
> {code}
> Similarly
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> should not get pushed to the servers, until we have a
> {code}
> /server-group=zzz/deployment=yyy:add(...)
> {code}
> which picks out the servers we want to have the overlay
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2065:
--------------------------------
Created a bunch of additional bundlers: {{RingBufferBundler}}, {{RingBufferBundlerLockless}} and {{RingBufferBundlerLockless2}}.
This needs to be revisited in 4.1, but is postponed until then as I need to go back to working on releasing 4.0 (and its API changes).
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1869:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1336088|https://bugzilla.redhat.com/show_bug.cgi?id=1336088] from ON_QA to VERIFIED
> TP.registerProbeHandler not thread safe
> ---------------------------------------
>
> Key: JGRP-1869
> URL: https://issues.jboss.org/browse/JGRP-1869
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization.
> If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers.
> Access to preregistered_probe_handlers should be synchronized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-1911) Use consensus for some subsystems
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1911?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1911:
---------------------------
Fix Version/s: 4.1
(was: 4.0)
> Use consensus for some subsystems
> ---------------------------------
>
> Key: JGRP-1911
> URL: https://issues.jboss.org/browse/JGRP-1911
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
>
> Provide options for several subsystems to run with consensus, e.g.
> * {{SEQUENCER}}
> * {{CENTRAL_LOCK}}
> * {{COUNTER}}
> * {{TOA}}
> * Clustered singletons etc
> For example, with the current impl of distributed counters ({{COUNTER}}), the same counter can be available multiple times if we have a split brain. It is currently up to the user to merge counters with different values after a split brain heals.
> This is OK, but we should provide a second implementation, based on jgroups-raft, which uses consensus to determine the counter maintainer in a split brain scenario. This will forfeit availability in favor of consistency.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Ali Hopyar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Ali Hopyar commented on JGRP-1914:
----------------------------------
Hi Mark,
It is good to hear that.
Thanks for information.
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months