Add support for custom MBean "ifModified" handling

[rhuss]

Since the list operation on Jolokia is quite expensive (or can be quite expensive), adding a new query parameter ifModified (or so) should be added. This parameter has a handle which was returned from a previous list call (still to think how to integrate it into the handle into the response, probably an extra field 'handle' in the response itself). The Jolokia agent (or more specific, the ListHandler) listens for notifications about MBeans added or removed and increases the handle/counter internally.

For a request with ifModified parameter it

• returns the requested list if the provided handle differs from the internal handle
• returns an empty value with status code "304 Not Modified" if the list hasn't changed.

The same could be implemented for search, too, however this request shouldn't as expensive as list so it is probably not needed here.

[rhuss]

Maybe even better: Use the standard HTTP-Header If-Modified-Since instead of an extra query paramter and use a real HTTP return code.

Advantages:

• Standard
• Doesn't add to API / protocol bloat

Disadvantages:

• Yet another place to add parameters (but we already use HTTP-Headers for CORS support)
• Quite some refactoring necessary so that the ListHandler has access to the HTTP headers
• Clients need to be updated, too which is more complicated than simply adding an extra processing option. Also the client API must then cope with empty HTTP responses.
• What about bulk requests (an single HTTP return code doesn't work here) ?

Especially because of bulk requests, a query options / processing parameter is more suitable.

[rhuss]

The parameter should probably called 'ifModifiedSince' and the handle should be the timestamp as it is returned with every response, so there is no need to add an extra key to the response.

[rhuss]

The core functionality for the LIST operation has been implemented (and soon also for SEARCH). BTW, this works for all MBeanServers present in the JVM, not only for a single MBeanServer. However, I wonder whether this feature could be even expanded for other kinds of operations. In fact, I could imagine, that when the parameter ifModifiedSince is given for a READ or EXEC request and the MBean to be called has exposed an operation

boolean hasModifiedSince(long timestamp,String operationType,String name,Object[] args)

then this operation will be called with the timestamp given in the request. If this operation return true nothing changes and the request processing continues as usual. If it returns false then the client gets a 304 - Not Modified response with no value. That way, expensive operation (in time and/or size) can be easily optimized without much extra work.

Then, when using the JavaScript scheduler and using a new option onlyIfChanged when registering the job, the callback functions will only be called when something has changed (this will all be done transparently under the hoods):

jolokia.register({sucess: cbFunc, onlyIfChanged: true}, request);

Is this something useful or is optimizing the list (which is indeed an expensive operation) sufficient and I should avoid the extra complexity for checking MBean freshness ?

[rhuss]

The Javascript Scheduler has been updated, so that the described functionality works now, i.e. that a callback is only called when the servers returns an value-response.

Still open:

• MBean Interface for READ and EXEC to call in case of a given ifModifiedSince config option (difficulty: How to deal with pattern reads ? Probably include only changed values for each bean, but howto signal this in the response ? Is there a dedicated HTTP status code for such a situation, something like 'partially successful' or so ?)
• SEARCH support

[rhuss]

Maybe one should move the open task out of this issue since most of the stuff has been already implemented ?