Re: [wsrp-coord] Fault handling with handleEvents

[Subbu Allamaraju <subbu@bea.com>]

Few comments below.

Subbu

Rich Thompson wrote:
> 
> I agree this is an area that still needs development. As to your questions:
> 
> a. The Producer is required to process the events in the order they are 
> received. The sending of an array is simply an optimization over 
> receiving each of them individually. The Consumer is not required to 
> dispatch events in the order they are received as it may want to apply 
> logic that reorders the events, inserts ones it generates itself or even 
> decides to not distribute a particular event.

I'm not sure if we should/can require this. Depending on how producer is 
implemented it may or may not be able preserve the order.

> b. I think the question about whether all events should be processed or 
> the first fault encountered returned is a nontrivial one. I would tend 
> toward having the Producer process all the events and have a means in 
> the return to indicate faults encountered and whether or not processing 
> was aborted.

I like this route, but we may need some means of identifying each event 
(like an ID) so that we can correlate processing errors with incoming 
events.

> c. The requirement is that the events be processed in the order 
> received. I think it might be a stretch to claim that can be 
> parallelized. I also suspect that most platforms do not require portlet 
> developers to write re-entrant code ...

I agree. But we should explicitly state that the Producer MUST NOT 
process events concurrently.

> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 10/19/2004 10:54 AM
> 
> 	
> To
> 	wsrp-coord@lists.oasis-open.org
> cc
> 	
> Subject
> 	[wsrp-coord] Fault handling with handleEvents
> 
> 
> 	
> 
> 
> 
> 
> 
> I would like to discuss if we need to be more specific about fault
> handling  of handleEvents.
> 
> Problem: Unlike performBlockingInteraction, the Producer processes one
> or more events during handleEvents and any fault returned from the
> Producer may vary from implementation to implementation.
> 
> Scenario: A Producer receives a batch of events via handleEvents. Of
> these, the first event requires state changes, but the Consumer sent a
> readOnly flag. The second event requires some security permissions not
> allowed for the current user. Whether the Consumer receives a
> StateChangeRequired fault or AccessDenied fault depends on the order
> Producer processes these events.
> 
> My questions:
> 
> a. Is the Producer required to process the events in the order the
> Consumer supplied those events? Note that we do not require Consumers to
> dispatch events in the order they were fired.
> 
> b. Should the Producer process both events and return two faults (as
> errors in normal output, as in destroyPortlets)? This may sound bizarre,
> but I would like to bring it up for the sake of argument since
> handleEvents may be considered as a multi-input operation like
> destroyPortlets.
> 
> c. Is the Producer allowed to process incoming events concurrently? We
> don't specify anything about it currently, but shouldn't we?
> 
> Regards,
> 
> Subbu
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php.
> 
>