Dear,
I already posted on stack overflow
<http://stackoverflow.com/questions/40529499/file-descriptor-leak-when-getting-response-code-cxf-ssl>
, server fault and the oracle weblogic forums without answer, maybe I find a
solution here...
Our application suffers from a file descriptor leak...
with
lsof -p $pid_of_managed_weblogic_server 2> /dev/null|grep TCP|wc -l
we get increasingly open files +2000
we set the limit to 65000ish which pushes the limit higher but doesn't solve
the problem.
This is a stack of a stuck file descriptor with File Leak Detector:
record socket to tst-cjcsr.just.fgov.be/10.239.7.19:443 by thread:[ACTIVE]
ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' on Wed
Nov 09 14:39:10 CET 2016
at java.net.PlainSocketImpl.create(PlainSocketImpl.java:188)
at java.net.Socket.createImpl(Socket.java:411)
at java.net.Socket.connect(Socket.java:544)
at
weblogic.net.http.HttpsClient.openWrappedSSLSocket(HttpsClient.java:565)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:296)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:373)
at weblogic.net.http.HttpsClient.New(HttpsClient.java:528)
at
weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:239)
at
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:409)
at
weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
at
weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:1038)
at
org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:266)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1550)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1579)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1520)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1317)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:632)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:136)
at com.sun.proxy.$Proxy382.requestCriminalRecord(Unknown Source)
at
be.fgov.just.cjr.application.dossier.DossierBean$1.call(DossierBean.java:225)
If you have any information to share that can be useful, please do,
thanks in advance,
Sander
--
View this message in context:
http://cxf.547215.n5.nabble.com/File-descriptor-leak-possibly-solvable-by-CXF-configuration-tp5774767.html
Sent from the cxf-dev mailing list archive at Nabble.com.
