incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "O'Keefe, Matthew" <>
Subject RE: critical Mux.start issue
Date Sat, 04 Oct 2008 13:19:43 GMT

We will just patch 2.1, and check out AR2 later.  Thanks...


-----Original Message-----
From: Mark.Hodapp@Sun.COM [mailto:Mark.Hodapp@Sun.COM] 
Sent: Friday, October 03, 2008 3:07 PM
Cc: Antonov, Alex
Subject: Re: critical Mux.start issue


We are unable to produce a patch or a Jini 2.1.1.  Are you able to add  
the patch to the 2.1 source code for your own purposes?  If not, would  
you find AR2 acceptable if testing were completed on what's in AR2 at  
this moment plus this change?  What timeframe do you need AR2 done by  
to meet your needs?

Thank you.



On Oct 2, 2008, at 9:03 PM, O'Keefe, Matthew wrote:

> Thanks, Peter.  Do you suppose that Sun would consider releasing Jini
> 2.1.1 with this patch?  I realize that the community's focus is on
> Apache River at this time, but that codebase is not ready for  
> production
> yet as far as I can tell.
> -Matt
> -----Original Message-----
> From: Peter Jones []
> Sent: Tuesday, August 12, 2008 2:49 PM
> To:
> Cc: Antonov, Alex
> Subject: Re: critical Mux.start issue
> On Mon, Aug 11, 2008 at 11:32:24PM -0500, O'Keefe, Matthew wrote:
>> We have discovered an issue with Jini 2.1 that can cause a client to
>> hang if a service VM enters a bad state.  While this issue is
>> somewhat similar to,
>> the patch that I would like to propose is a bit different, and still
>> applicable to apache-river-2.1.1.
> This issue is in a similar area as RIVER-254, but yes it is different.
> [snipped description of server that accepts connections but never
> responds with any data over them]
>> This caused Mux.start on the client side to hang indefinitely due to
>> a call to Object.wait without a timeout:
> [snip]
>> I would like to see a RemoteException thrown on the client side if
>> Mux.start takes too long to establish a connection.  This would
>> enable us to discard the bad service and retry with another.
> Yes, there definitely should be some sort of timeout supported there
> (as suggested by the code comment).  I think that this was pending
> discussion about a wider range of timeout support in the API (like new
> constraints), which got bogged down in complexity, but that shouldn't
> prevent a simpler (like property-based) timeout being supported here.
>> The patch that I would propose would look like this, except with the
>> hard-coded timeout value changed to a property:
> [snip]
>> Is this a reasonable approach?
> I think so.
> -- Peter
> If you are not the intended recipient of this e-mail message, please  
> notify the sender
> and delete all copies immediately. The sender believes this message  
> and any attachments
> were sent free of any virus, worm, Trojan horse, and other forms of  
> malicious code.
> This message and its attachments could have been infected during  
> transmission. The
> recipient opens any attachments at the recipient's own risk, and in  
> so doing, the
> recipient accepts full responsibility for such actions and agrees to  
> take protective
> and remedial action relating to any malicious code. Travelport is  
> not liable for any
> loss or damage arising from this message or its attachments.

View raw message