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. 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? Supun.. On Thu, Dec 11, 2008 at 10:37 PM, Bill Mitchell <bmitch...@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.lefranc...@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&m=118404667311058&w=2 > > > > > > -----Message d'origine----- > De : Patrick van Beem [mailto:patrick.van.b...@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.b...@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
