IW's LDAP module holds on to IP sockets?

Hi,

I've got TS 5.5.2 running on Solaris 2.8 and pointing to an NDS server for LDAP authentication.

My NDS admin called me up and told me that he thinks the TeamSite server holds on to network sockets connecting to the NDS server and doesn't ever kill the connections. In otherwords, after several days of an IW-LDAP connection, there are hundreds of ports in the TCP/IP IDLE_WAIT state that should time out.

Has anyone else experienced anything like this?

Hey Interwoven: do you guys know anything about this?

Thanks,
Tom

Find more posts tagged with

Comments

Adam Stoller

From one of our Engineers...

It's due to a file descriptor leak in Sun's 'libc' code that only shows up when the Naming Service for groups is set to LDAP or NDS. Sun hasn't fixed the bug, but current TeamSite versions avoid the faulty call.

Solution:
If you are running TS 5.5.X, upgrade to TS5.5.2 SP1.
If you are running TS 5.0.X, upgrade to TS5.0.2 SP1.

--fish
(Interwoven Senior Technical Consultant)

tvaughan

Hey Fish,

Thanks for the quick reply (as always). I'm running 5.5.2 with SP1 on Solaris 2.8 and I'm still seeing the behavior.

Are you sure SP1 fixed the problem?

I noticed that there's a file in my iw-logs directory named 'hs_err_pid2775.log'. When I cat that file, I see:


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 10 occurred at PC=0xff3634fc
Function name=thr_sighndlrinfo
Library=/usr/lib/libthread.so.1

Current Java thread:
        at java.lang.Thread.start(Native Method)
        at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:351)
        at java.lang.Thread.run(Thread.java:484)

Dynamic libraries:
0x10000         /teamsite/iw-home/tools/java1.3/bin/../bin/sparc/native_threads/java
0xff350000      /usr/lib/libthread.so.1
0xff390000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff330000      /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
0xfe000000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/server/libjvm.so
0xff2e0000      /usr/lib/libCrun.so.1
0xff1e0000      /usr/lib/libsocket.so.1
0xff100000      /usr/lib/libnsl.so.1
0xff0d0000      /usr/lib/libm.so.1
0xff310000      /usr/lib/libw.so.1
0xff0b0000      /usr/lib/libmp.so.2
0xff080000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/native_threads/libhpi.so
0xff050000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/libverify.so
0xfe7c0000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/libjava.so
0xff020000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/libzip.so
0xf0400000      /teamsite/iw-home/iwopenapi/libopenapijni.so
0xf1d80000      /teamsite/iw-home/lib/libldapssl41.so
0xfdd60000      /teamsite/iw-home/lib/libplc3.so
0xfdd40000      /teamsite/iw-home/lib/libplds3.so
0xfcfb0000      /teamsite/iw-home/lib/libnspr3.so
0xfcce0000      /usr/lib/libpam.so.1
0xfccc0000      /usr/lib/libpthread.so.1
0xfcca0000      /usr/lib/libposix4.so.1
0xfcc50000      /usr/lib/libresolv.so.2
0xfcc30000      /usr/lib/libaio.so.1
0xfabb0000      /teamsite/iw-home/tools/java1.3/jre/lib/sparc/libnet.so
0xfab90000      /usr/lib/nss_files.so.1

Local Time = Fri Nov 15 09:49:18 2002
Elapsed Time = 69323
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Server VM (1.3.1-b24 mixed mode)
#

So maybe the call isn't being avoided in all instances.

Tom

Migrateduser

Tom,
The java trace file has nothing to do with the ldap iwserver issue. The trace file is most likely from an openapi crash (just looking at the libraries that are listed).

On the ldap issue, are you sure you are up to date on your solaris recommended patch clusters? There have been some fixes recently that have effected performance of ldap/pam/nscd and I believe that some of the library upgrades may effect the ldap performance you are seeing (since iwserver may use some of the local ldap libraries dynamically)