Hi,
I couldn't find official documentation on how to use client stubs,
especially regarding a environment with a high level of concurrency.
Does anyone know where can I find that information?
I found some non official opinions talking about stubs not being thread
safe, but mentioning that Service class should be reused for each instance
of stubs. I found that using that model, I got exchanged responses between
clients in a concurrent environment. So, I did an intercourse in Service
source code, and found that createCall is not thread safe because it uses a
class attribute as a temporary variable for the new Call object. What
happens is that two threads can get the same call object as I explain below.
public javax.xml.rpc.Call createCall() throws ServiceException {
(1) this._call = new org.apache.axis.client.Call(this);
(2) return this._call;
}
Suppose a thread enters and runs line (1). Then another thread enters and
runs line (1) too. Then first thread runs line (2) and viola, it is
receiving the call object for the second thread.
I also found some notes regarding the importance of reusing Service because
it manages the transports connections pool. So, I assume that it should be
reused and managed to correct the Service.createCall erroneous behavior
using a local variable to hold call until the method returns. The thing is,
I hadn't had the opportunity yet to inspect all Service source code to
evaluate it for thread safety. Does anyone did that already? And can anyone
confirm that it is really supposed to reuse it over all stub instances?
This problem derives from the fact that the system I'm working on connects
to 114 different web services and has a very high level of concurrency. If I
try to instantiate a stub and service for each call, my system goes "down"
in a few minutes, because stubs instantiation are expensive. So I'm already
using a pool for stubs. Also, I'm using an extended Service, reimplementing
the createCall as mentioned above. Does anyone has any other ideias?
Best regards,
Telmo Costa
EF - Tecnologias de Software, S.A.
Portugal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
