> > We used the commons pooling approach in the end but only creating one > ConfigurationContext. This seems to work well. The only thing that worries > me now is Deepals last comment. Any insight into this? > Well cleaning up the transports is good in every cases, specially when you use the case configuration context and if you try to invoke considerable amount of service call. Then you will get some exception due to open client sockets. So to clean them service client has an API.
If you do not have any problem with what you are doing, then you do not need to worry about the transport cleanup, but in a long run you might need to clean the transports. Deepal > Merry Xmas. > > -----Original Message----- > From: Deepal jayasinghe [mailto:deep...@gmail.com] > Sent: 21 December 2008 15:00 > To: axis-user@ws.apache.org > Subject: Re: thread safe axis2 client stub > > Yes, creating ConfigurationContext is very expensive since it involve > reading various files. So as Thilina mentioned create a ConfigurationContext > and use the created ConfigurationContext for subsequent call. Simply when > you create the stub pass the same configuration context. > > However when you use this approach, do not forget to cleanup the transport. > You can do that by getting the service client from the stub, and calling its > cleanup transport method. > > Deepal > >> AFAIK creating a stub is not expensive, but creating the >> AxisConfiguration & ConfigurationContext is very expensive. You can >> create one AxisConfiguration & ConfigurationContext and share it >> across any number of clients. No need to create them per thread basis.. >> >> thanks, >> Thilina >> >> On Mon, Dec 15, 2008 at 12:51 AM, Shehan Simen <ssi...@itree.com.au >> <mailto:ssi...@itree.com.au>> wrote: >> >> Hi Samera, >> >> So do we have to create a ConfigurationContext for each thread? >> Is'nt it too much for each thread? >> >> >> >> Regards, >> >> Shehan >> >> >> >> *From:* Sameera Jayasoma [mailto:sameera.madus...@gmail.com >> <mailto:sameera.madus...@gmail.com>] >> *Sent:* 2008-12-15 15:06 >> >> *To:* axis-user@ws.apache.org <mailto:axis-user@ws.apache.org> >> *Subject:* Re: thread safe axis2 client stub >> >> >> >> >> >> On Tue, Dec 9, 2008 at 9:50 PM, Paul French >> <paul.fre...@kirona.com <mailto:paul.fre...@kirona.com>> wrote: >> >> This seems strange to me that the client stub cannot be made >> thread safe. >> >> >> >> After reading the below I have changed my client service to create >> the client stub on each call to one of my service methods since >> the client stub is not thread safe. >> >> >> >> I have no idea how inefficient this is? I have noticed that every >> time I create the client stub (for each and every call) I get the >> message: >> >> >> >> `[INFO] Deploying module: metadataExchange - >> file:/C:/downloads/axis2/axis2-1.4.1/lib/mex-1.4.1.jar >> >> It suggests a lot of work is going on to simply service a single >> web service call. >> >> >> you get the above message, when creating a new >> ConfigurationContext instance. Creating a CC instance is a heavy >> operation, therefore you can instantiate a CC instance once and >> use it for all subsequent calls. >> >> Sameera >> >> >> >> >> The link below suggests some tricks you can do to make things >> more efficient. What are these tricks? >> >> >> >> Thanks >> >> Paul >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Amila Suriarachchi [mailto:amilasuriarach...@gmail.com >> <mailto:amilasuriarach...@gmail.com>] >> >> *Sent:* 09 December 2008 04:26 >> >> >> *To:* axis-user@ws.apache.org <mailto:axis-user@ws.apache.org> >> *Subject:* Re: thread safe axis2 client stub >> >> >> >> I was not aware of this. If the axis2 design not permits this >> it is better not to use it. >> >> thanks, >> Amila. >> >> On Mon, Dec 8, 2008 at 10:00 AM, Shehan Simen >> <ssi...@itree.com.au <mailto:ssi...@itree.com.au>> wrote: >> >> Also this link: >> >> >> http://markmail.org/message/iif5rdpgqahk4u5t#query:axis2%20client%20st >> ub%20thread%20safe+page:2+mid:eenup3ck5ib6fzqq+state:results >> >> >> >> >> >> *From:* Amila Suriarachchi [mailto:amilasuriarach...@gmail.com >> <mailto:amilasuriarach...@gmail.com>] >> *Sent:* 2008-12-08 15:26 >> >> >> *To:* axis-user@ws.apache.org <mailto:axis-user@ws.apache.org> >> *Subject:* Re: thread safe axis2 client stub >> >> >> >> I have tested with Axis2 1.4 and it worked fine. can you >> please send the mail thread you mentioned? >> >> thanks, >> Amila. >> >> On Mon, Dec 8, 2008 at 9:48 AM, Shehan Simen >> <ssi...@itree.com.au <mailto:ssi...@itree.com.au>> wrote: >> >> Hi Amila, >> >> Thank you for your response. But I found in some discussion, >> it is saying that the client stub is not thread safe. Is this >> problem fixed now? In which version I can find it then? >> >> >> >> Regards, >> >> Shehan >> >> >> >> *From:* Amila Suriarachchi [mailto:amilasuriarach...@gmail.com >> <mailto:amilasuriarach...@gmail.com>] >> *Sent:* 2008-12-08 15:13 >> *To:* axis-user@ws.apache.org <mailto:axis-user@ws.apache.org> >> *Subject:* Re: thread safe axis2 client stub >> >> >> >> yes >> >> thanks, >> Amila. >> >> On Mon, Dec 8, 2008 at 9:31 AM, Shehan Simen >> <ssi...@itree.com.au <mailto:ssi...@itree.com.au>> wrote: >> >> Hi, >> >> I am going to invoke a web service via a client stub generated >> by axis2. >> >> I want to have a single instance of the stub across my >> application. >> >> So when I initiate the stub (when I call the constructor), I >> don't like to call it again throughout my application. >> >> Is it thread safe? >> >> >> >> Regards, >> >> Shehan >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> >> >> >> >> -- >> Sameera >> http://sameera-jayasoma.blogspot.com/ >> http://www.flickr.com/photos/sameera-jayasoma >> >> >> >> >> -- >> Thilina Gunarathne - http://thilinag.blogspot.com >> > > > -- Thank you! http://blogs.deepal.org http://deepal.org
