You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by "O'Keefe, Matthew" <MO...@orbitz.com> on 2008/10/03 03:03:15 UTC
RE: critical Mux.start issue
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:peter.jones@sun.com]
Sent: Tuesday, August 12, 2008 2:49 PM
To: river-dev@incubator.apache.org
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.
RE: critical Mux.start issue
Posted by "O'Keefe, Matthew" <MO...@orbitz.com>.
Mark-
We will just patch 2.1, and check out AR2 later. Thanks...
-Matt
-----Original Message-----
From: Mark.Hodapp@Sun.COM [mailto:Mark.Hodapp@Sun.COM]
Sent: Friday, October 03, 2008 3:07 PM
To: river-dev@incubator.apache.org
Cc: Antonov, Alex
Subject: Re: critical Mux.start issue
Matt,
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.
Regards,
Mark
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 [mailto:peter.jones@sun.com]
> Sent: Tuesday, August 12, 2008 2:49 PM
> To: river-dev@incubator.apache.org
> 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.
>
>
Re: critical Mux.start issue
Posted by Mark Hodapp <Ma...@Sun.COM>.
Matt,
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.
Regards,
Mark
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 [mailto:peter.jones@sun.com]
> Sent: Tuesday, August 12, 2008 2:49 PM
> To: river-dev@incubator.apache.org
> 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.
>
>