Hi All, We have been creating a new Stub instance for every operation initiated by our client, because if we don't, subsequent operations always get confused and think they are instances of the first operation performed. I.e., if we do operation A and then operation B on the same Stub, then the operation for B sends the correct message payload to the server, but the server thinks it is another A operation; the implementation of A of course then dies because the message is of the wrong type.
In looking at the code, it seems this must be a bug as the Stub is designed to be reused across operations. Is this a known problem? We are using the http client transport. Or perhaps, the bug is on the server side not accepting a message for a different operation on the same connection? We are using the built-in http client on the server side. There is this interesting comment at the top of Stub.java: > /** > * If _maintainSession is set to true, all the calls can use the same > * ServiceContext. The user can share information through this > * ServiceContext across operations. > */ However, grep _maintainSession shows no other references in the axis2 code base. I'm wonder if this is somehow related to our issue. E.g., if the operation is somehow sticky in the ServiceContext. I don't see any other shared state than the ServiceContext (and Options) across client operations on a single Stub instance. I'm looking into this problem again because we are getting a large number of hanging TimerThreads in our client on Windows. The same behavior does not happen running on linux. Anyone seen this issue? Thanks for any help, Chuck
