Thanks again for the information.  I will post my findings based on POC.

-Dmitriy

On Wed, Sep 24, 2008 at 4:48 PM, Deepal Jayasinghe <[EMAIL PROTECTED]>wrote:

>
> > Deepal,
> > Thanks for your quick response.  It worked perfectly.  I didn't
> > realize that configuration was initialized multiple times.
> Yes , whenever you create a new service client it create a new
> configuration context.
> >
> > I have another question.  Is client listener implemented as a server
> > model?  Meaning that once it receives a response it hands it over to
> > another thread for processing?
> Which listener you mean ?
> If you are talking about the client side HTTP listener , then the answer
> is yes. It is exactly a server.
> >
> > We are considering to use asynchronous client/server to reduce the
> > load on the client and improve its throughput.
> Yes that would be a good option , in fact Axis2 has support for NIO , so
> you might be able to use that too.
> >
> > In our case we have a client application that acts more or less as a
> > proxy and does very little processing itself.  It delegate all of the
> > work synchronously to backend web services.  Responses average from
> > several hundred milliseconds to several seconds with about 400 tps.
> >
> > Would you recommend asynchronous approach or could it potentially have
> > other side affects?  All of the feedback will be much appreciated.
> I think asynchronous approach would be a good option for your
> application. However you can try both and let us know which one is
> better. Then we can learn from you .
>
> -Deepal
> >
> > Thanks,
> > Dmitriy
> >
> > On Tue, Sep 23, 2008 at 7:03 PM, Deepal Jayasinghe
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >     Did you make two calls?
> >     If so please try to share the same configuration context.
> >
> >     -Deepal
> >
> >     Dmitriy Frolov wrote:
> >     > Hi all,
> >     > I am trying to utilize axis2 asynchronous processing via callback
> >     > mechanism and 2-way HTTP transport channels.  The question I have
> is
> >     > if client stub implementation is thread safe.  Even though
> >     Inderi have
> >     > seen some reports that it is not, I was wong if anything changed in
> >     > version 1.4.1. <http://1.4.1.> <http://1.4.1.>  Assuming it is
> >     not thread safe and I
> >     > cannot share client stubs between multiple threads, is there way to
> >     > reuse same separate response listener for all of the transactions?
> >     >
> >     > I have tried creating client stubs for each thread separately,
> >     but ran
> >     > into following exception:
> >     > Sep 23, 2008 6:27:14 PM
> >     >
> >
> org.apache.axis2.transport.http.server.DefaultConnectionListenerFailureHandler
> >     > failed
> >     > WARNING: Attempt number 1 of 10 to reestalish connection listener
> >     >
> >
> [EMAIL PROTECTED]
> >     > due to failure
> >     > java.net.BindException: Address already in use: NET_Bind
> >     >     at java.net.PlainSocketImpl.socketBind(Native Method)
> >     >     at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:398)
> >     >     at java.net.ServerSocket.bind(ServerSocket.java:331)
> >     >     at java.net.ServerSocket.<init>(ServerSocket.java:197)
> >     >     at java.net.ServerSocket.<init>(ServerSocket.java:109)
> >     >     at
> >     >
> >
> org.apache.axis2.transport.http.server.DefaultConnectionListener.run(DefaultConnectionListener.java:72)
> >     >     at
> >     >
> >
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
> >     >     at
> >     >
> >
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
> >     >
> >     >
> >     > Also if there is no way to use one listener for all of the
> >     responses,
> >     > are there any optimization techniques that can be utilized like
> >     a pool
> >     > of listeners for high volume system (~400tps)?  Creating a listener
> >     > every time could be rather expensive.
> >     >
> >     > Thanks,
> >     > Dmitriy
> >
> >     --
> >     Thank you!
> >
> >
> >     http://blogs.deepal.org
> >
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >     For additional commands, e-mail: [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>
> >
> >
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to