dev@glassfish.java.net

Re: JAX-WS client memory usage

From: Marshall Pierce <marshall_at_genius.com>
Date: Mon, 30 Aug 2010 11:42:18 -0700

On 08/30/2010 10:36 AM, Rama Pulavarthi wrote:
> Hi,
> Seems like you found a bug. Looking at the stack trace gives me an idea
> that this does now work now as the JAXBContext object is tightly coupled
> to the runtime model objects. As the code below shows, the runtime model
> is recreated each time getXYZPort() is called, when
> UsesJAXBContextFeature is used.
>
> boolean ownModel = useOwnSEIModel(features); // true when
> UsesJAXBContextFeature is enabled
> if (ownModel) {
> // Create a new model and do not cache it
> return createSEIPortInfo(portName, portInterface, features);
> }
>
>
> Can you file an issue with a simple reproducible test case to track this
> feature.
>
> thanks,
> Rama Pulavarthi
>
>> Rama,
>> I tried this approach (caching the response of the default factory
>> impl), but this is what happens the *second* time I try to create a
>> proxy off of the service:
>>
>> java.lang.NullPointerException
>> at
>> com.sun.xml.ws.client.sei.SEIMethodHandler.<init>(SEIMethodHandler.java:92)
>>
>> at
>> com.sun.xml.ws.client.sei.SyncMethodHandler.<init>(SyncMethodHandler.java:84)
>>
>> at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:82)
>> at
>> com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:639)
>>
>> at
>> com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:342)
>>
>> at
>> com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:324)
>>
>> at javax.xml.ws.Service.getPort(Service.java:133)
>> at
>> com.genius.crm.sf.jaxwsstub.SforceService.getSoap(SforceService.java:70)
>>
>>
>

Rama,
I've filed #881.

In the mean time, I've changed my system so that instead of caching
bindings for each org, there is a global cache of bindings. As we need
to talk to different orgs, a binding is pulled from the cache and
configured with a new (per org) endpoint and some soap headers to
provide a session id, etc. Is this a reasonable option? It seems to work
fine. The only downside I can come up with is the overhead of
reinitializing the SSL sockets when the endpoint changes. (While not
insignificant, this can be alleviated with a little improvement to the
cache to prefer bindings that are already configured with the requested
endpoint.)