[JBoss JIRA] (JGRP-1810) Illegal format string in trace message in NAKACK2 protocol
by Chris LeCompte (JIRA)
[ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.... ]
Chris LeCompte commented on JGRP-1810:
--------------------------------------
Shouldn't the my_highest_received(%) be changed to my_highest_received(%d) as well?
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
> Key: JGRP-1810
> URL: https://issues.jboss.org/browse/JGRP-1810
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Reporter: Chris LeCompte
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
> log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
> local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error. The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1810) Illegal format string in trace message in NAKACK2 protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1810:
---------------------------
Fix Version/s: 3.4.4
(was: 3.5)
The issue doesn't occur in 3.2 because we're not using format strings and in 3.5 because it has been fixed there, only in 3.4.x.
Fixed in 3.4.4
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
> Key: JGRP-1810
> URL: https://issues.jboss.org/browse/JGRP-1810
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Reporter: Chris LeCompte
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
> log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
> local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error. The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1810) Illegal format string in trace message in NAKACK2 protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1810.
----------------------------
Resolution: Done
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
> Key: JGRP-1810
> URL: https://issues.jboss.org/browse/JGRP-1810
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Reporter: Chris LeCompte
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
> log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
> local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error. The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1810) Illegal format string in trace message in NAKACK2 protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1810 at 3/24/14 12:17 PM:
----------------------------------------------------------
You meant replace {{%d}} (not {{%%}}) didn't you ?
was (Author: belaban):
You meant replace {{%s}} (not {{%%}}) didn't you ?
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
> Key: JGRP-1810
> URL: https://issues.jboss.org/browse/JGRP-1810
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Reporter: Chris LeCompte
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
> log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
> local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error. The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1810) Illegal format string in trace message in NAKACK2 protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1810?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1810:
--------------------------------
You meant replace {{%s}} (not {{%%}}) didn't you ?
> Illegal format string in trace message in NAKACK2 protocol
> ----------------------------------------------------------
>
> Key: JGRP-1810
> URL: https://issues.jboss.org/browse/JGRP-1810
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Reporter: Chris LeCompte
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> The NAKACK2 protocol has an invalid format string in one of its trace logging outputs:
> log.trace("%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s",
> local_addr, my_hr, hr, member + "#" + hr);
> This results in an error in the log:
> ERROR - Illegal format string "%s: my_highest_rcvd (%) < stability_highest_rcvd (%): requesting retransmission of %s"
> The % should be changed to %% to avoid the error. The arguments are in fact printed alongside the message however anything with ERROR in the text makes QA nervous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1811) Arithmetic Exception in MPerf when sending less than 10 messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1811?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1811.
----------------------------
Resolution: Done
> Arithmetic Exception in MPerf when sending less than 10 messages
> ----------------------------------------------------------------
>
> Key: JGRP-1811
> URL: https://issues.jboss.org/browse/JGRP-1811
> Project: JGroups
> Issue Type: Bug
> Reporter: Andrei Palade
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Not sure if this is intended to be like this, but in MPerf when the user tries to set the num_msg to 1 and start sending the messages, MPerf throws
> Mar 22, 2014 4:02:25 PM org.jgroups.logging.JDKLogImpl error
> SEVERE: failure unmarshalling buffer
> java.lang.ArithmeticException: / by zero
> at org.jgroups.tests.perf.MPerf.handleData(MPerf.java:418)
> at org.jgroups.tests.perf.MPerf.receive(MPerf.java:280)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:890)
> at org.jgroups.JChannel.up(JChannel.java:746)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.SEQUENCER.deliver(SEQUENCER.java:606)
> at org.jgroups.protocols.SEQUENCER.unwrapAndDeliver(SEQUENCER.java:573)
> at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:279)
> at org.jgroups.protocols.SEQUENCER.up(SEQUENCER.java:308)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:520)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:927)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:857)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:792)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:573)
> at org.jgroups.protocols.BARRIER.up(BARRIER.java:152)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:296)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1532)
> at org.jgroups.protocols.TP$3.run(TP.java:1466)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1136) Common mechanism for all secure socket definitions
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-1136:
-----------------------------------
Brain dump article collecting together the related pieces: -
https://community.jboss.org/docs/DOC-52501
> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
> Key: WFLY-1136
> URL: https://issues.jboss.org/browse/WFLY-1136
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1809) New discovery protocol to be used in conjunction with SHARED_LOOPBACK
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1809?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1809.
----------------------------
Resolution: Done
> New discovery protocol to be used in conjunction with SHARED_LOOPBACK
> ---------------------------------------------------------------------
>
> Key: JGRP-1809
> URL: https://issues.jboss.org/browse/JGRP-1809
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Sometimes tests in the testsuite fail because the nodes run over SHARED_LOOPBACK fail to discover each other and therefore don't form a cluster. This can happen because discovery requests sent via PING are discarded on a full thread pool.
> Because the default test stack doesn't have a MERGE protocol, members won't get merged back.
> h5. GOAL
> * Create a discovery protocol which always discovers other members registered with the same cluster
> h5. SOLUTION
> * Instead of using SHARED_LOOPBACK to send and receive discovery requests, query SHARED_LOOPBACK directly for discovery information. E.g. if we have members A,B,C registered with cluster "demo" in SHARED_LOOPBACK, then a node D joining can fetch (via SHARED_LOOPBACK_PING) the PingData of A, B and C directly from SHARED_LOOPBACK.
> * This way, we won't have any failed test cases (run over SHARED_LOOPBACK) which fail because no other members were discovered. Also, discovery (even for the first node started in a cluster) is very fast, and we don't need the timeout at all.
> * Also, we don't need to add a MERGE protocol to the stack as merging is not needed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1812:
-------------------------------------------
By the way, this is what I see on a passing run:
{noformat}
------------- testSharedTransport -----------
43652 [WARN] UDP: - JGRP000014: the receive buffer of socket MulticastSocket was set to 500KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
-------------------------------------------------------------------
GMS: address=A, cluster=cluster-one, physical address=10.3.239.189:56487
-------------------------------------------------------------------
47050 [TRACE] GMS: - A: no initial members discovered: creating group as first member
47051 [DEBUG] GMS: - A: installing view [A|0] [A]
47052 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
-------------------------------------------------------------------
GMS: address=B, cluster=cluster-two, physical address=10.3.239.189:56487
-------------------------------------------------------------------
50326 [TRACE] GMS: - B: no initial members discovered: creating group as first member
50327 [DEBUG] GMS: - B: installing view [B|0] [B]
50328 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
[A]<< hello-0
[B]<< hello-0
[A]<< hello-1
[B]<< hello-1
[A]<< hello-2
[B]<< hello-2
[A]<< hello-3
[B]<< hello-3
[A]<< hello-4
[B]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
[A]<< hello-9
50832 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view)
50833 [TRACE] GMS: - view [A|1] [] is empty: will not multicast it (last view)
{noformat}
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
> Key: JGRP-1812
> URL: https://issues.jboss.org/browse/JGRP-1812
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.14
> Environment: RHEL, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1812:
-------------------------------------------
One example of output from a failed instance of the test:
{noformat}
------------- testSharedTransport -----------
-------------------------------------------------------------------
GMS: address=A, cluster=cluster-one, physical address=10.16.92.26:49627
-------------------------------------------------------------------
111009 [TRACE] GMS: - A: no initial members discovered: creating group as first member
111009 [DEBUG] GMS: - A: installing view [A|0] [A]
111010 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
-------------------------------------------------------------------
GMS: address=B, cluster=cluster-two, physical address=10.16.92.26:49627
-------------------------------------------------------------------
112579 [TRACE] GMS: - A: new members=[A], suspected=[], leaving=[], new view: [A|1] [A, A]
112579 [TRACE] GMS: - A: mcasting view [A|1] [A, A] (2 mbrs)
112580 [DEBUG] GMS: - A: installing view [A|1] [A, A]
112581 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
112611 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
114019 [TRACE] GMS: - B: initial_mbrs are B
114019 [DEBUG] GMS: - election results: {}
114019 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759]
114019 [TRACE] GMS: - clients to choose new coord from are: [B, B]
114019 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator
[A]<< hello-0
[A]<< hello-1
[A]<< hello-2
[A]<< hello-3
[A]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
[A]<< hello-9
116116 [TRACE] GMS: - A: new members=[], suspected=[], leaving=[A], new view: [A|2] [A]
116116 [TRACE] GMS: - A: mcasting view [A|2] [A] (1 mbrs)
116116 [DEBUG] GMS: - A: installing view [A|2] [A]
116118 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
117529 [TRACE] GMS: - B: initial_mbrs are B
117529 [DEBUG] GMS: - election results: {}
117529 [TRACE] GMS: - could not determine coordinator from responses [B, view_id=, is_server=false, is_coord=false, logical_name=B, physical_addrs=10.16.92.90:53759]
117529 [TRACE] GMS: - clients to choose new coord from are: [B, B]
117529 [TRACE] GMS: - I (B) am not the first of the clients, waiting for another client to become coordinator
121039 [TRACE] GMS: - B: no initial members discovered: creating group as first member
121039 [DEBUG] GMS: - B: installing view [B|0] [B]
121039 [DEBUG] GMS: - created group (first member). My view is [B|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
[A]<< hello-0
[A]<< hello-1
[A]<< hello-2
[A]<< hello-3
[A]<< hello-4
[A]<< hello-5
[A]<< hello-6
[A]<< hello-7
[A]<< hello-8
121040 [WARN] NAKACK2: - JGRP000011: B: dropped message 1 from non-member B (view=[B|0] [B]) (received 5 identical messages from B in the last 0 ms)
[A]<< hello-9
[B]<< hello-0
[B]<< hello-1
[B]<< hello-2
[B]<< hello-3
[B]<< hello-4
131043 [TRACE] GMS: - view [B|1] [] is empty: will not multicast it (last view)
131043 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
{noformat}
I'm not quite sure what the discovery arrangements are for shared transport nor the mapping of channel names to memberships. It's a little hard to follow :-)
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
> Key: JGRP-1812
> URL: https://issues.jboss.org/browse/JGRP-1812
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.14
> Environment: RHEL, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months