2016-11-10 4 views
6

Nous avons un problème dans la production pendant un certain temps maintenant ...Fuite de descripteur de fichier lors de l'obtention du code de réponse. (CxF, ssl)

C'est un suivi de: my other question mais avec beaucoup plus de détails, donc je pense que l'affichage comme une nouvelle question est justifiée (sinon je vais juste ajouter cette information à l'autre question).

Ici, il va:

Ainsi, nous avons une fuite de descripteur de fichier sur aix avec (ibm) java 6 weblogic à l'aide d'une application à l'aide CxF et nous adressons un service Web de notre propre un aussi jsb qui achemine vers nos ws.

Lorsque vous utilisez File Leak Detector en tant qu'agent au démarrage de weblogic et que vous videz getCurrentOpenFiles() et que vous filtrez Listener.SocketRecord par programme, nous avons 2000+ sockets ouverts;

Ce sont prises java et les descripteurs de fichiers, les net-prises (vue avec netstat) sont bien fermés, par le temps, mais les programmes (et ceux vus avec

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

) rester ouvert (et finalement provoquer un trop de problèmes de fichiers ouverts)).

C'est la tête de la pile d'un de ces descripteurs de fichiers ouverts à l'intérieur du jvm:

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 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.requestCriminalRecord(Unknown Source) 
    at be.fgov.just.cjr.application.dossier.DossierBean$1.call(DossierBean.java:225) 

Je peux imaginer que cela est un problème applicatif parce que je ne peux pas trouver d'autres cas en ligne avec des défauts similaires .

Quelqu'un peut-il avoir plus de sens à partir de cette pile?

Par exemple: Il me semble étrange que HTTPConduit.close() veut créer une connexion ...

Un autre point: la question ne se produit pas avec la même pile de technologies pour non -https appels. (Ce qui ne fait sens parce que le stacktrace mentionne Http de client)

Version CXF: 2.7.18

config 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-${cjr.environment}.properties"/> 

    <jaxws:client id="CJCSCGService" 
        serviceClass="be.fgov.just.cjr.ws.extract.generated.CJCSCGService" 
        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

Merci pour les conseils, pointeurs, et, bien sûr - si possible -, réponses ;-)

S.

EJP le code demandé, la voici:

L'appel lui-même:

private CJCSCGService cjcscgService; 

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

Webservice produit:

package be.fgov.just.cjr.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 = "CJCSCGService", targetNamespace = "http://secret/service-v1.0-rc2") 
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) 
@XmlSeeAlso({ 
    ObjectFactory.class 
}) 
public interface CJCSCGService { 
    /** 
    * 
    * @param requestCriminalRecordRequest 
    * @return 
    *  returns be.fgov.just.cjr.ws.extract.generated.RequestCriminalRecordResponse 
    */ 
    @WebMethod(action = "http://secret/service/RequestCriminalRecord") 
    @WebResult(name = "requestCriminalRecordResponse", targetNamespace = "http://secret/service-v1.0-rc2", partName = "requestCriminalRecordResponse") 
    public RequestCriminalRecordResponse requestCriminalRecord(
     @WebParam(name = "requestCriminalRecordRequest", targetNamespace = "http://secret/service-v1.0-rc2", partName = "requestCriminalRecordRequest") 
     RequestCriminalRecordRequest requestCriminalRecordRequest); 
} 

avec:

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

Les connexions (niveau d'os) fermer; mais nous avons toujours la fuite (comportement indiqué ci-dessus).

avec:

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

Les deux connexions (niveau os) que les descripteurs de fichiers ne cessent d'augmenter ...

(informations complémentaires: les connexions au niveau des os diminuent (après le temps que je devinez) mais les descripteurs de fichier restent ouverts ...)

+0

@EJP Le problème est dans la configuration de CXF. C'est pourquoi il n'y a pas de code. Je ne peux pas aller coller le code de CXF: nous ne savons pas ce qui se passe en interne. Vous voulez le code qui appelle? Bien, ce n'est pas un problème, cela sera fait dans quelques minutes, mais ça ne vous donnera plus d'indices. –

+0

@EJP: Tous les descripteurs de fichiers ouverts semblent être bloqués sur java.net.PlainSocketImpl.create (PlainSocketImpl.java:188); nous pouvons rechercher ce code dans OpenJdk mais pas dans celui d'IBM (ce qui provoque le problème); la stacktrace utilise beaucoup de code interne weblogic, qui est appelé par cxf, que nous appelons, mais notre code est limité au code fourni par Olivier (avec la configuration que j'ai fournie) – Bamboomy

+0

avez-vous essayé les délais? Si vous n'avez pas encore vérifié, j'ai trouvé ce problème http://stackoverflow.com/questions/5656458/java-net-socketexception-too-many-open-files/37605213#37605213 – HRgiger

Répondre

1

De mon point de vue le problème est lié à la configuration cxf, peut-être que l'interaction de weblogic + cxf est également un problème, car c'est le composant cxf qui gère la connexion (voir le trace de la pile). J'ai donc suggéré d'essayer avec les différents paramètres keep-alive (comment définir keep-alive est décrit here). On dirait que cela n'a pas aidé à battre les descripteurs de fichiers ouverts cependant.

MISE À JOUR:

Après avoir réfléchi plus sur votre problème:

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) 

semble que lors de la fermeture connexion http le CxF tente d'obtenir un certain code de réponse et crée une prise pour cela, et que les prises attendez juste une réponse qui ne vient jamais indéfiniment qui crée une fuite. L'ensemble du flux est décrit sous here dans une section Simplified Client Workflow. Donc, la question suivante est, est-ce que tst-cjcsr.just.fgov.be répond jamais? Et, ma prochaine suggestion est de configurer ReceiveTimeout pour le http-conf:client comme décrit dans le link ci-dessus.

+0

En quoi est-ce différent des commentaires de HRgiger? Bamboomy a déjà déclaré que la connexion est fermée. C'est seulement le descripteur de fichier qui reste ouvert. –

+1

de mon point de vue le problème est lié à la configuration cxf, peut-être l'interaction de weblogic + cxf est également un problème. en définissant keep-alive sur false, j'espère que le cxf fermera explicitement les sockets et que par conséquent les descripteurs de fichiers seront libérés. Et Bamboomy a déclaré que les prises ouvertes programmées restent ouvertes si j'ai bien compris – borowis

+1

Cela me semble logique, je vais faire un tour et je vous le ferai savoir, ce sera demain matin; merci pour la suggestion (et pour réfléchir hors de la boîte;)) – Bamboomy