Somebody tried to cache the generated stubs for reusing by concurrent clients
because instantiating of them takes too long. But every time he started 4+ concurrent clients for the same web-service, he would receive some weird exceptions from the core of Axis. This happened only in case of caching the stubs and not issue for creating new stub for every client but the performance.
Some people replied the question and mentioned the cache of stub was not hoped and the internals of the stubs may screw up if cached! If you are using the usual no
args constructor of the stub, the stub may need to create its own configuration context and that may take significant time. You can cache the config context and create the stub passing in your config context, instead of caching stub.
In the mail list, also somebody mentioned they had found two important factors to keep in mind when reusing stubs:
- The stubs are not thread safe, so you cannot use the same stub in
two concurrent threads
- Recently discovered that even the stub constructor is not thread safe! So two concurrent threads cannot call the constructor at the same time.
If you have a typical architecture that reuses client processing threads, then each needs their own stub but once it creates a stub it can continue to use that indefinitely.
Another useful thing to do is:
options.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, new Boolean(true));