New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for custom MBean "ifModified" handling #77

Open
rhuss opened this Issue Mar 1, 2013 · 5 comments

Comments

Projects
None yet
1 participant
@rhuss
Owner

rhuss commented Mar 1, 2013

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

This comment has been minimized.

Owner

rhuss commented Mar 1, 2013

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

This comment has been minimized.

Owner

rhuss commented Mar 2, 2013

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

This comment has been minimized.

Owner

rhuss commented Mar 8, 2013

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 ?

@ghost ghost assigned rhuss Mar 8, 2013

rhuss added a commit that referenced this issue Mar 15, 2013

rhuss added a commit that referenced this issue Mar 16, 2013

rhuss added a commit that referenced this issue Mar 16, 2013

@rhuss

This comment has been minimized.

Owner

rhuss commented Mar 17, 2013

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 added a commit that referenced this issue Mar 17, 2013

Updated reference manual JS "onlyIfModifed"
The reference manual has been updated for the onlyIfModified Option for
j4p.register() in the JavaScript Client Library (#77)

rhuss added a commit that referenced this issue Mar 17, 2013

@rhuss

This comment has been minimized.

Owner

rhuss commented Jul 13, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment