On Thu, May 12, 2011 at 02:49:52PM +0200, Andrew Beekhof wrote:
On Thu, May 12, 2011 at 1:20 AM, Angus Salkeld asalkeld@redhat.com wrote:
The method call model is a request-response pattern that really only provides for a single response to the request. As you suggested, you can use events to augment that pattern. Specifically, the agent may start issuing events in response to the method call, either before or after the response is sent. Depending on your needs, you could have the equivalent of a "Start Events"/"Stop Events" method pair, or hold off the response until all events are doing being generated.
Related to this, how do I turn off a repeating (interval>0) monitor?
One minor point - the correlation id that is returned to the client is guaranteed to be unique only for the method call/response period. Once the response is received, that id _may_ be recycled for future requests (very unlikely, but I wouldn't recommend counting on it). So I would suggest that your method call take a unique identifier that your application provides. All events that correlate to that method call could contain that identifier, so you don't rely on having the correlation id be unique over the lifetime of your application.
So it looks like we need the IO handle Russell posted.
Only if events/replies don't include the name, action and interval values. We do need an atomically increasing call_id O field and a user_data IO field, but not for correlation.
Is this increasing field a sequence number?
The last sentence sounds odd because the only point of a correlation id (in mind) is to get at my user data.
-Angus