Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@ws.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <441B34D3.5060700@manawiz.com>
Date: Fri, 17 Mar 2006 12:14:43 -1000
From: Chuck Williams <chuck@manawiz.com>
Organization: Manawiz
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
MIME-Version: 1.0
To: axis-user@ws.apache.org
Subject: Reusing a Stub across multiple operations
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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