Thank you, Daniel and everyone!
I will keep how to make the suitable changeset when next contributions.
Best regards,
Yuji
2018-03-09 1:26 GMT+09:00 Daniel Fuchs :
> Thank you Yuji!
>
> This has been pushed.
>
> For the record - since you are an author, you don't need
> to list your address in t
Thank you Yuji!
This has been pushed.
For the record - since you are an author, you don't need
to list your address in the Contributed-by section as you
already appear as the author of the changeset:
http://hg.openjdk.java.net/jdk/jdk/rev/5447851ff0f6
```
author ykubota
```
best regards,
--
--Original Message-
>> From: KUBOTA Yuji [mailto:kubota.y...@gmail.com]
>> Sent: Donnerstag, 8. März 2018 03:57
>> To: Daniel Fuchs
>> Cc: Langer, Christoph ; Yasumasa Suenaga
>> ; OpenJDK Network Dev list > d...@openjdk.java.net>
>> Subject: Re: httpse
net>
> Subject: Re: httpserver does not close connections when
> RejectedExecutionException occurs
>
> Hi Daniel,
>
> Thank you for your sponsoring!
>
> 2018-03-08 0:56 GMT+09:00 Daniel Fuchs :
> > Could you prepare a final changeset with a properly formatted
Hi Daniel,
Thank you for your sponsoring!
2018-03-08 0:56 GMT+09:00 Daniel Fuchs :
> Could you prepare a final changeset with a properly formatted
> comment [1], use jcheck [2] to verify that your changeset conforms
> to the OpenJDK rules (no trailing whitespaces, no tabs etc...),
> and upload it
On 07/03/18 01:07, KUBOTA Yuji wrote:
..
Nice catch! I removed this unused variable.
http://cr.openjdk.java.net/~ykubota/8169358/webrev.04/
I think is good. Thanks.
-Chris.
Hi Yuji,
On 07/03/2018 01:07, KUBOTA Yuji wrote:
Nice catch! I removed this unused variable.
http://cr.openjdk.java.net/~ykubota/8169358/webrev.04/
Best regards
Yuji
This looks good to me as well. I have imported your patch
and sent it to our test system and things are looking fine.
Could y
-boun...@openjdk.java.net] On Behalf Of
>> KUBOTA Yuji
>> Sent: Donnerstag, 1. März 2018 12:41
>> To: OpenJDK Network Dev list
>> Cc: Yasumasa Suenaga
>> Subject: Re: httpserver does not close connections when
>> RejectedExecutionException occurs
>>
>>
> Cc: Yasumasa Suenaga
> Subject: Re: httpserver does not close connections when
> RejectedExecutionException occurs
>
> Hi all,
>
> Could you please review my patch(s)?
>
> Thanks,
> Yuji
>
> 2018-02-20 14:21 GMT+09:00 KUBOTA Yuji :
> > Hi Daniel
Hi all,
Could you please review my patch(s)?
Thanks,
Yuji
2018-02-20 14:21 GMT+09:00 KUBOTA Yuji :
> Hi Daniel,
>
> Thank you for your comment.
>
> Dispatcher is package-private class and handle method is called at
> only this file in the package (sun.net.httpserver), and all call sites
> look l
Hi Daniel,
Thank you for your comment.
Dispatcher is package-private class and handle method is called at
only this file in the package (sun.net.httpserver), and all call sites
look like to handle exception suitably. So we can remove `throws
IOException` clause without modifying the call site log
Hi,
On the surface I'd say that this change looks reasonable.
However, handle is declared to throw IOException, and
with this change it is guaranteed to never throw even
RuntimeException.
It seems that the code that calls handle() - at least in
this file, has some logic to handle IOException - o
Hi Chris and Yasumasa,
Sorry to have remained this issue for a long time. I come back.
I updated my patch for the following three reasons.
http://cr.openjdk.java.net/~ykubota/8169358/webrev.02/
* applies to the latest jdk/jdk instead of jdk9/dev
* adds test by modifying reproducer as like tests
Hi Chris and Yasumasa,
Thank you for your comments!
I had faced connection leak on production by this handler. It seems
like a corner-case but it's a real risk to me.
I had focused REE on this issue, but it is a subclass of
RuntimeException, so I think that we should investigate
RuntimeException,
> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote:
>
> Hi,
>
>> I think it best to just handle the specific case of REE, as it done in
>> Yuji’s patch.
>
> Will it be a cause of connection leak if RuntimeException is occurred in
> handler method?
No, at least not from this point in the cod
Hi,
I think it best to just handle the specific case of REE, as it done in Yuji’s
patch.
Will it be a cause of connection leak if RuntimeException is occurred in
handler method?
I think we should catch RuntimeException at least.
I think you can use finally statement to close the connectio
> On 9 Nov 2016, at 12:38, Yasumasa Suenaga wrote:
>
> Hi Yuji,
>
>> http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
I think Yuji’s patch is good as is.
> I think you can use finally statement to close the connection in this case.
I don’t believe that this is possible. The handling of
Hi Yuji,
http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
I think you can use finally statement to close the connection in this case.
Your patch cannot close the connection when any other runtime exceptions are
occurred.
However, it is concerned double close if custom handler which is
Hi Chris,
If I can add reproduce code as test, could you please teach me a hint to add it?
Thanks,
Yuji.
2016-11-08 18:53 GMT+09:00 KUBOTA Yuji :
> Hi Chris,
>
> Thank you for your review and updating this issues on JBS.
>
> I filed an issue:
> https://bugs.openjdk.java.net/browse/JDK-8169358
>
Hi Chris,
Thank you for your review and updating this issues on JBS.
I filed an issue:
https://bugs.openjdk.java.net/browse/JDK-8169358
I don't assign to me because I'm not a committer.
2016-11-08 0:28 GMT+09:00 Chris Hegarty :
>> * patch
>> diff --git
>> a/src/jdk.httpserver/share/classes/sun/
Hi Yuji,
On 05/11/16 18:27, KUBOTA Yuji wrote:
Hi all,
com.sun.net.httpserver in jdk9 does not catch
RejectedExecutionException and it does not close connections. We must
catch this exception to close a socket.
Please review the following patch and reproduce steps.
If you agree with that this
Hi all,
com.sun.net.httpserver in jdk9 does not catch
RejectedExecutionException and it does not close connections. We must
catch this exception to close a socket.
Please review the following patch and reproduce steps.
If you agree with that this is an issue of jdk9, I create a new issue
on JBS.
22 matches
Mail list logo
