On Fri, May 13, 2011 at 6:15 AM, Angus Salkeld <asalkeld(a)redhat.com> wrote:
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(a)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?
Yes.
The last sentence sounds odd because the only point of a correlation id
(in mind) is to get at my user data.
You want a call_id so that you can determine the order in which
actions were initiated.
You don't necessarily want to go looking for things like expected rc
because the operation might outlive you and/or you might not be the
only client - so you'd want to put that stuff into the user data.
Which now that I think of it, is a good reason to make (at least)
expected_rc a parameter.