Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.0-M12
    • Fix Version/s: 1.0.0-M13
    • Component/s: 0.9.18
    • Labels:
      None
    • Environment:

      Description

      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.

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        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.

        Show
        Emmanuel Lecharny added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Hendy Irawan
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development