【问题标题】:File descriptor leak when getting response code. (cxf, ssl)获取响应代码时文件描述符泄漏。 (cxf, ssl)
【发布时间】:2017-03-24 14:14:13
【问题描述】:

我们在生产中遇到了很长一段时间的问题......

这是对my other question 的跟进,但有更多细节,所以我认为将其作为一个新问题发布是合理的(如果不是,我会将此信息添加到另一个问题中)。

这里是:

因此,我们在使用 cxf 的应用程序使用 (ibm) java 6 weblogic 的 aix 上发生了文件描述符泄漏,并且我们解决了我们自己的 Web 服务以及路由到我们的 ws 的 jsb。

当在 weblogic 启动中使用File Leak Detector 作为代理并以编程方式转储 getCurrentOpenFiles() 和过滤 Listener.SocketRecord 时,我们有 2000 多个打开的套接字;

这些是 java 套接字和文件描述符,net-sockets(用 netstat 查看)按时间正确关闭,但程序化的(以及用 netstat 查看的)

lsof -p $pid_of_managed_server 2> /dev/null|grep TCP|wc -l

)保持打开状态(并最终导致打开文件过多的问题)。

这是 jvm 中打开的文件描述符之一的堆栈的头部:

record socket to tst-cjcsr.com/10.239.7.19:443 by thread:[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' on Thu Nov 10 10:25:56 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.$Proxy380.requestOurRecord(Unknown Source)
    at some.package.application.dossier.DossierBean$1.call(DossierBean.java:225)

我可以想象这是一个应用问题,因为我在网上找不到其他有类似缺陷的案例。

有没有人可以从这个堆栈中理解更多?

例如:HTTPConduit.close() 想要创建 一个连接让我觉得很奇怪......

还有一点: 对于非 https 调用,相同的技术堆栈不会出现此问题。 (这确实有道理,因为堆栈跟踪提到了 HttpsClient)

CXF 版本:2.7.18

cxf 配置:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:soap="http://cxf.apache.org/bindings/soap"
       xmlns:cxf="http://cxf.apache.org/core"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
            http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
            http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
            http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
            http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
    <import resource="classpath:META-INF/cxf/cxf.xml"/>

    <context:property-placeholder location="file:${config.file.location}cjr-extract-${environment}.properties"/>

    <jaxws:client id="OurService"
                  serviceClass="some.package.ws.extract.generated.OurService"
                  address="${ws.extract.wsdl.endpoint}">
        <jaxws:binding>
            <soap:soapBinding version="1.2"/>
        </jaxws:binding>
    </jaxws:client>

    <cxf:bus>
        <cxf:outInterceptors>
            <bean class="our.package.interceptors.SomeInterceptor"
                  id="webSecurityInterceptor">
                <constructor-arg>
                    <map>
                        <entry key="action" value="Timestamp Signature"/>
                        <entry key="user" value="${org.apache.ws.security.crypto.merlin.keystore.alias}"/>
                        <entry key="passwordCallbackRef">
                            <ref bean="passwordCallBack"/>
                        </entry>
                        <!--entry key="signaturePropFile" value="properties/our.properties"/-->
                        <entry key="signaturePropFile" value="file:${location}/our.properties"/>
                        <entry key="signatureKeyIdentifier" value="DirectReference" />
                    </map>
                </constructor-arg>
            </bean>
        </cxf:outInterceptors>
        <cxf:properties>
            <entry key="signatureParts"
                   value="{Element}{http://www.w3.org/2003/05/soap-envelope}Body;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp"/>
        </cxf:properties>
    </cxf:bus>

    <bean id="passwordCallBack" class="our.package.authentication.PasswordCallbackHandler">
        <property name="password" value="${password}"/>
        <property name="alias" value="${org.apache.ws.security.crypto.merlin.keystore.alias}"/>
    </bean>
</beans>

Java:

java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr15fp1-20140110_01(SR15 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 jvmap3260sr15-
20131231_180656 (JIT enabled, AOT enabled)
J9VM - 20131231_180656
JIT  - r9_20130920_46510ifx3
GC   - GA24_Java6_SR15_20131231_1152_B180656)
JCL  - 20140107_01

Weblogic 10.3.6

感谢您的提示、指点,当然还有 - 如果可能的话 - 回答 ;-)

S.

EJP 请求的代码,这里是:

调用本身:

private OurService ourservice;

private Callable<RequestOurRecordResponse> callService(final RequestOurRecordRequest request) {
    return new Callable<RequestOurRecordResponse>() {
        @Override
        public RequestOurRecordResponse call() throws Exception {
            try {
                return ourService.requestOurRecord(request); // this is line 225.
            } catch (Exception e) {
                facesMessages.error("technicalError");
                log.error("Encountered technical error", e);
                return null;
            }
        }
    };
}

生成的网络服务:

package some.package.ws.extract.generated;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.bind.annotation.XmlSeeAlso;


/**
 * This class was generated by the JAX-WS RI.
 * JAX-WS RI 2.1.7-b01-
 * Generated source version: 2.1
 * 
 */
@WebService(name = "OurService", targetNamespace = "http://secret/service-v1.0-rc2")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@XmlSeeAlso({
    ObjectFactory.class
})
public interface OurService {
    /**
     * 
     * @param requestOurRecordRequest
     * @return
     *     returns some.package.ws.extract.generated.RequestOurRecordResponse
     */
    @WebMethod(action = "http://secret/service/RequestOurRecord")
    @WebResult(name = "requestOurRecordResponse", targetNamespace = "http://secret/service-v1.0-rc2", partName = "requestOurRecordResponse")
    public RequestOurRecordResponse requestOurRecord(
        @WebParam(name = "requestOurRecordRequest", targetNamespace = "http://secret/service-v1.0-rc2", partName = "requestOurRecordRequest")
        RequestOurRecordRequest requestOurRecordRequest);
}

与:

<http-conf:conduit name="*.http-conduit">
    <http-conf:client Connection="Close" />
</http-conf:conduit>

连接(操作系统级别)关闭;但我们仍然有泄漏(上述行为)。

与:

<http-conf:conduit name="*.http-conduit">
    <http-conf:client Connection="Keep-Alive" />
</http-conf:conduit>

作为文件描述符的两个连接(操作系统级别)都在不断上升......

(附加信息:操作系统级别的连接断开(我猜是超时后),但文件描述符保持打开状态......)

【问题讨论】:

  • @EJP 问题出在CXF的配置上。这就是为什么没有代码。我不能去粘贴 CXF 的代码:我们只是不知道那里发生了什么。你想要调用的代码吗?好的,这没问题,会在几分钟内完成,但不会再给你任何提示。
  • @EJP: 所有打开的文件描述符似乎都停留在 java.net.PlainSocketImpl.create(PlainSocketImpl.java:188);我们可以在 OpenJdk 中搜索此代码,但不能在 IBM 中搜索(这会导致问题); stacktrace使用了很多weblogic内部代码,我们调用的是cxf,但是我们的代码仅限于Olivier提供的代码(以我提供的config)
  • 你试过超时吗?如果你还没有检查我发现这个问题stackoverflow.com/questions/5656458/…
  • 感谢@HRgiger,我们已经增加了打开文件的限制。它只会将问题推迟到以后的时间,我们不能走得更高。我们一定会检查 TIME_WAIT 设置。
  • @HRgiger:我们做到了:tcp_timewait(它是一台 aix 机器)设置为 1 -> 这意味着 15 秒;泄漏的不是网络连接,而是与它们关联的文件描述符;网络连接被正确关闭,但文件描述符仍然存在并增加......不过感谢您的建议......

标签: java ssl cxf aix file-descriptor


【解决方案1】:

从我的角度来看,问题与 cxf 配置有关,也许 weblogic + cxf 的相互作用也是一个问题,因为它是管理连接的 cxf 组件(参见堆栈跟踪)。所以我建议尝试使用不同的 keep-alive 设置(如何设置 keep-alive 描述了here)。似乎这并没有帮助击败打开的文件描述符。

更新:

仔细考虑你的问题后:

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)

似乎在关闭 http 连接时,cxf 会尝试取回一些响应代码并为此创建一个套接字,因为这些套接字只是等待永远不会无限期地产生泄漏的响应。整个流程在 Simplified Client Workflow 部分下描述 here。那么,下一个问题是,tst-cjcsr.just.fgov.be 会回复吗?而且,我的下一个建议是为http-conf:client 配置ReceiveTimeout,如上面link 中所述。

【讨论】:

  • 这与 HRgiger 的 cmets 有何不同? Bamboomy 已经声明连接已关闭。只有文件描述符保持打开状态。
  • 从我的角度来看,问题与 cxf 配置有关,也许 weblogic + cxf 的相互作用也是一个问题。通过将 keep-alive 设置为 false,我希望 cxf 将显式关闭套接字,因此文件描述符将被释放。 Bamboomy 表示,如果我理解正确,以编程方式打开的套接字会保持打开状态
  • 这对我来说很有意义,我会试一试并告诉你,这将在明天早上左右;感谢您的建议(以及开箱即用的想法;))
  • 我已经编辑了这个问题,“Keep-Alive”和“close”作为“Connection”的值都存在问题......
  • 我们正在积极尝试让您的见解在我们的代码中发挥作用,然后我无法再奖励赏金,到目前为止还没有成功。
猜你喜欢
  • 1970-01-01
  • 2015-09-23
  • 1970-01-01
  • 2011-01-15
  • 2014-09-20
  • 2020-01-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多