Re: [Axis2 0.94] Reusing a Stub across multiple operations

[Chuck Williams]

Hi Ajith, Thanks for your response.  That explains things.  We need to decide whether to try to use the current code base, or try to replicate your fixes for this issue in our current code base and wait for 0.95.  In order to use the current code base, we would need for it to be as stable as 0.94 and to have addressed all the issues I've submitted patches for:  support for choice particles, support for recursive data types, support for minOccurs=0 in both array and optional scalar cases, support for subelements with same name but different type as parent element, fix to OMStAXWrapper.getElementText() to conform to contract of getElementText(). Do you have some advice regarding whether we should upgrade now or wait until 0.95?  If we should wait until 0.95, then could we grab your new Options class and use it with our existing code base?  Making the service not be static would seem to require changes to Stub and the stub xsl template for both _service and _operations. Upgrading to your latest code and jettisoning all of our patches would be best if possible! Thanks for any advice, Chuck "Ajith Ranabahu" <[EMAIL PROTECTED]> wrote on 03/18/2006 07:11:37 PM: Hi Chuck, We discovered this as a bug in our options class and fixed it sometime back. The issue was that the parent-child hierarchy of the options objects were not getting treated properly in the getter methods. Stubs are meant to be used for multiple operations and you should be able to use one instance for multiple invocations of the same/different services! We also had a problem with the Axisservice being static inside the stub and now that is changed too. So all your issues should be solved in the latest code base :) Ajith On 3/18/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Resending with proper subject header: 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 -- Chuck Williams Manawiz Principal V: (808)885-8688 C: (415)846-9018 [EMAIL PROTECTED] Skype: manawiz AIM: hawimanawiz Yahoo: jcwxx -- Ajith Ranabahu