On 11/09/2018 12:15, Chris Hegarty wrote:
On 11 Sep 2018, at 09:50, vyom tewari wrote:
Hi Chris,Daniel,
Please find the latest patch(
http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
Thanks Vyom, Reviewed.
Agreed.
best regards,
-- daniel
-Chris.
> On 11 Sep 2018, at 09:50, vyom tewari wrote:
>
> Hi Chris,Daniel,
>
> Please find the latest patch(
> http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
Thanks Vyom, Reviewed.
-Chris.
Hi Chris,Daniel,
Please find the latest patch(
http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
I did the additional cleanup(removed redundant null check) as you suggested.
Thanks,
Vyom
On Monday 10 September 2018 09:03 PM, Daniel Fuchs wrote:
On 10/09/2018 15:53, vyom
Vyom,
You are correct, the change that I proposed is minimal
and some fragility still remains.
I talked with Daniel, walked through the code one more
time, and I am now convinced that your original proposal
is correct ( since the pooling is at the level of
LdapClient, rather than at the level of
On 10/09/2018 15:53, vyom tewari wrote:
Yes , this will definitely solve this NPE issue but we may hit NPE other
places as well because we are setting 'LdapClient.com' to null
asynchronously.
I agree with Vyom here.
Other solutions that have been investigated - such as only
setting the connec
On Monday 10 September 2018 05:30 PM, Chris Hegarty wrote:
Vyom,
The NPE is originating from the finally block of the LdapClient
`authenticate` method. In the finally block there is an attempt
to restore the "read" timeout, since it was changed earlier in
`authenticate`, to reflect the connec
Nice find Chris.
But I have to wonder why the NPE wasn't thrown at the
very beginning of `authenticate` namely one of these
two lines:
int readTimeout = conn.readTimeout;
conn.readTimeout = conn.connectTimeout;
which happen to be called even before ensureOpen() is
called a few l
Vyom,
The NPE is originating from the finally block of the LdapClient
`authenticate` method. In the finally block there is an attempt
to restore the "read" timeout, since it was changed earlier in
`authenticate`, to reflect the connect timeout value, since the
subsequent operation(s) are consider
Hi Vyom,
Please see inline... I've elided some parts...
On 07/09/2018 10:11, vyom tewari wrote:
On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
So what we see here is actually a race between an open
connection being retrieved from the pool, and the server
deciding to close that conn
Hi Daniel,
Thanks for detailed review and comment. Please find my answers inline.
Thanks,
Vyom
On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
Hi Vyom,
IIUC, the issue only happens when connections (clients?) to the
server are pooled. I assume the server may decide to
close what
Hi Vyom,
IIUC, the issue only happens when connections (clients?) to the
server are pooled. I assume the server may decide to
close what it thinks is an idle connection at any time.
So what we see here is actually a race between an open
connection being retrieved from the pool, and the server
de
On Friday 24 August 2018 08:52 PM, Chris Hegarty wrote:
Hi Vyom,
On 24/08/18 11:35, vyom tewari wrote:
Hi All,
Please review this simple fix below
webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html
bugid: https://bugs.openjdk.java.net/browse/JDK-8205330
This fix wil
Hi Vyom,
On 24/08/18 11:35, vyom tewari wrote:
Hi All,
Please review this simple fix below
webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html
bugid: https://bugs.openjdk.java.net/browse/JDK-8205330
This fix will resolve the race in LdapClient where we are explicitly
m
Hi All,
Please review this simple fix below
webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html
bugid: https://bugs.openjdk.java.net/browse/JDK-8205330
This fix will resolve the race in LdapClient where we are explicitly
making "null" to LdapClient.conn.
Thanks,
Vyom
14 matches
Mail list logo
