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 > <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 >
