[
https://jira.jboss.org/jira/browse/JGRP-1184?page=com.atlassian.jira.plug...
]
Richard Achmatowicz commented on JGRP-1184:
-------------------------------------------
5. Because every probe handler sends its own message, we can now get more messages that
the number of channels in a process. This is rather confusing. For example, when I call
probe on EAP 5.0.1:
Call with no arguments:
#1 (231 bytes):
member=127.0.0.1:45036 (DefaultPartition)
local_addr=127.0.0.1:45036
cluster=DefaultPartition
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#2 (265 bytes):
member=127.0.0.1:45036 (DefaultPartition-HAPartitionCache)
local_addr=127.0.0.1:45036
cluster=DefaultPartition-HAPartitionCache
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#3 (249 bytes):
member=127.0.0.1:45036 (DefaultPartition-JMS-CTRL)
local_addr=127.0.0.1:45036
cluster=DefaultPartition-JMS-CTRL
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#4 (245 bytes):
member=127.0.0.1:7900 (DefaultPartition-JMS-DATA)
local_addr=127.0.0.1:7900
cluster=DefaultPartition-JMS-DATA
view=[127.0.0.1:7900|0] [127.0.0.1:7900]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
Call with one argument:
[nrla@localhost bin]$ ./probe.sh keys
-- send probe on /224.0.75.75:7500
#1 (231 bytes):
member=127.0.0.1:45036 (DefaultPartition)
local_addr=127.0.0.1:45036
cluster=DefaultPartition
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#2 (88 bytes):
local_addr=127.0.0.1:7900
cluster=DefaultPartition-JMS-DATA
keys=dump keys jmx info
#3 (265 bytes):
member=127.0.0.1:45036 (DefaultPartition-HAPartitionCache)
local_addr=127.0.0.1:45036
cluster=DefaultPartition-HAPartitionCache
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#4 (245 bytes):
member=127.0.0.1:7900 (DefaultPartition-JMS-DATA)
local_addr=127.0.0.1:7900
cluster=DefaultPartition-JMS-DATA
view=[127.0.0.1:7900|0] [127.0.0.1:7900]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
#5 (134 bytes):
local_addr=127.0.0.1:45036
cluster=DefaultPartition-JMS-CTRL
keys=jmx info requests requests requests jmx info dump keys jmx info
#6 (249 bytes):
member=127.0.0.1:45036 (DefaultPartition-JMS-CTRL)
local_addr=127.0.0.1:45036
cluster=DefaultPartition-JMS-CTRL
view=[127.0.0.1:45036|0] [127.0.0.1:45036]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 belaban Exp
$"
Total responses=6, 6 matches, 0 non-matches
Perhaps its not so easy to collect together all reponses from each of the ProbeHandler
calls for a single channel, but it would improve output in my view.
Some issues with Probe
----------------------
Key: JGRP-1184
URL:
https://jira.jboss.org/jira/browse/JGRP-1184
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.13
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Priority: Minor
In the wiki
http://community.jboss.org/wiki/Probe, changes to the operation of the
DiagnosticsHandler which appear in 2.7+ are described. The changes revolve around
(i) changing the request format for probe requests from -query <query key> to
key(=value) strings
(ii) allowing channels to register probe handlers to process the key,value pairs now
passed in requests
There are a few issues with probe.sh in JGroups 2.6.13 which i'd like to list here. I
discovered these issues while testing the probe.sh script in EAP 5.1. Some of the issues
i'm running into:
1. probe.sh user interface has changed in 2.6.13, and not just 2.7+
- the documentation in the wiki leads one to believe that 2.6.13 should be able to handle
the old probe.sh message format, but the old messages seem to have been deprecated
- the help text associated with the probe.sh command for 2.6.13 does not well reflect the
change in user interface. There is no mention of key value pairs, for example; just keys.
2. Matched statistics are not appearing at the end of the probe.sh output
- when probe.sh terminates, I should see something like:
Total responses=1, 1 matches, 3 non-matches
This reflects how many responses were matched with the -match <match string>
parameter. 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.
3. The new request format is based on supplying key or key=value pairs in probe requests
in order to extract specific information from channels. However, there is no clean way to
obtain the set of keys available. I had to look at the source code to discover that the
following keys are registered:
* by Channel -> registers keys "jmx=protocol" (which returns JMX statistics
for the protocol value) and "info" (which returns the value of
Protocol.getInfo())
* by MessageDispatcher -> registers keys requests (which returns a list of pending RPC
requests for which replies have not been received)
* by TP -> registers keys "dump" (which returns a thread dump on that
channel) and "keys" (which returns a list of all registered keys on that
channel)
This seems to be undocumented and might be better provided by way of a command option
-get_defined_keys or something like that.
4. Output presentation could be improved
- I found the presentation of output was for each received diagnostics response was hard
to read, unlike the previous version of probe where the output was was divided up into
stats:
...
props:
...
and was easy to read.
--
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