You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@yahoo.com> on 2004/08/09 08:46:15 UTC
Re: [Threads] Implementation of 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 restrictions.
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.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Re: [Threads] Implementation of SOAPTransport interface using LibWWW for client
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> 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)?
>
Yes, John. This sounds correct. When I have multiple threads. I cannot reuse a stub object to call
another method (due to the initilizations done for each and every method)
> Have you tested the scenario of having to create another instance of the
> stub in the same process?
Yes in the same thread, more than one stub could exist.
(This was made possible by a hack that I applied make sure some of the one off inits at lib
level.)
However, dispatching multiple requests on the same stub still remains problamatic.
Thanks,
Samisa...
>
> Thanks for all your efforts with libwww - you obviously know it inside out
> now :-)
>
>
>
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 09/08/2004 07:46 <ax...@ws.apache.org>
> cc
>
> 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
> restrictions.
> 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.
> Thanks,
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: [Threads] Implementation of SOAPTransport interface using LibWWW for
client
Posted by John Hawkins <HA...@uk.ibm.com>.
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
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
09/08/2004 07:46 <ax...@ws.apache.org>
cc
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
restrictions.
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.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail