Our application has been using the XCC library with Java to talk to
MarkLogic over an XDBC server that was not using SSL. This all works
brilliantly, but when we switched to using SSL, we inevitably face a
problem as the tomcat process opens more and more file descriptors, never
closing them, and ultimately running up against the OS hard limit on number
of files open. At first we figured we needed to up that limit but after a
while it became clear no limit would be high enough since the number of
open files never goes down only up.
The ML database server is a different machine than the web box running Java.
As this is happening, the lsof command on the web box shows an increasing
number of open sockets (not actual files) to the database server in a
'CLOSE_WAIT' status.
>From the interwebs re: close_wait:
"CLOSE_WAIT means pretty much exactly what it says -- the kernel is waiting
for the local process to close it's file descriptor before removing the
entry. The TCP connection has been completely torn down and the far end may
be under the impression that the connection is finito, but your end is
holding onto things."
The ML version is 4.2-9-1 and the XCC jar version is 4.2.9.
Restarting tomcat releases all the file descriptors, but we don't want a
solution that involves just restarting tomcat on a schedule. I have
checked and all our code dealing with an XCC Session object has a finally {
s.close() } block so it is not as though we are not closing our sessions.
I also want to stress that we don't see this behavior at all when not using
SSL.
Has anyone worked through this issue?
--
Josh Warner-Burke
42SIX Solutions
(e): [email protected]
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
