[JBoss JIRA] Created: (JGRP-1188) Probe.sh does not display matches summary on termination.
by Richard Achmatowicz (JIRA)
Probe.sh does not display matches summary on termination.
---------------------------------------------------------
Key: JGRP-1188
URL: https://jira.jboss.org/jira/browse/JGRP-1188
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.7
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Priority: Minor
Fix For: 2.4.8
Matched statistics are not appearing at the end of the probe.sh output
- when probe.sh, with the -match option specified, terminates, I should only see responses which contain the match string, and should see a summary line something like:
Total responses=1, 1 matches, 3 non-matches
This reflects how many responses were matched with the -match <match string> parameter.
For example:
[rachmatowicz@vmg18 bin]$ ./probe.sh -match Tomcat-Cluster
-- send probe on /224.0.75.75:7500
#1 (262 bytes): 10.16.95.19:44066 (Tomcat-Cluster)
local_addr=10.16.95.19:44066
group_name=Tomcat-Cluster
version=2.4.7.GA, cvs="$Id: Version.java,v 1.42.2.14 2009/11/03 23:15:25 rachmatowicz Exp $"
view: [10.16.95.19:44066|0] [10.16.95.19:44066]
group_addr=239.11.12.13:45577
Here, the responses were correctly matched, but no summary line is produded.
This summary line is not appearing, because a thread set up to close the multicast socket after timeout seconds is causing the multicast socket to generate an exception and return, before the control loop can be exited and the summary line printed. Moving the summary line into the exception handling code fixes the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBAS-8169) Make default values of org.jboss.metadata.IorSecurityConfigMetaData configurable
by Dimitris Andreadis (JIRA)
Make default values of org.jboss.metadata.IorSecurityConfigMetaData configurable
--------------------------------------------------------------------------------
Key: JBAS-8169
URL: https://jira.jboss.org/browse/JBAS-8169
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: IIOP service
Affects Versions: 6.0.0.M3, JBossAS-5.1.0.GA, JBossAS-4.2.2.GA
Reporter: Dimitris Andreadis
Assignee: Stefan Guilhen
User wants to allow the configuration of all IOR default parameters that are hard coded in org.jboss.metadata.IorSecurityConfigMetaData ([SasContext : callerPropagation] and [AsContext : authMethod, realm, required] and [TransportConfig : integrity, confidentiality, detectMisordering, detectReplay, establishTrustInTarget, establishTrustInClient]).
Mostly they want to be able to configure [AsContext : realm] and [SasContext : callerPropagation]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JGRP-1243) FD_SOCK: reduce number of messages sent on a suspicion
by Bela Ban (JIRA)
FD_SOCK: reduce number of messages sent on a suspicion
------------------------------------------------------
Key: JGRP-1243
URL: https://jira.jboss.org/browse/JGRP-1243
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.10.1, 2.11
- When B suspects C, B multicasts a SUSPECT(C) message
- Everyone receives the SUSPECT(C) message and passes it up and down the stack as a SUSPECT(C) event
- VERIFY_SUSPECT *on every member* sends one (or more) ARE_YOU_DEAD messages to C
- C replies to the sender with a I_AM_NOT_DEAD messages, or not if crashed
- However, only the coordinator (or next in line) actually processes the SUSPECT(C) event in GMS !
--> All of the VERIFY_SUSPECT processing is superfluous unless it is the coord or next-in-line !
The number of messages used for a false suspicion are (1 SUSPECT mcast) + ((N-1) ARE_YOU_DEAD unicasts) + ((N-1) I_AM_NOT_DEAD unicasts)) !
SOLUTION:
- The SUSPECT(C) message could be sent as a unicast only to the coordinator and the next-in-line member. Maybe we could use a max_rank=2 for this, similar to the suggested solution for FD_ALL ? This would be good for non multicast based transports, e.g. TCP
- The SUSPECT(C) message is multicast to everyone, but only the coord and next-in-line start the VERIFY_SUSPECT processing
Issue: if we have {A,B,C,D,E}, what happens if A,B and C crash at the same time ?
- E's connection to A closes: E sends a SUSPECT(A) to B and C (excluding suspected A)
--> B and C are dead and won't process the message !
- Then E suspects B and sends a SUSPECT(A,B) to C and D (excluding suspected A and B)
- C adds A and B to its suspect list and finds out it is the next-in-line
- C then runs the VERIFY_SUSPECT protocol
- C passes the SUSPECT(A,B) event up the stack
- C becomes the new coord
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months