RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

[Julia Boes]

Hi,

The tests in java/net/httpclient/PathSubscriber don't grant certain file 
permissions to test library classes. The tests succeed by chance when 
the compiled library classes are placed under ${test.classes}, but 
occasionally they fail, depending on which test target compiles the 
library first. This fix adds a FilePermission to the test/lib code base 
to cover all cases.


Bug: https://bugs.openjdk.java.net/browse/JDK-8246431

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.00/

Cheers,

Julia

RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

[Patrick Concannon]

Hi,

Could someone please review my patch for JDK-8246132 - 
'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException' ?

AsynchronousSocketChannelNAPITest sometimes fails with a 
NotYetConnectedException while trying to read data after connecting. This is 
fix changes the connect method to use a CompletionHandler to wait for the 
connection to be made before reading.

issue: https://bugs.openjdk.java.net/browse/JDK-8246132 

webrev: http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.00/ 



Kind regards,
Patrick

Re: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

[Daniel Fuchs]

Hi Julia,

Thanks for taking care of this.

Your propose changes look good to me.

best regards,

-- daniel

On 04/06/2020 17:24, Julia Boes wrote:

Hi,

The tests in java/net/httpclient/PathSubscriber don't grant certain file 
permissions to test library classes. The tests succeed by chance when 
the compiled library classes are placed under ${test.classes}, but 
occasionally they fail, depending on which test target compiles the 
library first. This fix adds a FilePermission to the test/lib code base 
to cover all cases.


Bug: https://bugs.openjdk.java.net/browse/JDK-8246431

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.00/

Cheers,

Julia

Re: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

[Daniel Fuchs]

Hi Patrick,

Looks good, but for one thing.

Throwing in the failed() callback will probably accomplish
nothing since that is likely be called asynchronously in some
background thread. So if the connect doesn't succeed immediately
but fail instead at a later time, the test will block forever
waiting on the CountDownLatch until it gets interrupted by
the jtreg timeout.

Instead of using a CountDownLatch, I'd suggest using a
CompletableFuture which will allow to rethrow
the exception from the main thread.

best regards,

-- daniel


On 04/06/2020 17:55, Patrick Concannon wrote:

Hi,

Could someone please review my patch for JDK-8246132 - 
*'AsynchronousSocketChannelNAPITest failing with a 
NotYetConnectedException'* ?


AsynchronousSocketChannelNAPITest sometimes fails with a 
NotYetConnectedException while trying to read data after connecting. 
This is fix changes the connect method to use a CompletionHandler to 
wait for the connection to be made before reading.


issue: https://bugs.openjdk.java.net/browse/JDK-8246132
webrev: http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.00/


Kind regards,
Patrick

Re: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

[Alan Bateman]

On 04/06/2020 22:08, Daniel Fuchs wrote:

Hi Patrick,

Looks good, but for one thing.

Throwing in the failed() callback will probably accomplish
nothing since that is likely be called asynchronously in some
background thread. So if the connect doesn't succeed immediately
but fail instead at a later time, the test will block forever
waiting on the CountDownLatch until it gets interrupted by
the jtreg timeout.

Instead of using a CountDownLatch, I'd suggest using a
CompletableFuture which will allow to rethrow
the exception from the main thread.
Might be simpler to just change it to c.connect(remote).get(); to that 
it blocks until the connect is established (or it fails), no need to use 
the 3-arg connect method here.


-Alan