You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Dmitriy Frolov <dm...@gmail.com> on 2008/09/24 00:39:44 UTC

Async processing, client stubs thread safety and port conflicts

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.  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
org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974due
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

Re: Async processing, client stubs thread safety and port conflicts

Posted by Dmitriy Frolov <dm...@gmail.com>.
How should I go about extracting wsa:MessageID from the client's
asynchronous (call and transport with a separate listener) request and
response?  Am I responsible for correlating messages together or does axis2
offer such functionality as well?

Thanks,
Dmitriy

On Wed, Sep 24, 2008 at 9:59 PM, Dmitriy Frolov <dm...@gmail.com>wrote:

> 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 <de...@opensource.lk>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
>> > <deepal@opensource.lk <ma...@opensource.lk>> 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
>> >     >
>> >
>> org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974
>> >     > 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: axis-user-unsubscribe@ws.apache.org
>> >     <ma...@ws.apache.org>
>> >     For additional commands, e-mail: axis-user-help@ws.apache.org
>> >     <ma...@ws.apache.org>
>> >
>> >
>>
>> --
>> Thank you!
>>
>>
>> http://blogs.deepal.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>

Re: Async processing, client stubs thread safety and port conflicts

Posted by Dmitriy Frolov <dm...@gmail.com>.
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 <de...@opensource.lk>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
> > <deepal@opensource.lk <ma...@opensource.lk>> 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
> >     >
> >
> org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974
> >     > 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: axis-user-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     For additional commands, e-mail: axis-user-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >
> >
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: Async processing, client stubs thread safety and port conflicts

Posted by Deepal Jayasinghe <de...@opensource.lk>.
> 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
> <deepal@opensource.lk <ma...@opensource.lk>> 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
>     >
>     org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974
>     > 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: axis-user-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-user-help@ws.apache.org
>     <ma...@ws.apache.org>
>
>

-- 
Thank you!


http://blogs.deepal.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Re: Async processing, client stubs thread safety and port conflicts

Posted by Dmitriy Frolov <dm...@gmail.com>.
Deepal,
Thanks for your quick response.  It worked perfectly.  I didn't realize that
configuration was initialized multiple times.

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?

We are considering to use asynchronous client/server to reduce the load on
the client and improve its throughput.

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.

Thanks,
Dmitriy

On Tue, Sep 23, 2008 at 7:03 PM, Deepal Jayasinghe <de...@opensource.lk>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.>  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
> > org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974
> > 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: Async processing, client stubs thread safety and port conflicts

Posted by Deepal Jayasinghe <de...@opensource.lk>.
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.>  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
> org.apache.axis2.transport.http.server.DefaultConnectionListener@49744974
> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org