add a discovery mechanism to jolokia so its easy to discover JVMs (e.g. via local files, zeroconf/bonjour etc)

[jstrachan]

it'd be nice to support zeroconf to advertise the URLs to connect to jolokia on a machine using this library:
http://jmdns.sourceforge.net/

then folks could discover and connect to jolokia based JVMs more easily; e.g. there are pure C / ObjectiveC / JavaScript clients of zeroconf available

[jstrachan]

as a more concrete use case, a Chrome App of hawtio could then discover all the Jolokia machines locally :)
https://chrome.google.com/webstore/detail/hawtio/oklhjflkljcklphooeahnbfbmfelacib

[jstrachan]

incidentally its long bugged me that there's not an easier way to discover JVMs with jolokia inside; even if we use the hawtio-local-jvm-mbean to use the com.sun.tools.attach stuff in the JDK to discover local JVMs with JMX access; its still rare we are able to find the jolokia URL from those (the system properties trick often doesn't work); so am liking being able to publish the jolokia URL so its easy to auto-discover.

I understand this would be a little bit more code to add to an agent; but its not that much and can be a totally optional plugin for jolokia. (e.g. adding jmdns adds 205k which isn't much really)

[jstrachan]

have a little spike of this implemented; will tidy it up a little before sending a PR. Its basically an extra optional plugin class with 1 extra class added to the core where we can register / unregister the locations as/when we know (currently the JVM agent is the only implementation)

[rhuss]

Sorry for the delay, I got ill over the weekend, but will have a look at it tomorrow ASAP. Looking forwar to the PR ...

[jstrachan]

the cute thing about this plugin is it means jolokia agents appear in the Safari Bonjour menu ;) Just trying to figure out how to register correctly, so the links in the Safari browser menu actually work...

[jstrachan]

@rhuss btw get well soon!

[jstrachan]

ok I've added a first PR. I'm not completely happy with the ZeroConf code (its adding a 200K library, and not 100% sure the absolutely correct way to register into ZeroConf; plus things seem to hang around in ZeroConf for a while).

So I tried a really simple (1 class) implementation which just uses a jolokiaDiscovery folder in the machines tmp directory that periodically writes a little text file with the URL and name of the agent; then removes any old files as a really simple discovery mechanism. Added a little MBean API too - so from 1 Jolokia agent you can discover all the others too.

Currently only the JVM agent is supported; its a bit tricky figuring out the URL for servlet/osgi agents; I'll try ponder a nice way to do that

[jstrachan]

we could mark the zeroconf stuff as experimental or move to a sandbox maybe; I'm now more keen on a simple file based implementation to be honest; its simple, has minimal effect on the library size and is easy to work with

[rhuss]

I have an initial implementation using a simple multicast for discovery nearly ready. Beside the URL the discovery response also additional information about the detector server (vendor, product, version), the Jolokia version, whether authentication is required or not and the 'reliance level' as a percentage value (100% sure means that the URL is valid for sure which is true for the JVM agent, a lower value can mean its an "educated guess" e.g. for servlet based installations).

This first version will be comitted soon (at the weekend, sorry have not much time available for Jolokia recently). I will pick a fixed MC address and port which "Organization Local Scope". Since I don't have much experience about MC scopes at all (as defined in RFC2365), i hope this is fine.

If you have any idea how to get the agent URL from a servlet I would be glad to add this to the servlet initialization as well (of course, if being behind an HTTP proxy this is probably quite hard). AFAIK one can extract the URL from an HttpRequest, but for this to work one would need to catch a request first. Maybe I can do some lazy stuff here, hmmm.

[jstrachan]

Awesome! :) I owe you many beers, even more than before now!

That all sounds perfect - I'll try figure out a way to do the servlet URL issue; I guess worst case there's env vars and system properties if we really have to (and we can update it once we've had a request in).

Many many thanks!

[rhuss]

Here is the (prelimiary, but not changing much) setup for the mulitcast messages:

• MC address and port is 239.192.48.84 (IPv4, for IPv6 I still need to look for the proper address), port 24884.
• A request is an UDP Datagram with the following content (UTF-8 encoding):

    type:query

• For such a request a response is sent back to the source of the incoming packet with a content like

    type:response
    url:http://myaddress:8080/jolokia
    confidence:100
    secured:true
    server_vendor:Apache
    server_product:Tomcat
    server_version:7.0.50
    version:1.1.6-SNAPSHOT

• Every agent listening on the multicast socket will respond correspondingly. It might be, that a name and/or id will be added, too. (don't know yet).

[rhuss]

Closed, discovery feature is now included since version 1.2.0