[ http://jira.jboss.com/jira/browse/JBREM-827?page=all ] David Lloyd updated JBREM-827: ------------------------------ Fix Version/s: Remoting 3 M3 (was: Remoting 3 M2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBREM-827?page=all ] David Lloyd updated JBREM-827: ------------------------------ Fix Version/s: 3.1.0.GA (was: 3.0.0-M3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-827: ----------------------------------- I think at a minimum we should have: - Counters: - Requests processed by endpoint and by connection - Requests rejected by endpoint and by connection - Clients opened by endpoint and connection - Management operations: - Examine & administrative close of connections (graceful and force close) - Examine registered services That's what I can think of offhand. There's probably more stuff we can add as needed. -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-827: ------------------------------ Fix Version/s: 3.1.0.Beta2 (was: 3.1.0.Beta1) -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-827: ------------------------------ Fix Version/s: 3.1.0.Beta3 (was: 3.1.0.Beta2) -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] Trustin Lee commented on JBREM-827: ----------------------------------- Here's the draft: http://anonsvn.jboss.org/repos/jbossremoting/remoting3/trunk/jboss-remoti... There are two MXBeans: EndpointMXBean and ConnectionMXBean. They are almost identical except that ConnectionMXBean has close/forceClose operations while EndpointMXBean does not and that you can list the registered services with EndpointMXBean while you can't with ConnectionMXBean. They both provide some counters via the Counters object. Once agreed, I will finish documentation. One missing piece though is how we register an MBean for a connection. We could register all EndpointMXBeans automatically but we can't do that for Connections because there will be much more connections and registering that many connections will probably pollute the JMX console with overinformation. What user wants might be to register only the ConnectionMXBeans that meet some criteria..? Long time ago, I wrote a JMX operation that accepts some expression so that only the MBeans that meets the specified condition, but I'm not sure it's a good idea since it's a lot of work. -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-827: ----------------------------------- Also, an idea occurs to me - for the Remote protocol, we might want to track authentication failures (client & server). I'm not sure how we'd want to present that info though. -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] Trustin Lee edited comment on JBREM-827 at 3/25/10 1:22 AM: ------------------------------------------------------------ If the number of connections are expected to be small, it might be fine as you said. As long as we have an option that disables JMX exports, it will be fine. Authentication failures could be represented as rejected clients? (i.e. clientCounters.failure) What information else could be provided by EndpointMXBean / ConnectionMXBean by the way? A user might want to know where exactly the endpoint / connection is pointing at. Will the MBean object name be enough? was (Author: trustin): If the number of connections are expected to be small, it might be fine as you said. As long as we have an option that disables JMX exports, it will be fine. Authentication failures could be represented as rejected clients? (i.e. clientCounters.failure) What information else could be provided by EndpointMXBean / ConnectionMXBean by the way? A user might want to know where exactly the endpoint is pointing at or what the client ID is in a connection. Will the MBean object name be enough? -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] Trustin Lee commented on JBREM-827: ----------------------------------- Then maybe we could add connectionCounters? +1 for not registering local connections. If we need to provide the information for connections, we could add ConnectionInfo like I did for ServiceInfo. What attribute would you suggest other than the connection ID and its timestamp? -- 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

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] Trustin Lee commented on JBREM-827: ----------------------------------- I've just checked in the revised interfaces. ServiceInfo has been replaced with ServiceMXBean. Each registered services will have its own ServiceMXBean. I added requestCounter to it so that the number of requests can be tracked in per-service manner. EndpointMXBean now has connectionCounter as proposed previously. It also exposes the list of ObjectNames of services and connections. ConnectionMXBean and ServiceMXBean also exposes the ObjectName of the EndpointMXBean they belong to. For IP-based transports, we could include the endpoint address in the MBean object name? -- 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