[jbossws-issues] [JBoss JIRA] Created: (JBWS-2239) Provide a way to reuse Web Services proxies across multiple invocations from within EJBs

[Torsten Mielke (JIRA)]

Provide a way to reuse Web Services proxies across multiple invocations from within EJBs
----------------------------------------------------------------------------------------

                 Key: JBWS-2239
                 URL: http://jira.jboss.com/jira/browse/JBWS-2239
             Project: JBoss Web Services
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jbossws-jaxrpc
    Affects Versions:  jbossws-2.0.2
            Reporter: Torsten Mielke


This feature request is in relation to JBWS-1519 (Web Services proxy not thread safe).

When a SLSB uses a web services proxy for outgoing calls, it is highly desirable to reuse the same proxy object across multiple invocations on the SLSB. 
The reason for that is very simple: the CPU cycles required to lookup and create the port are higher than the call itself. 
Here some numbers for a simple ejb3 web service. In our opinion the getPort() operation costs too much to do in each call (the lookup of the service can be done just once without having problems with concurrency). 
     lookup 1264.7     ms
    getPort 225.7      ms
     WsCall 63.9       ms

This slow performance for getPort() is the reason for looking for a faster solution (e.g. re-use a proxy across multiple EJB invocations).

Storing the proxy in a servlet context is not a solution, it is even "forbidden" indirectly in the spec because multiple requests could use the proxy concurrently. JEE lovers could wrap the web service call in a local stateless session bean where the container assures that never two calls the same bean instance.
Another workaround could be to use a thread local to store the proxy. To do it bullet prove one would have to care also about error conditions (e.g. when an expiration from transport layer occurs the thread local needs to be set to null so that subsequent calls create a new port)
But the "thread local" workaround results in ugly application code and performance matters.

Another workaround suggested to us is to implement our own pool of proxies. This is certainly possible but should rather be provided by Web services toolkit and not rely on the application developer to be implemented.

We can think of the following options (open for discussion):
1. The getPort implementation itself could use a thread local. Probably additional code that detects that a proxy is corrupt (e.g. when the underlying transport framework has a broken connection) would be required. This would result in out of the box performance improvements for anybody using this nice ws stack.

2. Provide a pool of Web services proxies that can be used to retrieve proxy objects on demand.

3. Create documentation about "How to increase the web service performance with a thread local or a stateless session bean wrapper".


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira