[jboss-jira] [JBoss JIRA] Commented: (JGRP-1184) Some issues with Probe

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 Fix For: 2.6.15, 2.10 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.