axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manjula Peiris <manj...@wso2.com>
Subject Re: Multi-threading
Date Sat, 13 Dec 2008 10:33:43 GMT

On Sat, 2008-12-13 at 13:02 +0500, Supun Kamburugamuva wrote:
> Hi all,
> 
> This question has being popping up time to time. First we need to
> think why we need to execute Axis2/C clients in multiple threads
> instead of using separate clients in different threads. One advantage
> of using a single client is the overhead associated with multiple
> clients. A single axis2_svc_client requires multiple axis2
> configurations and multiple environments. This is the only reasong
> comes to my mind right now for not using different axis2_svc_clients
> in different threads. If you have any other requirements please share
> with us.
> 
> If performance is the concern associated with creating multiple
> clients, there is a solution to the problem. The real entity that do
> the most important work in the client side is axis2_mep_client.

Not mep_client it is op_client.

>  axis2_svc_client is a wrapper around the mep client for make the job
> easier for the client programmer. But axis2_svc_client is not designed
> for a multithreaded environment. The problems with axis2_svc_client
> running in multiple threads is it keep tracks of the various objects
> from previous invokations. This leads to double free this resources in
> multiple threading environments.
> 
> But if we can use the mep client these problems won't be there. The
> only problem with mep client is it requires quite a bit of coding to
> make it work. If we can provide a simple thread safe method set for
> directly accessing the mep client it will be really useful. So devs
> what do you think?

Actually AFAIK, even each svc_client_send_receive creates a new
op_client and this op_client uses the configurations created from
svc_client. So svc_client is like a container which keeps the
configurations for the use of op_clients. What we need to do is we
should provide methods to application clients to create configurations
of their own. So they can pass these to op_client and do the work. 

> 
> Supun.. 
> 
> On Thu, Dec 11, 2008 at 10:37 PM, Bill Mitchell
> <bmitchell@austin.rr.com> wrote:
>         Patrick, when building a multi-threaded Axis2C client I too
>         was
>         concerned about the multiple environments.  Although your
>         statement is correct in a sense that each thread needs its own
>         environment/stub, these environments can in fact share much of
>         the underlying structures.  In practice, each thread needs its
>         own error stack, but it can certainly share the allocator and
>         logger.  And the configuration information is associated with
>         the allocator.  There is a primitive function
>         axutil_env_create_with_error_log_thread_pool() that lets you
>         share the substructures already created for the "global"
>         environment
>         created once for the application.  This way the configuration
>         information is read only once.  Axutil_env_free_masked() lets
>         each thread free just its error stack upon termination,
>         leaving
>         the allocator et.al. intact.
>         
>         I was not dealing with asynchronous operation in my
>         application,
>         so I don't know if you might need a separate thread-pool for
>         each created environment.
>         
>         Good luck,
>         Bill Mitchell
>         
>         
>         -----Original Message-----
>         From: Lefrancois, Carl [mailto:Carl.Lefrancois@axa-canada.com]
>         Sent: Thursday, December 11, 2008 9:56 AM
>         To: Apache AXIS C Developers List
>         Subject: RE : Multi-threading
>         
>         Hello Patrick,
>         
>         Manjula kindly provided a best-practice example for how to do
>         multi-threading with Axis2/C [1] (at least on the client
>         side)  if I
>         remember correctly, it was one environment per thread, and the
>         stubs
>         were per call?  Well in his example it is svc_client and not
>         stub, but
>         if I understand correctly, those two concepts are one-to-one,
>         meaning
>         one stub has one svc_client.
>         
>         >From my point of view it seems the troubles you are
>         encountering are
>         based in areas where Axis does little or nothing to help the
>         programmer.
>         I have not seen any code to manage thread creation and
>         resources acces
>         in the Axis2/C project.  Problems like resource deadlock on
>         the
>         configuration file are outside the scope of what Axis2/C has
>         to offer.
>         
>         What Axis does well is freeing resources (once we figure out
>         how to set
>         everything up right!) so I am a little confused as to where
>         exactly the
>         limitations are.  You say the callback system provided is not
>         good in
>         terms of freeing resources, but have you tried freeing your
>         resources
>         from another function which itself waits for the callback to
>         occur?
>         (either error callback or success callback)  I think this is
>         the way
>         Axis was designed with as implied by Dimuthu: wait in a loop
>         in your
>         main thread while the callbacks are outstanding, do no cleanup
>         in the
>         callback itself, let that thread exit completely and after it
>         is done,
>         then from your main thread detect that the callback ocurred
>         and do the
>         cleanup there.
>         
>         For environment vs stub issues, there is no alternative but to
>         take
>         ownership of this problem directly and implement some
>         synchronisation
>         outside the scope of Axis2/C.  Your code synchronises creation
>         of
>         threads and initialisation to avoid having deadlock problems.
>          Maybe
>         there is some improvement to be made to Axis here?
>         
>         My reason for responding though is really to comment on this
>         phrase:
>         "Threads are a rather expensive resource to use for just
>         waiting on an
>         IO completion".  It may be my lack of understanding, but I am
>         pretty
>         sure that -- at least in the win32 tcp/ip stack -- once your
>         thread goes
>         into asynchronous communication on a socket, you do not see it
>         again
>         until there is some result.  This means if there is a timeout
>         your
>         thread is inactive for a long time.  How can one thread wait
>         on more
>         than one asychronous communication?  I admit this would be a
>         far better
>         solution, however from my understanding of winsock2 it is not
>         possible.
>         
>         Seen this way, one thread per socket communication is maybe
>         expensive in
>         resources, but it is the only way to ensure your main thread
>         continues
>         to operate in a timely fashion.
>         
>         Hth
>         
>         Carl
>         
>         
>         [1]
>         http://marc.info/?l=axis-c-user&amp;m=118404667311058&amp;w=2
>         
>         
>         
>         
>         
>         -----Message d'origine-----
>         De : Patrick van Beem [mailto:patrick.van.beem@quintiq.com]
>         Envoyé : jeudi, décembre 11, 2008 05:46
>         À : axis-c-dev@ws.apache.org
>         Objet : Multi-threading
>         
>         
>         Hello,
>         
>         I'm experiencing serious limitations while using axis in a
>         multi-threading environment. I know axis is not fully designed
>         (yet?)
>         for multi-threading, but I think some 'small' changes might
>         make it more
>         usable. One can't deny multi-threading. Here my 2 cents:
>         
>         
>         * Callback and resources
>         In a multi-threading environment, an asynchronous job is often
>         responsible for freeing it's own resources (in this case, the
>         environment, the stub and possible extra application dependent
>         data). In
>         the axis framework, this can't be done in the callback, since
>         the
>         framework will use the stub after the callback is finished.
>         This makes
>         it impossible for an application to free resources after a
>         call has
>         finished (because you never know exactly when the call
>         (including the
>         framework part of it) is finished. This makes the asynchronous
>         implementation of axis useless in a job-oriented
>         multi-threading
>         environment. Improvements might include adding an extra
>         callback to free
>         resources, that is made when axis has freed all its resources
>         and does
>         not need any resources the user might free.
>         
>         
>         * Environment vs stub
>         Since every thread needs it's own environment and stub in axis
>         and (as
>         stated above) in a multi-threaded environment a job is often
>         responsible
>         of it's own resources, every job needs to allocate and
>         initialize it's
>         environment and stub for each call (or keep one set
>         initialized for
>         every thread, but that's not feasible when one thread can be
>         used for
>         multiple purposes / jobs and/or threads can be added
>         dynamically). And
>         free it after the job is finished. Apart from the (slight)
>         performance
>         drawback, this poses another problem: Part of the stub
>         initialization
>         includes reading the configuration file. When two threads try
>         to do this
>         simultaneously, the last one who tries this, fails. Solutions
>         to this
>         problem might include:
>         - Create a clone function for the stub, so all threads can
>         clone from
>         template stub, instead of reading from disk.
>         - Separate the state information from the stub and put it in
>         the
>         environment, so the stub can be used read-only and shared by
>         threads.
>         
>         
>         * Async model
>         The asynchronous call implementation of axis is based on
>         creating new
>         threads that just wait on a response. Threads are a rather
>         expensive
>         resource to use for just waiting on an IO completion (and then
>         performing some small task). It might be better that the
>         waiting on all
>         outstanding IO is done by one single thread. The work after
>         the IO
>         completed can then be done by either that thread, or a (small
>         and
>         static) thread pool. That way, no threads have to be created /
>         deleted
>         on the flow, not more than one thread is waiting on IO and no
>         high
>         amount of threads will exist when a lot of asynchronous calls
>         exist in
>         parallel. My axis knowledge is not enough to see solutions for
>         this
>         within axis right now.
>         
>         
>         What do you all think about these points?
>         
>         Regards,
>         
>         --
>         
>         
>         Patrick van Beem
>         Sr. Software engineer
>         
>         Quintiq
>         
>         T +31 (0) 73 691 07 39
>         F +31 (0) 73 691 07 54
>         M +31 (0) 06 15 01 65 83
>         E patrick.van.beem@quintiq.com
>         I www.quintiq.com
>         
>         
>         
>         This message contains information that may be privileged or
>         confidential
>         and is the property of Quintiq. It is only intended for the
>         person to
>         whom it is addressed. If you are not the intended recipient,
>         you are not
>         authorized to read, print, retain, copy, disseminate,
>         distribute or use
>         this message or any part thereof. If you have received this
>         message in
>         error, please notify the sender immediately and delete all
>         copies of
>         this message. Please note that e-mails are susceptible to
>         change,
>         therefore they are not binding.
>          _____
>         
>         "Ce message est confidentiel, à l'usage exclusif du
>         destinataire
>         ci-dessus et son contenu ne représente en aucun cas un
>         engagement de la
>         part de AXA, sauf en cas de stipulation expresse et par écrit
>         de la part
>         de AXA. Toute publication, utilisation ou diffusion, même
>         partielle,
>         doit être autorisée préalablement. Si vous n'êtes pas
>         destinataire de ce
>         message, merci d'en avertir immédiatement l'expéditeur."
>         
>         "This e-mail message is confidential, for the exclusive use of
>         the
>         addressee and its contents shall not constitute a commitment
>         by AXA,
>         except as otherwise specifically provided in writing by AXA.
>         Any
>         unauthorized disclosure, use or dissemination, either whole or
>         partial,
>         is prohibited. If you are not the intended recipient of the
>         message,
>         please notify the sender immediately."
>         
>         
>         
> 
> 
> 
> -- 
> Software Engineer, WSO2 Inc
> http://wso2.org
> Web Services with Axis2/C http://wsaxc.blospot.com
> 


Mime
View raw message