There are situations, where a deployment of an Jolokia agent on the target platform is not possible. This might be for political reasons or an already established JSR-160 export on the instrumented servers. In these environments, Jolokia can operate as a JMX Proxy. In this setup, the agent is deployed on a dedicated proxy Java EE server (or other supported agent platform). The proxy bridges between Jolokia JSON request and responses to remote JSR-160 calls to the target server. The following diagrams gives an illustration of this setup.
A Jolokia proxy is universal and agnostic to the target server as it gets its information for the target via an incoming request (the same as for an HTTP proxy). Due to this required extended information, only Jolokia POST requests can be used for proxying since there is currently no way to encapsulate the target information within a GET Url. The base Jolokia URL for the request is that of the proxy server, whereas the target parameters are included in the request. In the next example, a proxied Jolokia request queries the number of active threads for a server jboss-as via a proxy tomcat-proxy, which has an agent deployed under the context jolokia. The agent URL then is something like
http://jolokia-proxy:8080/jolokia
and the POST payload of the request is
{ "type":"READ" "mbean":"java.lang:type=Threading", "attribute":"ThreadCount", "target": { "url":"service:jmx:rmi:///jndi/rmi://jboss-as:8686/jmxrmi", "password":"admin", "user":"s!cr!t" }, }
The target is part of the request and can contain authentication information as well (with params user and password)
Operating Jolokia as a JMX proxy has some limitations compared to a native agent deployment: