Re: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

2014-12-05 Thread Vincent Ryan
Changes look fine to me Rob.
Thanks.


On 5 Dec 2014, at 05:17, Rob McKenna  wrote:

> Just updated the test to workaround a seemingly unrelated platform specific 
> issue. (that only manifests on older kernels)
> 
> http://cr.openjdk.java.net/~robm/8065238/webrev.02/
> 
>-Rob
> 
> On 03/12/14 16:21, Rob McKenna wrote:
>> Hi folks,
>> 
>> Looking to fix a regression caused by 8042857. Basically the behaviour in 
>> 8042857 is incorrect. This fix reverts to the previous behaviour and 
>> attempts to beef up the tests a little around Ldap timeouts.
>> 
>> http://cr.openjdk.java.net/~robm/8065238/webrev.01/
>> 
>> The test itself looks quite complex but isn't really. There are two executor 
>> pools. (scheduled and fixed) The fixed pool is for running tests 
>> concurrently. The scheduled pool is for killing tests that test ldap 
>> connects / reads where no timeout is set. (according to the spec these 
>> should wait forever)
>> 
>> For these long running timeout tests, we schedule a thread to interrupt the 
>> test after waiting for 20s. There are 3 of these long running tests in 
>> total, hence the decision to run the tests in parallel.
>> 
>> I'm not averse to breaking this out into separate tests and a library for 
>> the helper classes if people think it makes more sense to leave the 
>> concurrency up to the test framework.
>> 
>>-Rob
>> 
> 



Re: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

2014-12-04 Thread Rob McKenna
Just updated the test to workaround a seemingly unrelated platform 
specific issue. (that only manifests on older kernels)


http://cr.openjdk.java.net/~robm/8065238/webrev.02/

-Rob

On 03/12/14 16:21, Rob McKenna wrote:

Hi folks,

Looking to fix a regression caused by 8042857. Basically the behaviour 
in 8042857 is incorrect. This fix reverts to the previous behaviour 
and attempts to beef up the tests a little around Ldap timeouts.


http://cr.openjdk.java.net/~robm/8065238/webrev.01/

The test itself looks quite complex but isn't really. There are two 
executor pools. (scheduled and fixed) The fixed pool is for running 
tests concurrently. The scheduled pool is for killing tests that test 
ldap connects / reads where no timeout is set. (according to the spec 
these should wait forever)


For these long running timeout tests, we schedule a thread to 
interrupt the test after waiting for 20s. There are 3 of these long 
running tests in total, hence the decision to run the tests in parallel.


I'm not averse to breaking this out into separate tests and a library 
for the helper classes if people think it makes more sense to leave 
the concurrency up to the test framework.


-Rob