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

Mon Apr 5 18:48:37 EDT 2010

    [ https://jira.jboss.org/jira/browse/JGRP-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12523860#action_12523860 ] 

Richard Achmatowicz commented on JGRP-1184:
-------------------------------------------

6. When I use the key "info", I get a frag_size field being returned:

W:\RACHMA~1\jboss-eap-5.0\jboss-as\bin>probe.bat -bind_addr 10.16.94.200
24.1.75.75 info
-- send probe on /224.1.75.75:7500
#1 (262 bytes):
member=10.16.94.200:1863 (DefaultPartition)
local_addr=10.16.94.200:1863
cluster=DefaultPartition
view=[10.16.94.200:1863|0] [10.16.94.200:1863]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 ...n Exp $"
info=frag_size=60000

#2 (280 bytes):
member=10.16.94.200:1863 (DefaultPartition-JMS-CTRL)
local_addr=10.16.94.200:1863
cluster=DefaultPartition-JMS-CTRL
view=[10.16.94.200:1863|0] [10.16.94.200:1863]
version=2.6.13.GA, cvs="$Id: Version.java,v 1.59.2.27 2009/09/25 11:32:35 ...n Exp $"
info=frag_size=60000

I'm not really sure where this frag_size is coming from, as from what I can tell, the transports don't define such a key in their maps returned by getInfo(). Or I could be mistaken. 

> 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