Enhancing dtest Instrumentor class to not work only for localhost

[ochaloup]

I would like to enhance ability of dtest helper to not work only on localhost. Currently what I can see in code Instrumentor class creates a java rmi registry which sits on test side. In my case I start a JBoss app server which I need to monitor and get information about called classes and their methods back to the test. Byteman helper as being part of JBoss jvm tries to locate the registry and it connects to localhost.

I would like to have the same ability but for JBoss servers started on different machines as well.

I would like to reuse connection properties (host and port) which is used in byteman Submit method and with the same data being able to connect to the dtest Helper and let the Helper to pass calling statistics back to test over this opened channel. It's needed to have statistics stored on test side as it's more than possible that JBoss server will be crashed as part of test execution.

First do you think there is some chance to tweak java rmi communication to provide such functionality?

My follow-up idea is to use plain java sockets to do such thing. What do you think?

Now my concerns in Byteman engine itself.

For this would work I would need to get a byteman callback for helper at point when a rule with my helper is introduced to byteman. At that point the test (client using Instrumentor class) needs to establish connection. But by my experimentation I got to the fact that the helper callbacks activated and installed are executed when rule is firstly triggered. Am I correct in this observation? Do I have some chance to get a helper code being called right after the rule is delivered to byteman? A workaround which came to my mind was to put the jar with helper to JBoss classpath to be loaded by jvm and initialization of the socket waiting for the incoming 'test channel' would be done in static part in the class. But I'm here quite unsure about classloading and visibility. Plus I doubt if it's a good way how to do it that way.

Thank you for any comment or idea.

ondra

[adinn]

Hi Ondra,

Ondra Chaloupka wrote:

I would like to enhance ability of dtest helper to not work only on localhost. Currently what I can see in code Instrumentor class creates a java rmi registry which sits on test side. In my case I start a JBoss app server which I need to monitor and get information about called classes and their methods back to the test. Byteman helper as being part of JBoss jvm tries to locate the registry and it connects to localhost.

I would like to have the same ability but for JBoss servers started on different machines as well.

I would like to reuse connection properties (host and port) which is used in byteman Submit method and with the same data being able to connect to the dtest Helper and let the Helper to pass calling statistics back to test over this opened channel. It's needed to have statistics stored on test side as it's more than possible that JBoss server will be crashed as part of test execution.

First do you think there is some chance to tweak java rmi communication to provide such functionality?

My follow-up idea is to use plain java sockets to do such thing. What do you think?

I think the best way to do this would be to continue to use RMI. It is supposed to allow calls to be made between processes on different hosts. So you should be able to configure the test process to advertise its RMI registry on a public interface (TCP IP host + port) and have the dtest ByetmanHelper call back to that host by supplying a hostname and port in the RMI registry lookup. However, I don't really know enough about how RMI works to be able to advise how to get the RMI server set up so as to allow it to communicate using a public interface. The javadoc on the RMI clssses doesn't help much  (it may just be that you need to supply a TCP Socket Factory?). I suggest you try to find i) resources on the web explaining how to do it or ii) someone inside JBoss who knows about RMI (Ron Sigal? David Lloyd?).

You cannot use the Submit port to communicate the data you want without a significant rewrite of the AgentListener class. So that really is not an option.

You could change dtest so that it implements its own TCP listener and client socket communication link. However, that means you then need to implement your own remote procedure call (RPC) mechanism on top of the TCP connection. Of course, you don't have to have a general RPC mechanism but even so it doesn't sound like a good idea implementing even a very basic RPC model when RMI is already available.

Ondra Chaloupka wrote:

Now my concerns in Byteman engine itself.

For this would work I would need to get a byteman callback for helper at point when a rule with my helper is introduced to byteman. At that point the test (client using Instrumentor class) needs to establish connection. But by my experimentation I got to the fact that the helper callbacks activated and installed are executed when rule is firstly triggered. Am I correct in this observation? Do I have some chance to get a helper code being called right after the rule is delivered to byteman? A workaround which came to my mind was to put the jar with helper to JBoss classpath to be loaded by jvm and initialization of the socket waiting for the incoming 'test channel' would be done in static part in the class. But I'm here quite unsure about classloading and visibility. Plus I doubt if it's a good way how to do it that way.

The static methods you are referring to (activated and installed) are exactly what you would need to use (assuming you go the way of having the client establish the connection -- I'm not sure you need to worry about this if you stick to RMI). They are documented in the Programmer's Guide under the topic of Life Cycle Management (along with the related lifecycle methods deactivated and uninstalled).  Read the section in the Guide first and then come back to me if you have any questions regarding how it works.

regards,

Andrew Dinn