Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

[Vyom Tiwari]

Hi Patrick,
Thanks for testing, please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev1.0/index.html). I fixed
the windows build issue.
Thanks,
Vyom

On Tue, Jul 7, 2020 at 11:49 PM Patrick Concannon <
patrick.concan...@oracle.com> wrote:

> Hi Vyom,
>
> I imported your latest patch and ran it on our test system, and I noticed
> the following error on Windows:
>
> [2020-07-07T11:09:20,621Z]
> T:\workspace\open\test\jdk\java\net\Socket\libNativeThread.c(54) : error
> C2220: the following warning is treated as an error
> [2020-07-07T11:09:20,621Z]
> T:\workspace\open\test\jdk\java\net\Socket\libNativeThread.c(54) : warning
> C4716: 'Java_NativeThread_signal': must return a value
>
> Kind regards,
> Patrick
>
> On 7 Jul 2020, at 04:14, Vyom Tiwari  wrote:
>
> Hi All,
>
> Please find the updated webrev(
> http://cr.openjdk.java.net/~vtewari/8237858/webrev0.9/index.html). I
> leave the idea of using the PoolCleaner.
>
> Thanks,
> Vyom
>
> On Sat, Jul 4, 2020 at 9:08 PM Martin Buchholz 
> wrote:
>
>> Right.  It would be a project to create a jtreg test utility inspired
>> by PoolCleaner and use it in many tests.
>>
>> On Sat, Jul 4, 2020 at 8:24 AM Vyom Tiwari  wrote:
>> >
>> > Hi Martin
>> > Thanks for the review, I will try to address your review comment.
>> >
>> > I wanted to write a simple test case for this issue but it is getting
>> more complex.
>> >
>> > Thanks,
>> > Vyom
>> >
>> > On Sat, Jul 4, 2020 at 8:14 PM Martin Buchholz 
>> wrote:
>> >>
>> >> On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman 
>> wrote:
>> >>
>> >> > - "service" isn't a great name for the Executor. Also you can make
>> use
>> >> > of try-finally, e.g.
>> >> > ExecutorService executor = Executors.newFixedThreadPool(1);
>> >> > try { ... } finally { executor.shutdown(); }
>> >>
>> >> If you want to do this structured-concurrency-style, you should wait
>> >> for all the threads you started to complete (they might block!).
>> >> shutdown is not enough - you also want awaitTermination.
>> >>
>> >> We have a PoolCleaner utility in test/jdk/java/util/concurrent/tck/ to
>> >> help do this.
>> >>
>> >>  try (PoolCleaner cleaner = cleaner(p)) {
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > Vyom
>>
>
>
> --
> Thanks,
> Vyom
>
>
>

-- 
Thanks,
Vyom

Browser's accepting certificates that Java does not

[Mark A. Claassen]

I was curious if there has been any thought to allowing accessing to other 
certificate stores in Windows besides the "Trusted Root Certification 
Authorities" and the "Personal" ones.  It seems like web servers omitting 
intermediate certificates in the certificate chain is pretty common.  Browsers 
seems to fill in the gaps, but Java does not.

We very recently encountered this again when a customer started proxying their 
SSL requests, creating a new certificate on the fly, resigning ours with their 
corporate CA.  (The browser handled this fine, but our Java app detected a 
chain length of 2, instead of 4 like in the browser.)  Having them put their 
intermediate certificates in the "Trusted Root Certification Authorities" 
solved the issue, but they are unwilling to do this on a corporate-wide basis.

If Java was able to access more keystores through the MSCAPI interface, is 
seems like it would fill in the gaps as well and remove a pain point we are 
experiencing where Java does not accept a certificate even though all their 
browsers will.  I think all intermediate certificates are supposed to be in the 
chain sent from the server (https://tools.ietf.org/html/rfc5246) in the TLS 
negotiation, but since browser's don't enforce care, people are left thinking 
everything is great (until Java tries to connect).

Thanks,

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect 
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
assumes no legal liability or responsibility for the posting. 

Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

[Patrick Concannon]

Hi Vyom,

I imported your latest patch and ran it on our test system, and I noticed the 
following error on Windows:

[2020-07-07T11:09:20,621Z] 
T:\workspace\open\test\jdk\java\net\Socket\libNativeThread.c(54) : error C2220: 
the following warning is treated as an error
[2020-07-07T11:09:20,621Z] 
T:\workspace\open\test\jdk\java\net\Socket\libNativeThread.c(54) : warning 
C4716: 'Java_NativeThread_signal': must return a value

Kind regards,
Patrick

> On 7 Jul 2020, at 04:14, Vyom Tiwari  wrote:
> 
> Hi All,
> 
> Please find the updated 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.9/index.html 
> ). I leave 
> the idea of using the PoolCleaner.
> 
> Thanks,
> Vyom
> 
> On Sat, Jul 4, 2020 at 9:08 PM Martin Buchholz  > wrote:
> Right.  It would be a project to create a jtreg test utility inspired
> by PoolCleaner and use it in many tests.
> 
> On Sat, Jul 4, 2020 at 8:24 AM Vyom Tiwari  > wrote:
> >
> > Hi Martin
> > Thanks for the review, I will try to address your review comment.
> >
> > I wanted to write a simple test case for this issue but it is getting more 
> > complex.
> >
> > Thanks,
> > Vyom
> >
> > On Sat, Jul 4, 2020 at 8:14 PM Martin Buchholz  > > wrote:
> >>
> >> On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman  >> > wrote:
> >>
> >> > - "service" isn't a great name for the Executor. Also you can make use
> >> > of try-finally, e.g.
> >> > ExecutorService executor = Executors.newFixedThreadPool(1);
> >> > try { ... } finally { executor.shutdown(); }
> >>
> >> If you want to do this structured-concurrency-style, you should wait
> >> for all the threads you started to complete (they might block!).
> >> shutdown is not enough - you also want awaitTermination.
> >>
> >> We have a PoolCleaner utility in test/jdk/java/util/concurrent/tck/ to
> >> help do this.
> >>
> >>  try (PoolCleaner cleaner = cleaner(p)) {
> >
> >
> >
> > --
> > Thanks,
> > Vyom
> 
> 
> -- 
> Thanks,
> Vyom

Re: 8248865: Document JNDI/LDAP timeout properties

[Daniel Fuchs]

On 07/07/2020 14:08, Sean Mullan wrote:

I believe this is a more general problem - and I would beg to tackle
that in a followup issue if you don't mind.


Ok.


For the record I have logged 
https://bugs.openjdk.java.net/browse/JDK-8248909


best regards,

-- daniel

Re: 8248865: Document JNDI/LDAP timeout properties

[Sean Mullan]

On 7/7/20 9:02 AM, Daniel Fuchs wrote:

Hi Sean,

Good point.

It appears it throws a java.lang.NumberFormatException which is not
documented as being thrown by any InitialContext constructors or its
subclasses, nor by `addToEnvironment`.


Ugh, ok.


I believe this is a more general problem - and I would beg to tackle
that in a followup issue if you don't mind.


Ok.

--Sean



best regards,

-- daniel

On 07/07/2020 13:12, Sean Mullan wrote:
You should document what the behavior is if an invalid string value is 
set (ex: not an integer).


--Sean

Re: 8248865: Document JNDI/LDAP timeout properties

[Daniel Fuchs]

Hi Sean,

Good point.

It appears it throws a java.lang.NumberFormatException which is not
documented as being thrown by any InitialContext constructors or its
subclasses, nor by `addToEnvironment`.

I believe this is a more general problem - and I would beg to tackle
that in a followup issue if you don't mind.

best regards,

-- daniel

On 07/07/2020 13:12, Sean Mullan wrote:
You should document what the behavior is if an invalid string value is 
set (ex: not an integer).


--Sean

Re: 8248865: Document JNDI/LDAP timeout properties

[Sean Mullan]

You should document what the behavior is if an invalid string value is 
set (ex: not an integer).


--Sean

On 7/7/20 7:11 AM, Aleks Efimov wrote:

Hi Daniel,

Thanks for documenting the system properties. It looks good to me.

NIT: You might want to update the copyright's last modification year to 
2020


Best Regards,
Aleksei

On 06/07/2020 16:39, Daniel Fuchs wrote:

Hi,

Please find below a doc only change to document two
JDK specific JNDI/LDAP timeout properties:

8248865: Document JNDI/LDAP timeout properties
https://bugs.openjdk.java.net/browse/JDK-8248865

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8248865/webrev.00/

CSR:
https://bugs.openjdk.java.net/browse/JDK-8248866

best regards,

-- daniel

Re: 8248865: Document JNDI/LDAP timeout properties

[Chris Hegarty]

Looks ok to me.

-Chris.

> On 6 Jul 2020, at 16:39, Daniel Fuchs  wrote:
> 
> Hi,
> 
> Please find below a doc only change to document two
> JDK specific JNDI/LDAP timeout properties:
> 
> 8248865: Document JNDI/LDAP timeout properties
> https://bugs.openjdk.java.net/browse/JDK-8248865
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8248865/webrev.00/
> 
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8248866
> 
> best regards,
> 
> -- daniel

Re: 8248865: Document JNDI/LDAP timeout properties

[Aleks Efimov]

Hi Daniel,

Thanks for documenting the system properties. It looks good to me.

NIT: You might want to update the copyright's last modification year to 2020

Best Regards,
Aleksei

On 06/07/2020 16:39, Daniel Fuchs wrote:

Hi,

Please find below a doc only change to document two
JDK specific JNDI/LDAP timeout properties:

8248865: Document JNDI/LDAP timeout properties
https://bugs.openjdk.java.net/browse/JDK-8248865

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8248865/webrev.00/

CSR:
https://bugs.openjdk.java.net/browse/JDK-8248866

best regards,

-- daniel