[jira] [Commented] (DIRAPI-342) Unbind breaks connection
[
https://issues.apache.org/jira/browse/DIRAPI-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848681#comment-16848681
]
Emmanuel Lecharny commented on DIRAPI-342:
--
That's nasty...
When you call {{unbind}}, two things happen:
- once the server has processed the request, it will close the TCP connection.
On the client, it will generate a {{inputClosed}} event, which calls
{{session.closeNow()}}
- OTOH, when a {{Unbind}} request is sent, a {{Future}} is created, with a
{{ready}} flag that is set to {{false}} until the message has been fully
written. It should be done immediately (but not necessarily), and in this case,
the {{ready}} flag is set to true, so the {{Future}} will not block. Now, the
message map is cleared, and {{close()}} is called.
whatever wins will lead to the result: the session will be closed, but the way
it does it is not the same.
2) if the first course of action wins, we end with {{closeNow()}} being called,
which will be processed later on in a separate thread.
1) if the second course of action wins, the {{sessionClosed()}} method is
called which should shutdown the client, clear the map, etc, but *inanother
thread* (ie, the client might be able to process some new operation before the
session is really closed)
Anyway, we have a potential short period of time where we *may* be able to
reuse a session that is not clean.
Waiting for the {{closeFuture}} does not help. We need to wait on something
that guarantees the session has been closed, a {{Future}} set in the
{{sessionClosed}} event. Until this future is set, we should *not* reuse the
session. It should be created before we write the {{Unbind}} request, or before
we call {{close()}}, and it should be waiting for when one try to {{connect()}}
or to send any message.
> Unbind breaks connection
>
>
> Key: DIRAPI-342
> URL: https://issues.apache.org/jira/browse/DIRAPI-342
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM2
>Reporter: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.0.AM4, 2.0.0
>
>
> The DelegatedAuthIT/DelegatedAuthOverSslIT/DelegatedAuthOverTlsIT tests fail
> randomly (I try to stabilize tests on Windows, but also happens on Jenkins).
> They all do multiple bind() and unbind() on the same connection, it seems the
> unbind() is the reason.
> A simple test to reproduce the problem (on Linux):
> {code}
> @Test
> public void testSimpleBindAndUnbindLoop() throws Exception
> {
> try ( LdapConnection connection = new LdapNetworkConnection(
> Network.LOOPBACK_HOSTNAME,
> getLdapServer().getPort() ) )
> {
> for ( int i = 0; i < 1; i++ )
> {
> System.out.println( i );
> connection.bind( "uid=admin,ou=system", "secret" );
> assertTrue( connection.isAuthenticated() );
> connection.unBind();
> assertFalse( connection.isAuthenticated() );
> // Thread.sleep( 10L );
> }
> }
> }
> {code}
> Without the unbind() or when sleeping for 10ms it works fine.
> Otherwise I saw 3 different errors:
> {code}
> org.apache.directory.ldap.client.api.exception.InvalidConnectionException:
> ERR_04108_INVALID_CONNECTION Cannot connect on the server, the connection is
> invalid
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.checkSession(LdapNetworkConnection.java:574)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1596)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1488)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:134)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:118)
> {code}
> {code}
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1534)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:134)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:118)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1505)
> {code}
> {code}
> org.apache.directory.api.ldap.model.exception.LdapProtocolErrorException:
> PROTOCOL_ERROR: The server will disconnect
[jira] [Comment Edited] (DIRAPI-342) Unbind breaks connection
[
https://issues.apache.org/jira/browse/DIRAPI-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848681#comment-16848681
]
Emmanuel Lecharny edited comment on DIRAPI-342 at 5/27/19 2:36 PM:
---
That's nasty...
When you call {{unbind}}, two things happen:
- once the server has processed the request, it will close the TCP connection.
On the client, it will generate a {{inputClosed}} event, which calls
{{session.closeNow()}}
- OTOH, when a {{Unbind}} request is sent, a {{Future}} is created, with a
{{ready}} flag that is set to {{false}} until the message has been fully
written. It should be done immediately (but not necessarily), and in this case,
the {{ready}} flag is set to true, so the {{Future}} will not block. Now, the
message map is cleared, and {{close()}} is called.
whatever wins will lead to the result: the session will be closed, but the way
it does it is not the same.
* if the first course of action wins, we end with {{closeNow()}} being called,
which will be processed later on in a separate thread.
* if the second course of action wins, the {{sessionClosed()}} method is called
which should shutdown the client, clear the map, etc, but *in another thread*
(ie, the client might be able to process some new operation before the session
is really closed)
Anyway, we have a potential short period of time where we *may* be able to
reuse a session that is not clean.
Waiting for the {{closeFuture}} does not help. We need to wait on something
that guarantees the session has been closed, a {{Future}} set in the
{{sessionClosed}} event. Until this future is set, we should *not* reuse the
session. It should be created before we write the {{Unbind}} request, or before
we call {{close()}}, and it should be waiting for when one try to {{connect()}}
or to send any message.
was (Author: elecharny):
That's nasty...
When you call {{unbind}}, two things happen:
- once the server has processed the request, it will close the TCP connection.
On the client, it will generate a {{inputClosed}} event, which calls
{{session.closeNow()}}
- OTOH, when a {{Unbind}} request is sent, a {{Future}} is created, with a
{{ready}} flag that is set to {{false}} until the message has been fully
written. It should be done immediately (but not necessarily), and in this case,
the {{ready}} flag is set to true, so the {{Future}} will not block. Now, the
message map is cleared, and {{close()}} is called.
whatever wins will lead to the result: the session will be closed, but the way
it does it is not the same.
2) if the first course of action wins, we end with {{closeNow()}} being called,
which will be processed later on in a separate thread.
1) if the second course of action wins, the {{sessionClosed()}} method is
called which should shutdown the client, clear the map, etc, but *inanother
thread* (ie, the client might be able to process some new operation before the
session is really closed)
Anyway, we have a potential short period of time where we *may* be able to
reuse a session that is not clean.
Waiting for the {{closeFuture}} does not help. We need to wait on something
that guarantees the session has been closed, a {{Future}} set in the
{{sessionClosed}} event. Until this future is set, we should *not* reuse the
session. It should be created before we write the {{Unbind}} request, or before
we call {{close()}}, and it should be waiting for when one try to {{connect()}}
or to send any message.
> Unbind breaks connection
>
>
> Key: DIRAPI-342
> URL: https://issues.apache.org/jira/browse/DIRAPI-342
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM2
>Reporter: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.0.AM4, 2.0.0
>
>
> The DelegatedAuthIT/DelegatedAuthOverSslIT/DelegatedAuthOverTlsIT tests fail
> randomly (I try to stabilize tests on Windows, but also happens on Jenkins).
> They all do multiple bind() and unbind() on the same connection, it seems the
> unbind() is the reason.
> A simple test to reproduce the problem (on Linux):
> {code}
> @Test
> public void testSimpleBindAndUnbindLoop() throws Exception
> {
> try ( LdapConnection connection = new LdapNetworkConnection(
> Network.LOOPBACK_HOSTNAME,
> getLdapServer().getPort() ) )
> {
> for ( int i = 0; i < 1; i++ )
> {
> System.out.println( i );
> connection.bind( "uid=admin,ou=system", "secret" );
> assertTrue( connection.isAuthenticated() );
> connection.unBind();
> assertFalse( connection.isAuthenticated() );
> // Thread.sleep( 10L );
> }
> }
> }
> {code}
> Without the unbind() or when sl
[jira] [Comment Edited] (DIRAPI-342) Unbind breaks connection
[
https://issues.apache.org/jira/browse/DIRAPI-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848681#comment-16848681
]
Emmanuel Lecharny edited comment on DIRAPI-342 at 5/27/19 2:50 PM:
---
That's nasty...
When you call {{unbind}}, two things happen:
- once the server has processed the request, it will close the TCP connection.
On the client, it will generate a {{inputClosed}} event, which calls
{{session.closeNow()}}
- OTOH, when a {{Unbind}} request is sent, a {{Future}} is created, with a
{{ready}} flag that is set to {{false}} until the message has been fully
written. It should be done immediately (but not necessarily, as it's processed
by a separate thread), and in this case, the {{ready}} flag is set to true, so
the {{Future}} will not block. Now, the message map is cleared, and
{{close()}} is called.
whatever wins will lead to the result: the session will be closed, but the way
it does it is not the same.
* if the first course of action wins, we end with {{closeNow()}} being called,
which will be processed later on in a separate thread.
* if the second course of action wins, the {{sessionClosed()}} method is called
which should shutdown the client, clear the map, etc, but *in another thread*
(ie, the client might be able to process some new operation before the session
is really closed)
Anyway, we have a potential short period of time where we *may* be able to
reuse a session that is not clean.
Waiting for the {{closeFuture}} does not help. We need to wait on something
that guarantees the session has been closed, a {{Future}} set in the
{{sessionClosed}} event. Until this future is set, we should *not* reuse the
session. It should be created before we write the {{Unbind}} request, or before
we call {{close()}}, and it should be waiting for when one try to {{connect()}}
or to send any message.
was (Author: elecharny):
That's nasty...
When you call {{unbind}}, two things happen:
- once the server has processed the request, it will close the TCP connection.
On the client, it will generate a {{inputClosed}} event, which calls
{{session.closeNow()}}
- OTOH, when a {{Unbind}} request is sent, a {{Future}} is created, with a
{{ready}} flag that is set to {{false}} until the message has been fully
written. It should be done immediately (but not necessarily), and in this case,
the {{ready}} flag is set to true, so the {{Future}} will not block. Now, the
message map is cleared, and {{close()}} is called.
whatever wins will lead to the result: the session will be closed, but the way
it does it is not the same.
* if the first course of action wins, we end with {{closeNow()}} being called,
which will be processed later on in a separate thread.
* if the second course of action wins, the {{sessionClosed()}} method is called
which should shutdown the client, clear the map, etc, but *in another thread*
(ie, the client might be able to process some new operation before the session
is really closed)
Anyway, we have a potential short period of time where we *may* be able to
reuse a session that is not clean.
Waiting for the {{closeFuture}} does not help. We need to wait on something
that guarantees the session has been closed, a {{Future}} set in the
{{sessionClosed}} event. Until this future is set, we should *not* reuse the
session. It should be created before we write the {{Unbind}} request, or before
we call {{close()}}, and it should be waiting for when one try to {{connect()}}
or to send any message.
> Unbind breaks connection
>
>
> Key: DIRAPI-342
> URL: https://issues.apache.org/jira/browse/DIRAPI-342
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM2
>Reporter: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.0.AM4, 2.0.0
>
>
> The DelegatedAuthIT/DelegatedAuthOverSslIT/DelegatedAuthOverTlsIT tests fail
> randomly (I try to stabilize tests on Windows, but also happens on Jenkins).
> They all do multiple bind() and unbind() on the same connection, it seems the
> unbind() is the reason.
> A simple test to reproduce the problem (on Linux):
> {code}
> @Test
> public void testSimpleBindAndUnbindLoop() throws Exception
> {
> try ( LdapConnection connection = new LdapNetworkConnection(
> Network.LOOPBACK_HOSTNAME,
> getLdapServer().getPort() ) )
> {
> for ( int i = 0; i < 1; i++ )
> {
> System.out.println( i );
> connection.bind( "uid=admin,ou=system", "secret" );
> assertTrue( connection.isAuthenticated() );
> connection.unBind();
> assertFalse( connection.isAuthenticated() );
> // Thread.sleep( 10L );
> }
> }
> }
>
[jira] [Commented] (DIRAPI-342) Unbind breaks connection
[
https://issues.apache.org/jira/browse/DIRAPI-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849012#comment-16849012
]
Emmanuel Lecharny commented on DIRAPI-342:
--
What about that:
- no matter what, a call to {{unbind}} or {{close}} should put the session in a
state where no other operation can be executed, as if the session was
immediately closed.
- which means we have to wait either for the {{inputClosed}} event or for the
session cleanup (it all depends on which ends first)
(that's just rephrasing the previous comment)
> Unbind breaks connection
>
>
> Key: DIRAPI-342
> URL: https://issues.apache.org/jira/browse/DIRAPI-342
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM2
>Reporter: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.0.AM4, 2.0.0
>
>
> The DelegatedAuthIT/DelegatedAuthOverSslIT/DelegatedAuthOverTlsIT tests fail
> randomly (I try to stabilize tests on Windows, but also happens on Jenkins).
> They all do multiple bind() and unbind() on the same connection, it seems the
> unbind() is the reason.
> A simple test to reproduce the problem (on Linux):
> {code}
> @Test
> public void testSimpleBindAndUnbindLoop() throws Exception
> {
> try ( LdapConnection connection = new LdapNetworkConnection(
> Network.LOOPBACK_HOSTNAME,
> getLdapServer().getPort() ) )
> {
> for ( int i = 0; i < 1; i++ )
> {
> System.out.println( i );
> connection.bind( "uid=admin,ou=system", "secret" );
> assertTrue( connection.isAuthenticated() );
> connection.unBind();
> assertFalse( connection.isAuthenticated() );
> // Thread.sleep( 10L );
> }
> }
> }
> {code}
> Without the unbind() or when sleeping for 10ms it works fine.
> Otherwise I saw 3 different errors:
> {code}
> org.apache.directory.ldap.client.api.exception.InvalidConnectionException:
> ERR_04108_INVALID_CONNECTION Cannot connect on the server, the connection is
> invalid
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.checkSession(LdapNetworkConnection.java:574)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1596)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1488)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:134)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:118)
> {code}
> {code}
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1534)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:134)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:118)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1505)
> {code}
> {code}
> org.apache.directory.api.ldap.model.exception.LdapProtocolErrorException:
> PROTOCOL_ERROR: The server will disconnect!
> at
> org.apache.directory.api.ldap.model.message.ResultCodeEnum.processResponse(ResultCodeEnum.java:2137)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:136)
> at
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:118)
> at
> org.apache.directory.shared.client.api.operations.bind.SimpleBindRequestTest.testSimpleBindAndUnbindLoop(SimpleBindRequestTest.java:664)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
