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.
-Angus
>
> Does that make sense?
>
> thanks,
>
> -K
>
_______________________________________________
Matahari mailing list
Matahari(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/matahari