[ 
https://issues.apache.org/jira/browse/DIRAPI-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195817#comment-14195817
 ] 

Emmanuel Lecharny commented on DIRAPI-200:
------------------------------------------

Ok, I went a bit farther. 

In a scenario where we bind, and unbind, without using the pool, I can loop 
16000 times without pb, then I get an exception :

{code}
Iteration # 16300
Failure after 16347 iterations
org.apache.directory.ldap.client.api.exception.InvalidConnectionException: 
Cannot connect on the server: Can't assign requested address
        at 
org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:586)
        at 
org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1196)
        at 
org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1116)
        at 
org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:127)
        at 
org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:112)
        at 
org.apache.directory.shared.client.api.LdapConnectionPoolTest.testRebind2(LdapConnectionPoolTest.java:250)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
        at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
        at 
org.apache.directory.server.core.integ.FrameworkRunner.runChild(FrameworkRunner.java:379)
        at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at 
org.apache.directory.server.core.integ.FrameworkRunner.run(FrameworkRunner.java:154)
        at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
        at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
        at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
        at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
        at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
        at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.net.BindException: Can't assign requested address
        at sun.nio.ch.Net.connect0(Native Method)
        at sun.nio.ch.Net.connect(Net.java:435)
        at sun.nio.ch.Net.connect(Net.java:427)
        at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:643)
        at 
org.apache.mina.transport.socket.nio.NioSocketConnector.connect(NioSocketConnector.java:185)
        at 
org.apache.mina.transport.socket.nio.NioSocketConnector.connect(NioSocketConnector.java:46)
        at 
org.apache.mina.core.polling.AbstractPollingIoConnector.connect0(AbstractPollingIoConnector.java:322)
        at 
org.apache.mina.core.service.AbstractIoConnector.connect(AbstractIoConnector.java:248)
        at 
org.apache.mina.core.service.AbstractIoConnector.connect(AbstractIoConnector.java:171)
        at 
org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:539)
        ... 32 more
{code}

It might be very OSX dependent though. 

I have applied 2 important modifications in the LdapNetworkConnection.unbind() 
method : first, we now wait for the unbindFuture to complete, second I added a 
call to the close() method, which actually close the connection (as requested 
by RFC 4511).

I'd like to know if any of those changes makes the test happy on linux.

The tests are @Ignored atm, it's enough to comment the @Ignore. 

> unBind() followed by bind() on the same connection may throw an 
> IllegalStateException
> -------------------------------------------------------------------------------------
>
>                 Key: DIRAPI-200
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-200
>             Project: Directory Client API
>          Issue Type: Bug
>    Affects Versions: 1.0.0-M23
>            Reporter: lucas theisen
>
> Not sure if this even should be allowed but the fact that it can result in an 
> exception is disconcerting.  I added a test case to 
> {{LdapConnectionPoolTest}} (with the {{unBind()}} currently commented out) 
> that can be used to reproduce this issue.
> The main question here, in my mind, is whether or not this should be allowed. 
>  If not allowed, we should immediately throw a more reasonable exception if 
> any operation is attempted on an {{LdapConnection}} that has had {{unBind()}} 
> called on it.  Perhaps still an {{IllegalStateException}}, but maybe with a 
> message stating _connection no longer valid after unBind()_.  More 
> importantly, this should happen every time, rather than just when the race 
> condition bears its ugly face.  For more discussion, see [this email 
> chain|http://mail-archives.apache.org/mod_mbox/directory-dev/201407.mbox/%3CEE6ADC61AF2D71408E4FA7F9517DB7710A9C07E5%40IMCMBX03.MITRE.ORG%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to