It's all about the answers!

Ask a question

IChangeEventHandler::handleEvent called repeatedly...


John Nason (2.4k1012) | asked Apr 27 '09, 5:16 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
I have created an event/event handler pair (IChangeEvent / IChangeEventHandler).
I create the IChangeEvent and save it (once).
My registered event handler (handleEvent on IChangeEventHandler) gets called repeatedly for this event every time the change event task kicks in.

Question: is this intended? I would only like to be called once per instance of an event. Is there a way I can force this behavior by doing something in either the event creation or response to the event?

Thanks,
John

Accepted answer


permanent link
John Nason (2.4k1012) | answered Apr 27 '09, 7:40 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
I think I may have found the answer to my question:
IChangeEventService::delete(event)

If this is not the correct approach then please advise.

I have created an event/event handler pair (IChangeEvent / IChangeEventHandler).
I create the IChangeEvent and save it (once).
My registered event handler (handleEvent on IChangeEventHandler) gets called repeatedly for this event every time the change event task kicks in.

Question: is this intended? I would only like to be called once per instance of an event. Is there a way I can force this behavior by doing something in either the event creation or response to the event?

Thanks,
John
John Nason selected this answer as the correct answer

Comments
scott herzinger commented May 06 '13, 11:25 a.m.

John,

Did you end up concluding that deleting the event was the correct approach to the question of repeating event handler calls? I am seeing the same kind of behavior in my add-snapshot event handler: the handler is called repeatedly, usually 7 times (from data I've captured so far). I have been looking for something that says "you need to do thus-and-such to signal that you are finished handling the event". It did not occur to me to delete the event; for all I know there may be other handlers that want to see the same event. Any advice?

Thanks,
Scott


John Nason commented May 09 '13, 10:19 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

Hi Scott,

In our scenario we were using the change event for a cross component communication mechanism, and we knew once we consumed the event there would be no other interested parties. We did end up deleting the event per my answer above.
Otherwise, the change event will ultimately expire and be scrubbed, but if you know you don't need it any longer I'd delete it. 


Jared Burns commented May 13 '13, 2:09 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

If we're talking about com.ibm.team.process.service.IChangeEventHandler, the behavior described here sounds like a bug. You shouldn't have to delete your change events. Your handler should only be called for each event once.

One other answer



permanent link
scott herzinger (1367) | answered May 13 '13, 1:53 p.m.
Thanks for the info. Do you have any advice (or pointers thereto) on the API for deleting a change event? My expertise with RTC extension development begins and ends with the RTC Extensions Workshop, which is kind of light on the concepts (it's much better on the logistics and scaffolding of RTC plugin development). It's far from obvious (to me) how RTC concepts of Items, Handles, ManagedItems, SimpleItems, Events, and so on all fit together into a coherent model.

One idea I had was to let RTC handle scrubbing the event, by setting the ChangeEvent's expiration time to "now". However, that led to an ImmutablePropertyException (and indeed, event.isImmutable() returns true for the IChangeEvents I see when a snapshot is added to a stream). Some browsing on jazz.net suggests that I may need a "working copy". But again, I'm not finding the information I need to make sense out of these concepts of immutability, nor how to use working copies of various flavors.

Any suggestions or links would be highly appreciated.

And thanks again for your earlier response,
Scott

Your answer


Register or to post your answer.