Dashboard > Terracotta Developer Documentation > Home > LeftSideBar > L1-L2 JMX Tunneling
  Terracotta Developer Documentation Log In   View a printable version of the current page.  
  L1-L2 JMX Tunneling
Added by Geert Bevin, last edited by Geert Bevin on Feb 19, 2008  (view change)
Labels: 
(None)

From Tim Eck:

To reiterate some from the conversation we had in the team meeting today...The MBeanServer (mbs) in the L2 has proxies to beans that are physically in the L1. When you get one of these proxy beans from the L2 mbs and invoke operations (or get/set attributes, etc), the proxy forwards the request over our comms channel and is performed on the L1 and the result set back.

I don't know for sure, but you should be able to treat the proxy in the L2 just like it was local (with the exception of the network delays). So registering notifications listeners and such should work.

In terms of the code, some interesting things are:

On the L1 side, a thread is started in L1Management.start() that attempts to find the local mbean server, register some beans, and then sends an L1JmxReady message to the L2 over our comms channel in TunnelEventHandler.sendJmxReadyMessageIfNecessary().

The L1JmxReady message is handled on the L2 side in ClientTunnelingEventHandler.handleEvent() which looks like it just enqueues another event (of type L1ConnectionMessage) to connectStage whose handler is ClientConnectEventHandler.handleEvent(). The handling of the L1ConnectionMessage there is interesting -- ClientConnectEventHandler.addJmxConnection the method where the beans on the l1 side are queried and the proxies created and registered to the L2 mbs.

  • The ObjectName of the bean on the L2 is the name as it is registed in L1 plus some info about the client. This line of code does that (ClientConnectEventHandler:120) ObjectName modifiedObjName = TerracottaManagement.addNodeInfo(objName, channel.getRemoteAddress());

  • The query to enumerate the beans on the L1 side is controlled by the expression returned from TerracottaManagement.matchAllTerracottaMBeans()

There's a bunch of other junk that are classes that implement JMX interfaces so that we can do all the message transport and what not.

Anyway, hope this helps. I think the most important thing to know is the beans are proxied so anything you on them is a remote call (even though that aspect is transparent to you).

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.5 Build:#811 Jul 25, 2007) - Bug/feature request - Contact Administrators