river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: RemoteEvent specification - proposal
Date Thu, 17 Apr 2014 12:25:00 GMT

Hi Peter:

You should probably create a JIRA enhancement ticket to track discussion if you’re picturing
adding some kind of order-guaranteeing comparator to the API.  But I don’t think you really
need to do that, because the usage would be so dependent on the client’s architecture that
it probably isn’t sensible to put it in the API.

On the actual question, I’d suggest that Reggie should make no guarantees on the order of
event delivery (as per the event spec).  That being the case, imposing some kind of order
is a client problem, not Reggie’s.  I would suggest modifying the test simply to ensure
that all the expected events have been received in the required time, regardless of the order.
 Perhaps also add some clarification to the service registrar spec.

Cheers,

Greg Trasuk.

On Apr 17, 2014, at 7:30 AM, Peter <jini@zeus.net.au> wrote:

> 
> 
> From: Peter <jini@zeus.net.au>
> Subject: RemoteEvent specification - proposal
> Date: April 17, 2014 at 7:28:13 AM EDT
> To: dev@apache.river.org
> Reply-To: Peter <jini@zeus.net.au>
> 
> 
> The Jini Remote Event specification clearly states that remote events may arrive out
of order, yet some lookup tck tests in the qa test suite require events to arrive in order.

> 
> Presently I have an Executor in Reggie, used specifically for sending event notifications,
however it is single threaded, to ensure events arrive in an order identical to client registration,
to avoid qa test failures. 
> 
> I propose creating a comparator clients can use to order events as they arrive. This
will allow qa tests, when utilising this comparator, to pass when Reggie is configured to
use a multi threaded event notifier executor. This would increase Reggie's scalability for
event notifications. 
> 
> Thoughts? 
> 
> Regards, 
> 
> Peter. 
> 
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message