axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stadelmann Josef" <>
Subject AW: AW: AW: client slow after sometime.
Date Thu, 09 Jun 2011 09:28:48 GMT
Hi Jak,


Thanks that you confirm what I expected somehow.


I think the learning for everyone is to activate and only use one
feature at a time unless it is really proven how each feature works.


Axis2 has so many points one can make failures and trigger unexpected
behavior. And in particular, a multithreaded system is gaining very much
to become soon too complex to understand about what is going on.
Particular in cases one does not have a good UML activity diagram at
hand! And in particular if only a part of the whole is really thread
safe programmed. And in particular if one omits to use a debugger and
debug at the JVM's debug-port to have axis2-engine e all under control.


Testing for thread safety is another big challenge.


And how can one say ... it's thread safe  ... unless it was really
tested in many different test application. 


And how many threads are running in parallel in a average system from
client to server and back via all communication and protocol layers?


Not easy to say.







Von: Theazyfa Jak [] 
Gesendet: Mittwoch, 8. Juni 2011 09:50
Betreff: RE: AW: AW: client slow after sometime.


Hello Josef,


I started to write my answer yesterday but I had some idea about new


I test with/without MultiThreadedHttpConnectionManager, with/without
Singleton pattern and finally I finish with a very basic call with new()
objects each time.

I don't see any decrease of the response time.

So finally, I made a upgrade from Axis 2 1.4.1 to 1.5.4 and.... 


The app is up since yesterday and the response is always fine (under 100


Finally we don't really know why this latency but.. IT'S WORK !


I just have to qualify my entire apps with the new Axis2 lib ^^


Thanks a lot for your help Josef!


Best regards,



Subject: AW: AW: client slow after sometime.
Date: Tue, 7 Jun 2011 10:33:08 +0200

Good, that you have figured out that it is the client taking more time. 


Now we need a bit more insight into what you intend to do to understand
in example why you choose a particular approach7design! 

Can you explain please?


Are you running  a synchronous or asynchronous protocol? 

that is to say your client may have several requestors placing a request
on a thread.

Are your requestors waiting on their  thread unless the response for a
particular requestor on a thread is back? (Synchronous Protocol)


Are your requestors doing something busy on this thread and get
called-back on a call-back-point/routine?


Basically: why do you intend to have a

What do you expect from this MultiThreadedHttpConnectionManager?


Asynchronous: are you placing several requests at once without waiting
for a response?

Asynchronous: is your client talking to multiple service-objects
(instances) each request placed on a separate thread and delivered at a
particular instance?

Asynchronous: is your application-server, your axis2-engine, your
service-object or any stuff below really thread safe?


Could you run the same test without the
MultiThreadedHttpConnectionManager engaged?

What are your observations?


But you should consider one thing: configuring something absolute
correct but misusing it may also lead to problems!


The issue might be on which level do we expect/have the problem:
Transport TCPIP/HTTP OR above XML-SOAP and handlingby AXIS routines.

the latency is between the receive of data on client and the acknowledge
from client to server

As you observer that, it means your client code is just not involved,
because it is your TCPIP layer which as to ACK, isn't it.

And the question is, why is TCPIP not ACKing the Response to the server
just after a big delay?



Do you observe any REST (Transport Resets) in Wireshark? Then it is a
TCPIP Problem from Microsoft.


What is your architecture? In my mind, you are using a bit too many
exotic features at once!

While this is certainly not prohibited, in case of troubles - keep it
short and simple! KISS

What is the observed behavior if you engage only one feature at a time
to get control back?


Maybe some axis2/j developers implementing the
MultiThreadedHttpConnectionManager can tell you about the configuration






Von: Theazyfa Jak [] 
Gesendet: Montag, 6. Juni 2011 16:43
Betreff: RE: AW: client slow after sometime.



so I just finish some test with Wireshark.

It seems that it's the client part ( so Axis 2 ) that's slow.


the latency is between the receive of data on client and the acknowledge
from client to server.

I don't see any bottleneck on cpu or Memory.


Is there some config to have log from Axis 2 client layer?

Is my config ( first mail ) of Axis 2 client is correct?




Subject: RE: AW: client slow after sometime.
Date: Thu, 2 Jun 2011 08:37:32 +0200

Thanks for your answer Josef!

I already take the 2 time ( and I forgot to talk about ^^ sorry)

So, I always have the same time for the Server Process.
But this time is only about the 'created' code. So, I can't really know
if it's the server 'wrapped' part ( connection pool,....) is slowing or
if it's the client.

Wireshark is a very good ( and fast ) idea to found the guilty !
I do the test and I come to you with result.

Thanks to give me a new approach!



Subject: AW: client slow after sometime.
Date: Wed, 1 Jun 2011 18:55:39 +0200

It would be nice if you can find out the following:

Is the delay cause by the network or the server processing your request?


For that you can get the system time in as small a fraction as possible,
i.e. nano seconds 

1.       At the server take the system time up on entering the service
and just before you return the response.

2.       add this two entries to the response.

3.       At the client calculate the delta 

4.       This is the servers true processing time


1.       At the client side you get the system time just before you send
the message and 

2.       you catch the time when the response is back.

3.       Then you calculate the client-side-delta. 

4.       This is the total turn-around-time.



Now then you shall report to use what you observer in the beginning and
after 2/3 hours.


Basically which time increases a lot?

a)      Just the server time

b)      Just  the turnaround time at the client

c)       Both?


Maybe you can observer that after 2/3 hours the server uses much more
time to process your request? 
Then you know where you have to investigate more closer.


Maybe after 2/3 hours you will find that the servers process time is
still the same 

but that  the time the request/response is on the way to/from the server
takes much more time.

In this case it could be good to use a network analyzer such as
Wireshark to find the cause. 

Is it the send or the receive time when you look from the client side.


And then you can also calibrate and profile your server and your client
using NetBeans IDE and use all about  PROFILING what help of NetBeans
tells you to do..

This would be the most professional approach.


You will end up either with a network latency time increase for sending
or receiving or both


Or you will find either a CPU or MEMORY or IO Bottleneck at the Client
or the Server side.


Hope this helps to start with your not so easy task


And only if you have found the location/the cause you can think about a
configuration change!






Von: Theazyfa Jak [] 
Gesendet: Mittwoch, 1. Juni 2011 10:49
Betreff: client slow after sometime.




First of all, sorry for my english.


I have a strange issue in my apps and I really don't know how to fix it.


I have a app that called a Webservice (Websphere 6.2).

The client code is generated by Axis 1.4.1 (Java SE 6).


when I start the apps, I have a response time under 50 ms and all is


After sometime ( generally 2/3hours ) the response time increase to
350/400 ms and the only workaround I found is to stop/start the client


the first version of my code was basically : 


xxxStub ws = new xxxStub("EPR");



So I recreate everything each time and I have a response time between 30
to 100ms.

And after 2/3 hours I got 250/300.


So I try to use a MultiThreadedHttpConnectionManager. I Create a
singleton to call the Webservice and in my constructor I put this : 


            private static final int connectionPerHost = 10;

            private static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 50;

            private static final int timeoutIdleconnection = 20000;





                                   conf = new

                                   epr =

                                   ws = new xxxStub(epr);


connectionManager = new MultiThreadedHttpConnectionManager();




                                   HttpClient httpClient = new

P_CLIENT, httpClient);


and after each call, I made a ws._getServiceClient().cleanupTransport().

I have better response time (15-40 ms) but I always have after 2/3hours
a inscrease to 300 ms....



So, I have 3 questions : 

1- Is my implementation of MultiThreadedHttpConnectionManager correct?

2- Is my problem due to client or Server settings?

3- Any ideas of how to fix this?





View raw message