Hello Supun, > First we need to think why > we need to execute Axis2/C clients in multiple threads instead of using > separate clients in different threads.
I had to read that sentence at least three times before I understood it :-) You mail does shine some light on the subject for me. Both the overhead and performance are an issue for us. And since IO is involved when initializing a stub, performance might be more important. We selected axis for our soap interface because of the adb code generation (ease of use while adding more and more soap clients). So writing a lot of code for the mep instead of 'just using the framework' is not really an option for us. I think we stay with the 'use our own thread pool and do sync calls from there' implementation of 'async' calls for now. Thanks for the input. > 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.. -- 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.
