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 [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 2:49 PM To: [email protected] 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 http://issues.apache.org/jira/browse/RIVER-254, > 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.
