Looks good Daniel. Good catch with the timeout ordering bug.
- Michael
On 11/04/2017, 12:51, Daniel Fuchs wrote:
Hi,
Please find below a new webrev that fixes an additional timeout
ordering issue I discovered while testing:
http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.02/
While d
> On 11 Apr 2017, at 12:51, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a new webrev that fixes an additional timeout
> ordering issue I discovered while testing:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.02/
Thanks for going the extra mile on this one. Good catch, an
Hi,
Please find below a new webrev that fixes an additional timeout
ordering issue I discovered while testing:
http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.02/
While doing some further tests after incorporating Chris's feedback
I noticed that the new test and the TimeoutOrdering tes
> On 7 Apr 2017, at 17:51, Daniel Fuchs wrote:
>
> Hi Chris,
>
> Here is the new webrev - where I have incorporated your feedback.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.01/
Looks good to me Daniel.
-Chris.
Hi Chris,
Here is the new webrev - where I have incorporated your feedback.
http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.01/
If I don't hear from you that's what I plan to push on Monday.
best regards,
-- daniel
On 07/04/2017 15:12, Daniel Fuchs wrote:
On 07/04/2017 14:31, Chris
On 07/04/2017 14:31, Chris Hegarty wrote:
Daniel,
On 06/04/17 11:32, Daniel Fuchs wrote:
...
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.00/
Looks good Daniel. Just a few comments.
1) Http1Exchange.java
Can 'operations' now be made private, and not a synchronizedList
Daniel,
On 06/04/17 11:32, Daniel Fuchs wrote:
...
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.00/
Looks good Daniel. Just a few comments.
1) Http1Exchange.java
Can 'operations' now be made private, and not a synchronizedList?
Now that it is operated on only within
On 06/04/2017 14:23, Pavel Rappo wrote:
Though it indeed jumps out on you. Could we use an iterator here and rely
on its remove implementation, since we know the implementation of the list?
We could - there's another loop earlier in this file that uses
an index (line 713) - so I just choose to
> On 6 Apr 2017, at 14:08, Daniel Fuchs wrote:
>
> Return is needed here because 1. we are removing something from the
> list, so after that the next values of 'i' will be invalid, and 2.
Yeah, that would be my second question :-) But you explained the purpose,
so no problem here. Thanks.
Tho
On 06/04/2017 14:08, Daniel Fuchs wrote:
The only reason I touched this method is because I noticed the
possibility of ConcurrentModificationException if we reached there.
Well - now that I think about it again CME would probably not have
happened with the old code either since we broke out of
Hi Pavel,
Thanks for taking a look!
On 06/04/2017 13:28, Pavel Rappo wrote:
Heya Daniel,
750 /**
751 * same as above but for errors
752 */
753 void completeResponseExceptionally(Throwable t) {
754 synchronized (response_cfs) {
755 /
Heya Daniel,
750 /**
751 * same as above but for errors
752 */
753 void completeResponseExceptionally(Throwable t) {
754 synchronized (response_cfs) {
755 // use index to avoid ConcurrentModificationException
756 // caus
Hi,
While analyzing some of the later failure traces reported for
https://bugs.openjdk.java.net/browse/JDK-8170940
8170940: test/java/net/httpclient/TimeoutOrdering.java
failing intermittently
I began to suspect that this was not caused by a test bug.
Looking at the timeout handling cod
13 matches
Mail list logo
