[
https://issues.apache.org/jira/browse/DIRSHARED-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSHARED-135.
-----------------------------------------
Resolution: Won't Fix
This is a complex issue.
sharing a connection between many threads is certainly not a good idea : the
incoming messages may arrive fragmented, and this may be impossible to build
the correct responses in this case, leading to a situation where we will have
long timeout (60s).
OTOH, making the connection threadsafe would forbid someone to stop a long
operation with the AbandonRequest request.
ATM, I would rather tell you to create as many connection as you have threads.
> LdapNetworkConnection should be thread-safe
> -------------------------------------------
>
> Key: DIRSHARED-135
> URL: https://issues.apache.org/jira/browse/DIRSHARED-135
> Project: Directory Shared
> Issue Type: Bug
> Components: 0.9.18
> Affects Versions: 1.0.0-M12
> Environment: java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> Linux annafi.dev 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Hendy Irawan
> Fix For: 1.0.0-M13
>
>
> I'm working on an open source project ( https://github.com/soluvas/ldap-tools
> ) which uses LdapNetworkConnection using shared v1.0.0-M12. Several threads
> are running in parallel (using Akka), all using the same
> LdapNetworkConnection to delete entries.
> However in some cases it locks up (deadlock? race condition?) and the last
> logs I get is :
> ...
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-14] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=setsuna_hinagiku,ou=users,dc=berbatik,dc=com
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-24] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=rumah_amal_salman_itb,ou=users,dc=berbatik,dc=com
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-18] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=setyo_rini,ou=users,dc=berbatik,dc=com
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-1] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=pipit_nugroho,ou=users,dc=berbatik,dc=com
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-15] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=yuliana_riris_basaria,ou=users,dc=berbatik,dc=com
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [ldap_cli-akka.actor.default-dispatcher-16] INFO
> o.soluvas.ldaptools.cli.PersonClear - Deleting
> uid=setia_budi,ou=users,dc=berbatik,dc=com
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> 22:17:17 [NioProcessor-2] DEBUG o.a.m.f.codec.ProtocolCodecFilter -
> Processing a MESSAGE_RECEIVED for session 1
> I also experience similar issues doing concurrent add()s.
> LdapNetworkConnection should be thread-safe.
> Workaround: use separate LdapConnection for each thread, or probably
> sufficient to use synchronized blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
