Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LDAP Hangs

252 views
Skip to first unread message

Roytman, Alex

unread,
Jan 25, 2006, 7:40:37 PM1/25/06
to

Hello,

 

We have been experiencing intermittent lockups recently. I wonder if anyone had similar problem. Below please find stack traces for couple of stuck threads.

We are using November 2005 jLDAP build against Netware 6.0 LDAP

 

If I remember correctly we share the same connection to read LDAP data from multiple threads. I recall it was specified to be thread sahe

 

I would appreciate any suggestions

 

 

Thanks

 

Alex Roytman

 

 

 

"TP-Processor33" daemon prio=1 tid=0x086cc720 nid=0x1b7f in Object.wait() [0x67cfe000..0x67cff6f0]

            at java.lang.Object.wait(Native Method)

            - waiting on <0x71f8efb0> (a java.lang.Object)

            at java.lang.Object.wait(Object.java:474)

            at com.novell.ldap.Connection.acquireWriteSemaphore(Unknown Source)

            - locked <0x71f8efb0> (a java.lang.Object)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Message.sendMessage(Unknown Source)

            at com.novell.ldap.MessageAgent.sendMessage(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.search(LdapPrincipalBuilder.java:176)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.findPrincipal(LdapPrincipalBuilder.java:100)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.provide(LdapPrincipalBuilder.java:51)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.provide(PrincipalBuilderRealm.java:113)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.authenticate(PrincipalBuilderRealm.java:36)

            at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256)

            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)

            at com.peacetech.tomcat.auth.RSANextTokenValve.invoke(RSANextTokenValve.java:185)

            at com.peacetech.tomcat.auth.SessionExpiredWarning.invoke(SessionExpiredWarning.java:109)

            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)

            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)

            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)

            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)

            at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)

            at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)

            at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:744)

            at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:674)

            at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:866)

            at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

            at java.lang.Thread.run(Thread.java:595)

 

 

"TP-Processor236" daemon prio=1 tid=0x641444b8 nid=0x2702 in Object.wait() [0x671e8000..0x671e9770]

            at java.lang.Object.wait(Native Method)

            - waiting on <0x71f8efb0> (a java.lang.Object)

            at java.lang.Object.wait(Object.java:474)

            at com.novell.ldap.Connection.acquireWriteSemaphore(Unknown Source)

            - locked <0x71f8efb0> (a java.lang.Object)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Message.sendMessage(Unknown Source)

            at com.novell.ldap.MessageAgent.sendMessage(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.search(LdapPrincipalBuilder.java:176)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.findPrincipal(LdapPrincipalBuilder.java:100)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.provide(LdapPrincipalBuilder.java:51)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.provide(PrincipalBuilderRealm.java:113)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.authenticate(PrincipalBuilderRealm.java:36)

            at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256)

            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)

            at com.peacetech.tomcat.auth.RSANextTokenValve.invoke(RSANextTokenValve.java:185)

            at com.peacetech.tomcat.auth.SessionExpiredWarning.invoke(SessionExpiredWarning.java:109)

            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)

            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)

            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)

            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)

            at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)

            at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)

            at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:744)

            at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:674)

            at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:866)

            at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

            at java.lang.Thread.run(Thread.java:595)

 

"TP-Processor232" daemon prio=1 tid=0x64172318 nid=0x26e0 in Object.wait() [0x68ce4000..0x68ce5570]

            at java.lang.Object.wait(Native Method)

            - waiting on <0x71f8efb0> (a java.lang.Object)

            at java.lang.Object.wait(Object.java:474)

            at com.novell.ldap.Connection.acquireWriteSemaphore(Unknown Source)

            - locked <0x71f8efb0> (a java.lang.Object)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Connection.writeMessage(Unknown Source)

            at com.novell.ldap.Message.sendMessage(Unknown Source)

            at com.novell.ldap.MessageAgent.sendMessage(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.novell.ldap.LDAPConnection.search(Unknown Source)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.search(LdapPrincipalBuilder.java:176)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.findPrincipal(LdapPrincipalBuilder.java:100)

            at com.peacetech.tomcat.auth.LdapPrincipalBuilder.provide(LdapPrincipalBuilder.java:51)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.provide(PrincipalBuilderRealm.java:113)

            at com.peacetech.tomcat.auth.PrincipalBuilderRealm.authenticate(PrincipalBuilderRealm.java:36)

            at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256)

            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)

            at com.peacetech.tomcat.auth.RSANextTokenValve.invoke(RSANextTokenValve.java:185)

            at com.peacetech.tomcat.auth.SessionExpiredWarning.invoke(SessionExpiredWarning.java:109)

            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)

            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)

            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)

            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)

            at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)

            at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)

            at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:744)

            at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:674)

            at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:866)

            at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

            at java.lang.Thread.run(Thread.java:595)

 

 

 

Moises Morales

unread,
Jan 26, 2006, 1:12:59 PM1/26/06
to
Alex Roytman,
By looking at the stack trace (.....acquireWriteSemaphore), it seems
that threads are conflicting. Anyways, I would suggest to synchronize
those LDAP calls in your code, just to see if the problem goes away.
I'm not sure if your application threads can afford synchronization, but
try it just to narrow down the problem.

Regards,

Moises Morales
Novell Developer Support

Roytman, Alex

unread,
Jan 26, 2006, 1:59:27 PM1/26/06
to
Hello Moises,

Thank you for your suggestion. Now I know precisely WHEN (but not why)
it happens. It happens if I unload LDAP.NLM on Netware server. All
connection hung and NEVER time out. I tried everything to make them
timeout - set LDAPConstraint.timeLimit no effect, pass my own
SSLSocketFactory which decorates JSSE factory and set soTimeout on each
socket - no effect. Every time I do bind or search on one of such
connections it hangs and never ever timeout

I found a work around - call LDAPConnection.isConnectionAlive before
every LDAP call - that one does not hang on bad connection and return
false as expected. It solves immediate problem but it makes my code
EXTREMELY dirty with all this "alive" checks. Not to say it is an extra
network roundtrip for each search or bind (even afraid to think what
might happen if connection goes dead in the middle of fetch - will stuck
I guess).

I have not tested what would happen if entire NetWare server (or TCP/IP
stack) got restarted not just LDAP. I suspect it might timeout then. I
have a suspicion that NLDAP itself somehow does not close sockets they
linger somewhere in TCP/IP stack and that's why client can not detect
broken connection. But I am not very familiar with internals of TCP/IP
protocol and NLDAP implementation so it is just a guess

I hope you would have a solution for us - I would hate having to
retrofit all our LDAP code with "Alive" checks

Thank you for your assistance

Alex

Roger Thomas, DevNet SysOp 22

unread,
Jan 26, 2006, 1:37:30 PM1/26/06
to
One thing to look at will be the version of eDirectory on the server and
is independent to the NW version. Unless the server has been upgraded
with service packs you may have a wide range of issues with the LDAP
support it can provide.
 
Roger Thomas, DevNet SysOp 22

@novell.com Susan Perrin

unread,
Jan 27, 2006, 3:25:53 PM1/27/06
to
In addition to what Moises wrote, when you write "If I remember correctly we share the same connection to read LDAP data from multiple threads. I recall it was specified to be thread safe", that's only when you use clone().
 
Thank you
Susan

Roytman, Alex

unread,
Jan 27, 2006, 6:26:04 PM1/27/06
to

Susan,

 

Thank you very much for your suggestion. This does not seem to be a threading issue I can reproduce this issue with a single thread:

 

- Open connection, bind, search

- Unload LDAP.NLM

- Search

 

This sequence cause second search to hang in exactly the same place as my stack trace and never timeout regardless o what set in LDAPConstraints and even regardless ot Socket.setSoTimeout() I do in my SSLSocketFactory decorator for each created socket.

 

I wonder if cloning dead connection will give me a good one (one which will not block) I will try it bit I doubt it will help

 

Thank you

 

Alex

 

From: jldap-de...@forge.novell.com [mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Friday, January 27, 2006 3:26 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

 

In addition to what Moises wrote, when you write "If I remember correctly we share the same connection to read LDAP data from multiple threads. I recall it was specified to be thread safe", that's only when you use clone().

 

Thank you

Susan

Roytman, Alex

unread,
Jan 30, 2006, 5:50:13 PM1/30/06
to

Susan,

 

Thank you very much I will give it a try.

Couple more questions:

- When using LDAPConnection.clone() to share a physical connection by multiple thread, should each thread close its clone immediately when it is done with it?

- Is cloned connection any different from the primary one? Will clone.close() close underling connection when all clones a closed or it needs to be closed explicitly via the primary connection?

- Should I just use connection pool rather then cloning?

 

Thanks again for your assistance

 

Alex  

 

From: jldap-de...@forge.novell.com [mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Monday, January 30, 2006 5:29 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

 

Hi

 

In the specific case you mention, the jldap libraries send notice to registered LDAPUnsolicitedNotificationListener's.  So the following will exit for me:

 

import com.novell.ldap.*;
import com.novell.ldap.util.Base64;
import java.util.Enumeration;
import java.util.Iterator;
import java.io.UnsupportedEncodingException;
import java.io.IOException;
import java.io.BufferedReader;
import java.io.InputStreamReader;
public class Search
{

 

 public class theListener implements LDAPUnsolicitedNotificationListener
 {

 

  public theListener()
  {
  }

 

  // The required method that has to be implemented by all listeners.  This
  // method is called on unsolicited notifications.
  public void messageReceived(LDAPExtendedResponse msg)
  {
   String myMsg = ((LDAPExtendedResponse)msg).getID();
   if(myMsg == LDAPConnection.SERVER_SHUTDOWN_OID)
   {
    System.out.println("Received notification of unsolicited notification " + myMsg);
    System.out.println("got shutdown");
    System.exit(-1);
   }
  }
 }

 


 /**
  * @param args
  */
 public static void main(String[] args)
 {
  if (args.length != 5)
  {
   System.out.println("Usage:   java Search <host name> <login dn>"
    + " <password> <search base>\n"
    + "         <search filter>");
   System.out.println("Example: java Search Acme.com"
                                     + " \"cn=admin,o=Acme\""
                                     + " secret \"ou=sales,o=Acme\"\n"
                                     + "         \"(objectclass=*)\"");
   System.exit(0);
  }
  new Search(args[0], args[1], args[2], args[3], args[4]);
 }

 

 public Search(String ldapHost, String loginDN, String password, String searchBase, String searchFilter)
 {

 


  int ldapPort = LDAPConnection.DEFAULT_PORT;
  int ldapVersion  = LDAPConnection.LDAP_V3;
  LDAPConnection lc = new LDAPConnection();
  LDAPSearchConstraints cons = new LDAPSearchConstraints();

 

  theListener myListener = new theListener();

 

  try
  {
   lc.addUnsolicitedNotificationListener(myListener);
   lc.setConstraints(cons);
   // connect to the server
   lc.connect( ldapHost, ldapPort );
   // bind to the server
   lc.bind( ldapVersion, loginDN, password.getBytes("UTF8") );
   while(true)
    doSearch(lc, searchBase, searchFilter);
   // disconnect with the server
   //lc.disconnect();
  }
  catch( Exception e )
  {
   e.printStackTrace();
  }
  System.exit(0);

 

 }

 

 public void doSearch(LDAPConnection lc, String searchBase, String searchFilter)
 {
  int searchScope = LDAPConnection.SCOPE_ONE;
  LDAPEntry nextEntry;
  try
  {

 

   LDAPSearchResults searchResults = lc.search(searchBase,
    searchScope,
    searchFilter,
    null,          // return all attributes
    false);        // return attrs and values

 

   while ( searchResults.hasMore())
   {
    nextEntry = searchResults.next();
    System.out.println("\n" + nextEntry.getDN());
    System.out.println("  Attributes: ");

 

    LDAPAttributeSet attributeSet = nextEntry.getAttributeSet();
    Iterator allAttributes = attributeSet.iterator();

 

    while(allAttributes.hasNext())
    {
     LDAPAttribute attribute = (LDAPAttribute)allAttributes.next();
     String attributeName = attribute.getName();
     System.out.println("    " + attributeName);

 

     Enumeration allValues = attribute.getStringValues();

 

     if( allValues != null)
     {
      while(allValues.hasMoreElements())
      {
       String Value = (String) allValues.nextElement();
       if (Base64.isLDIFSafe(Value))
       {
        // is printable
        System.out.println("      " + Value);
       }
       else
       {
        // base64 encode and then print out
        Value = Base64.encode(Value.getBytes());
        System.out.println("      " + Value);
       }
      }
     }
    }
   }
  }
  catch( LDAPException e )
  {
   e.printStackTrace();
   System.exit(-1);
  }
 }
}

@novell.com Susan Perrin

unread,
Jan 30, 2006, 5:28:48 PM1/30/06
to

@novell.com Susan Perrin

unread,
Jan 31, 2006, 2:23:11 PM1/31/06
to
Hi
 
Regarding the connection pool class you might want to look at the discussion "LDAPConnection from PoolManager fails to reconnect when connection is dropped by LDAPServer" 1/4/2006.  The connection pool class used to be a sample, and I think it would be better that way... it needs some work.  I haven't worked with the implementation that Jim posted, but I assume he's worked through some of the issues.  I have forwarded those issues reported  here to the engineering team.  At this time, I would look at the pool manager classes as a starting place with the understanding that they require some customization for specific needs.  Specifically, they aren't dealing very well with handling disconnection exceptions. 
 
Cloned LDAPConnections share the underlying physical tcp/ip socket with the original.  They also share the current bind state.  Each maintains its own context, including constraints settings.
 
You call disconnect() on a clone to disassociate it from the underlying LDAPConnection.
 
Thank you
Susan
 
 

Roytman, Alex

unread,
Jan 31, 2006, 2:35:30 PM1/31/06
to

Thank you very much Susan. I have implemented my own simplistic pool based on your suggestion to use SERVER_SHUTDOWN message, making sure dead connections are removed and never given to pool user I will look into your sample for more details.

 

Does clone clones constraints from master connection?

 

Thanks again

 

Alex

 

From: jldap-de...@forge.novell.com [mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Tuesday, January 31, 2006 2:23 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

 

Hi

@novell.com Susan Perrin

unread,
Jan 31, 2006, 4:03:07 PM1/31/06
to
Hi
 
When you clone a LDAPConnection, the resulting cloned LDAPConnection inherits the constraints settings of the parent.  However, any modifications to the constraints property of the clone are independent of the parent LDAPConnection.
 
BTW, although you can get exceptions for the server going down, and local client socket problems, if I just pull the lan connection on my server, my client will wait indefinitely.  The engineering team is looking into enabling a read timeout on the connections.  I don't know whether this change will make it into the March NDK yet.
 
Thanks
Susan

Roytman, Alex

unread,
Jan 31, 2006, 4:08:20 PM1/31/06
to

Susan,

 

This is exactly my problem – LDAP goes down all client connections hang. As I mentioned in my first email, even if I supply a custom Socket Factory which sets soTimeout every time Socket is created client will

wait indefinitely. Can’t wait for the fix J

 

Thanks again for your kind assistance

 

Alex

 

From: jldap-de...@forge.novell.com [mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Tuesday, January 31, 2006 4:03 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

 

Hi

@novell.com Susan Perrin

unread,
Jan 31, 2006, 4:09:44 PM1/31/06
to
I guess it all depends on what you mean by " LDAP goes down".  At least when it's a clean shutdown, you can catch it.
 
I'll let you know if I get something better to test.
 
Thanks
Susan

Mark Andersen

unread,
Jan 31, 2006, 9:47:48 PM1/31/06
to
I have run into a similar situation. One possible solution is to execute
the ldap operation in a separate thread and then do a join with a max wait
time. Now this is a problem if you are in an EJB, but works well if you
are not in a container. My connection pool framework has a flag to decide
whether to run the LDAP operations in a separate thread or not.

It also helps to interrupt the thread so it will return and then close the
connection. The interrupt happens immediately on Solaris as it supports
interruptable IO but no on Windows.

BTW, is this more of a socket problem with java? I seem to hear about other
socket operations in java that have problems similar to this. Especially
when the machine disappears (as in the case when you pull the network cord).

Mark


----Original Message Follows----
From: "Susan Perrin" <dev...@novell.com>
Reply-To: jlda...@forge.novell.com


To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

Date: Tue, 31 Jan 2006 21:09:44 GMT

Jim Willeke

unread,
Jan 31, 2006, 11:16:54 PM1/31/06
to
Susan -
This is the same issue we looked into sometime back.
It is during a "non-clean" shutdown that issue occurs.
At this point the client would have to have an established TCP
connection to the server and have made a successful connection to the
LDAP service.

If the LDAP service becomes un-responsive, then the connection fails and
the TCP session never drops.

When we spoke of this before, the solution was to create our own
"SocketFactory" setting a timeout on the socket and then use
LDAPConnection.setSocketFactory(myTLSFactory).

What we were hoping for was an exposed method so we could access the
methods on the base socket class to set the parameter for the socket.
The methods for the socket class is java.net.socket.

As I remember the methods that were of interest to our team at the time
were:

setSoTimeout(int timeout) Enable/disable SO_TIMEOUT with the specified
timeout, in milliseconds.

Hopefully, this setSoTimeout would help the "hang" problem that has been
experianced.

and

setTcpNoDelay(boolean on) - Enable/disable TCP_NODELAY (disable/enable
Nagle's algorithm).

What we have found with Nagle' algorithm, which tries to maximize the
TCP payload, that the typical LDAP client send such small TCP packets
that disabling Nagle should/would improve performance.

It would be really nice if Nagle could be disabled on the LDAP server
socket (SUN's server does expose this form the server) as many of the
response packets from the server contain only 0 or 1 as a response; but
that is another story.

-jim

Roytman, Alex

unread,
Feb 1, 2006, 1:53:31 AM2/1/06
to
Jim,

Did setting soTimeout in custom socket factory work for you? Does not
seem to work for me

Thank you

Alex

-----Original Message-----
From: jldap-de...@forge.novell.com
[mailto:jldap-de...@forge.novell.com] On Behalf Of Jim Willeke
Sent: Tuesday, January 31, 2006 11:17 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

@novell.com Susan Perrin

unread,
Feb 1, 2006, 1:52:55 PM2/1/06
to
Hi

Yes, your solution seems along the lines (only even more straightforward
than) the example at
http://developer.novell.com/ndk/doc/samplecode/jldap_sample/ConnectTimeOut.java.html.
Here they're just thinking about the connect possibility, but it gets a bit
more complex with additional functionality.

Your point about the underlying socket is right, I think. It was easy
enough to use blocking reads but what do you do when the connection is
broken without any shutdown information? This seems like a good article:
http://www.javacoffeebreak.com/articles/network_timeouts/ The problem with
the socket options is that they require jdk 1.4 or higher, but I believe
(please post if you disagree) that this is an acceptable requirement these
days.

Thanks
Susan


@novell.com Susan Perrin

unread,
Feb 1, 2006, 1:55:37 PM2/1/06
to
> It would be really nice if Nagle could be disabled on the LDAP server
> socket (SUN's server does expose this form the server) as many of the
> response packets from the server contain only 0 or 1 as a response; but
> that is another story.

Sounds like a reasonable bug/enhancement request to me. I'll submit it to
the eDir team. thanks!

Susan


Roytman, Alex

unread,
Feb 1, 2006, 1:58:01 PM2/1/06
to
Susan,

JDK 1.4 actually 1.5 is acceptable and desirable for us.

But as I said my setting soTimeout on underlying socket in socket
factory does not seem to help on LDAP unload (I will test on network
connection broken). Why do you think is that? May be unloading LDAP does
not close open sockets on netware?

Thank you very much

Alex


-----Original Message-----
From: jldap-de...@forge.novell.com
[mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Wednesday, February 01, 2006 1:53 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

Roytman, Alex

unread,
Feb 1, 2006, 2:15:37 PM2/1/06
to
Susan,

I tested socket timeout by unplugging my firewall from internet and it
worked! So socket does timeout as it suppose to if I use my custom
socket factory and set soTimeout. Now back to this peculiar issue of
socket not timing out on LDAP.NLM unload. Any idea why? It is not
critical any more since we implemented SERVER_SHUTDOWN handling but I
still would like to understand why it is happening.

Thank you

@novell.com Susan Perrin

unread,
Feb 1, 2006, 5:29:45 PM2/1/06
to
Hi

I think it's where you are... I'm seeing a problem if I connect/bind/unload
nldap.nlm then search. It's waiting indefinitly on a write semaphore but
the io exception is not processed. This looks like a thread synch issue.
I'll look into it as possible bug.

Thanks
Susan


@novell.com Susan Perrin

unread,
Feb 1, 2006, 6:22:20 PM2/1/06
to
Hi

I think it's a thread timing thing. I'm looking into it. Without the
unsolicited handler I'm getting stuck in a semaphore wait.

Thanks for pointing this out.

Susan


Roytman, Alex

unread,
Feb 1, 2006, 6:25:20 PM2/1/06
to
Yes thanks for letting me know. Eagerly waiting for a fix :-)

Alex

-----Original Message-----
From: jldap-de...@forge.novell.com
[mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Wednesday, February 01, 2006 6:22 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

@novell.com Susan Perrin

unread,
Feb 2, 2006, 4:01:45 PM2/2/06
to
correction,
 
   if(myMsg == LDAPConnection.SERVER_SHUTDOWN_OID)
 
should be
 
if(myMsg.equals(LDAPConnection.SERVER_SHUTDOWN_OID))
 
Sorry
Susan
 

Roytman, Alex

unread,
Feb 2, 2006, 4:31:36 PM2/2/06
to

Well actually it should be

if (LDAPConnection.SERVER_SHUTDOWN_OID.eqals(myMsg))  {

}

 

To guard agains NullPointerException right? J

From: jldap-de...@forge.novell.com [mailto:jldap-de...@forge.novell.com] On Behalf Of Susan Perrin
Sent: Thursday, February 02, 2006 4:02 PM
To: jlda...@forge.novell.com
Subject: Re: LDAP Hangs

 

correction,

@novell.com Susan Perrin

unread,
Feb 3, 2006, 1:09:42 PM2/3/06
to
yes, thank you!
0 new messages