axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: [Threads] Implementation of SOAPTransport interface using LibWWW for client
Date Mon, 09 Aug 2004 08:27:17 GMT

Hi Samisa,

So, just to confirm what you are saying:

 A user creates a Stub, they can set up that stub then call the service.
After that they have to throw away that stub and then recreate another one
to call the next method on the service (or even the same method)?

Have you tested the scenario of having to create another instance of the
stub in the same process?

Thanks for all your efforts with libwww - you obviously know it inside out
now :-)

John Hawkins

             Samisa Abeysinghe                                             
   >                                               To 
                                       Apache AXIS C Developers List       
             09/08/2004 07:46          <>          
             Please respond to                                     Subject 
              "Apache AXIS C           Re: [Threads] Implementation of     
             Developers List"          SOAPTransport interface using       
                                       LibWWW for client                   

Hi All,
    I have been spending so much time (in fact too much ;-)) on getting
LibWWW transport to be
thread safe.

    I have managed to get the threaded client working with LibWWW with
    The restriction is that a thread could dispatch only one method call
per stub. If you try to
dispatch two or more then the client fails.
    The problem could be fixed. But with the current desing of the way in
which the stub handles
the trasport prohibits this. One main problem is that the Stub creates a
new trasport object for
each method invocation. This prevents me doing some one off lib level
initializations of trasport
(this is a must in LibWWW). This could be solved by having thread specific
logic (e.g. use of
locking) in the trasport code itself. However, I do not think this is the
correct way to do it
because then we have to  have thread specific code in the trasport.
    The problems are mainly due to the fact that the level of control that
we can have on the way
we control trasport from the Stub. This is acceptable with AxisTransport,
which is the original
transport of Axis C++. However, if we are to use LibWWW in a thread safe
manner, there need to be
some drastic design cnages to the interaction between
Serializer/Deserializer and the trasport.
(Basically state management has to be re-thought) I hope these will be
taken up with the proposed
refactoring/new-design of Axis C++.
    For the time being, we have to live with LibWWW trasport not being
truely thread safe.

Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!

View raw message