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?
The last sentence sounds odd because the only point of a correlation id
(in mind) is to get at my user data.
-Angus