Ist xfire Client-Proxy-Thread sicher?

Question

Wenn Sie eine Anwendung zu entwickeln, die ein externer Webservice verbraucht ich die Quellen aus der WSDL-Datei-URL generiert habe und dann einen Client erstellt:

GeoIPServiceClient service = new GeoIPServiceClient();
GeoIPServiceSoap geoIPClient = service.getGeoIPServiceSoap();

Da die Erstellung dieser Proxy einige Zeit dauert, ich den Client als ein Attribut in meiner Dienstklasse festgelegt.

Aber ich mache mir Sorgen, dass der Kunde nicht sicher ist, fädeln und diese Webservice stark in der Anwendung durch gleichzeitige Threads (Webapp) verwendet wird. Ich kann keine Dokumentation zu diesem Thema finden.

Als Vorsichtsmaßnahme Ich habe angefangen, ein um ein Objekt zu verwenden Pool Seife Kunden statt eines gemeinsam genutzt.

Ist dies eine unnötige Vorsichtsmaßnahme? Was ist die beste Praxis, wenn xfire Kunden zu schreiben?

Ich vermute, eine Art von Concurrency Problem mit xfire, da ich regelmäßig, unter hohen Last, Fäden blockiert werden und als Ergebnis diesen die Anwendung abstürzt. Hier ist ein Teil-Thread-Dump:

"http-xx.xx.xx.xx-80-17" daemon prio=10 tid=0x00007f560d437000 nid=0x66cb waiting for monitor entry [0x00000000412b8000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:174)
    - waiting to lock <0x00007f561d44e1c0> (a com.sun.xml.bind.v2.runtime.reflect.opt.Injector)
    at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:85)
    at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:87)
    at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:165)
    at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:253)
    at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:231)
    at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:173)
    at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:83)
    at sun.reflect.GeneratedConstructorAccessor165.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:124)
    at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:171)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:481)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:315)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
    at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:128)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:277)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244)
    at org.codehaus.xfire.jaxb2.JaxbType.getJAXBContext(JaxbType.java:306)
    - locked <0x00007f565b3aee60> (a org.codehaus.xfire.jaxb2.JaxbType)
    at org.codehaus.xfire.jaxb2.JaxbType.writeObject(JaxbType.java:230)
    at org.codehaus.xfire.aegis.AegisBindingProvider.writeParameter(AegisBindingProvider.java:229)
    at org.codehaus.xfire.service.binding.AbstractBinding.writeParameter(AbstractBinding.java:273)
    at org.codehaus.xfire.service.binding.WrappedBinding.writeMessage(WrappedBinding.java:90)
    at org.codehaus.xfire.soap.SoapSerializer.writeMessage(SoapSerializer.java:80)
    at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:56)
    at org.codehaus.xfire.transport.http.OutMessageRequestEntity.writeRequest(OutMessageRequestEntity.java:51)
    at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499)
    at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
    at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
    at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
    at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
    at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:369)
    at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
    at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
    at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
    at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
    at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
    at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
    at org.codehaus.xfire.client.Client.invoke(Client.java:336)
    at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
    at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
    at $Proxy143.getMyMethod(Unknown Source)

Der Thread-Dump enthält viele blockierte Threads, die wie folgt aussehen.

Answer 1

Ich denke, wie Sie eine Menge blockierter Threads erhalten, der Kunde tatsächlich Thread-sicher ist als Objektdaten nicht beschädigt ist :). Aber ich stimme es nicht die Parallelität in einer guten Art und Weise der Handhabung.

1) Eine Beobachtung ist, dass die endgültige Sperre scheint in JAXB Umsetzung und nicht in XFire zu sein. Was passiert, wenn Sie versuchen, verschiedene JAXB Umsetzung mit wie JaxMe ?

2) Auch das Verfahren getJAXBContext in JaxbType synchronisiert wird. Und sehr wahrscheinlich, weil Ihre Threads denselben JaxbType Instanz zugreifen, sie blockiert werden können.

bei dieser Methode der Suche würde ich bewege eigentlich die Synchronisation in das Verfahren nach Kontext presense geprüft:

if (context == null) {
    synchronized (this)  {
         ...

Dies ist für Kunden ermöglichen wird, die bereits JAXBContext initialisiert teure Synchronisation überspringen.

Mein Vorschlag ist, entweder versuchen, den Code selbst fixiert und einen Test machen oder einen Fehler zu XFire einreichen oder beides.)

Answer 2

Abhängig von der Version von Xfire Sie verwenden, wie sie nur wenige Themen Sicherheitsfragen in der Version 1.2.5 behoben haben. Sie können den Fehler bei http://jira.codehaus.org/browse/XFIRE-886 und weitere Details siehe die Release notes auf hxxp: //xfire.codehaus.org/XFire+1.2.5+Release+Notes