Unrelated TCP sockets affected!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi All,
I realize this is a very peculiar situation, and I was sceptical about
this "finding" also, but after days of debugging, this is what things have
narrowed down to:

I have an app (originaly a Web app, but I am able to replicate the issue in
a WinForm app also) that calls on a 3rd party DLL through PInvoke. The
library connects to a remote 3rd party server thorough TCP/IP to perform some
EDI data processing. We started noticing that every one of these TCP
connections remain in the "CLOSE_WAIT" state until the process is shut down.
At first, we assumed it's a problem with the 3rd party ilibrary. However,
after further investigation, we found that this only happens if we connect to
a SQL server first!

To clarify, if we use the 3rd party library without ever connecting to the
SQL server, then the TCP connections close properly in a timely manner.
However, once a SqlConnection.Open() call is made (and loaded modules in VS
show System.EnterpriseServices.dll, and System.EnterpriseServices.thunk.dll
loaded), any subsequent call to the 3rd party DLL starts to hang in the
CLOSE-WAIT state indefinitely.

I tried to see if turning off the connection pooling would affect this,
but it did not. Please note that I do not have to run any commands agains the
database for this to occur. As long as I do SqlConnection.Open(), this
problem starts!

I am beyong confused! I know this 3rd party DLL is written in VC++. I have
a unsubstiated theory that perhaps perhaps the SQL DLL and this 3rd party DLL
have the same base address, and the 3rd party DLL gets rebased by he OS
loader, and thus cannot be unloaded, causing the bug to appear. (I am
grabbing at straws).

Any ideas/suggestions? Please help!!!

Thanks,
Muj Beg
 
Try to do EDI (3rd party dll) work in a separate appDomain, so that
socket (handle) inheritance can be avoided (when not directly using
win32 apis).
 
Thanks for your suggestion.

I tried the seperate AppDomain aproach also, but that did not work either.
Process level isolation works in this case, but AppDomain level isolation
does not.

Thanks,
Muj Beg
 
Have you tried sniffing to find out what the endpoints of those connections
are?

ALso, could the 3rd party library be using some SQL feature of connection
pooling, which gets activated when it detects that a SQL.Open() has been
made?


--
feroze

-----------------
This posting is provided as-is. It offers no warranties and assigns no
rights.

See http://weblogs.asp.net/feroze_daud for System.Net related posts.
----------------
 
Back
Top