Concurrency when calling webservice clients
I have a webapp that use some webservice clients to get the data it displays.
When the load is not very high the app work just fine.
Unfortunately when the load is bigger the servers become overloaded because of the following stucked threads...
Any idea what might be the cause ?
]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
com.sun.org.apache.xml.internal.resolver.Catalog.parseCatalog(Catalog.java:660)
com.sun.xml.ws.util.xml.XmlUtil.createDefaultCatalogResolver(XmlUtil.java:251)
com.sun.xml.开发者_Python百科ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:265)
com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:228)
weblogic.wsee.jaxws.spi.WLSServiceDelegate.<init>(WLSServiceDelegate.java:52)
weblogic.wsee.jaxws.spi.WLSProvider$ServiceDelegate.<init>(WLSProvider.java:371)
weblogic.wsee.jaxws.spi.WLSProvider.createServiceDelegate(WLSProvider.java:79)
weblogic.wsee.jaxws.spi.WLSProvider.createServiceDelegate(WLSProvider.java:62)
javax.xml.ws.Service.<init>(Service.java:56)
It looks like the service client is timing out parsing the WSDL.
Ensure that the WSDL and any dependencies it imports are being loaded locally and not being fetched over the network from the service host. You can provide the path to a local WSDL via a constructor that takes a URL; you will still have to inspect your WSDL to ensure that any schemas it imports are referred to by relative URIs.
Also ensure that you reuse your Service
instances by making them application scope. Since parsing the WSDL is expensive, you want to do this as seldom as possible. Check that your JAX-WS implementation's Service
is threadsafe (I'm not aware of an implementation where they aren't but it pays to check). The ports the services create vary - in some implementations, these are threadsafe; in some they aren't.
精彩评论