tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Unable to sendViaPost to url...... .... Read timed out
Date Mon, 16 Jan 2012 18:51:14 GMT
Bert Verhees wrote:
> Hi, I hope you can help me analyzing this problem:
> I am using Tomcat6 6.0.32-5ubuntu1.1 together with Axis2 1.6.1
> I am not sure if it is an Axis2 problem or a Tomcat-problem.
> I have an client-application for test-purposes which runs inside the 
> Eclipse-IDE.
> The problem only occurs when running Axis2 inside Tomcat6, when running 
> in Axis2 as stand-alone server, it runs better.
> What I do is posting arrays of strings (about 50 elements, about 5Kb 
> max) 

Is that per "person", or per POST ?

to an webservice-call.
> After some validation, the webservice 

of which we here know nothing..

posts the data to a postgresql
> database.
> I have some console-output to see how long it takes.
> storing.....  Person:26, ID:27
> Creating EHR for:213d7c09-949c-4757-a91d-da5510215472
> GUIDs saved to table:213d7c09-949c-4757-a91d-da5510215472, 
> 73b60dd4-d745-4267-9c6f-fc8b067bfeb9
> stored.....  Person:26, UID:213d7c09-949c-4757-a91d-da5510215472
> PT0.647S
> As you can see, it starts with less then a second, sometime 0.3 seconds, 
> sometimes 1.1 second, depending on the number of elements in the array 
> to store.

What array, where ?

> After 1000 persons stored, it takes 4 seconds

Do you mean that you send data in one POST about 1000 persons (each with 50 text data 
elements) ?

> storing.....  Person:998, ID:989
> Creating EHR for:49c96d87-38db-491d-a824-78800615e80a
> GUIDs saved to table:49c96d87-38db-491d-a824-78800615e80a, 
> 3554514f-ccb6-40dd-92f2-d9140760870e
> stored.....  Person:998, UID:49c96d87-38db-491d-a824-78800615e80a
> PT4.147S
> When running in Axis2 standalone, it stays about 4 seconds until 8000 
> persons stored (which is the complete group to store)

is that 1 POST, or 8000 POSTs to the server ?

> This is slow, I must investigate the library directly without webservice 
> if that is a problem of my coding. So we forget that for the moment.
> The problem which bothers me is when I am using Tomcat.
> The problem start to occur after posting 1200 patients, it takes 8 
> seconds. When it reaches 1300, it already takes 17 seconds.
> When at Person 1330, it is already 29 seconds, and at 1340 it is 39 
> seconds, and than a few persons more and a time-out exception occurs.
> I receive a Read timed out from the 
> client side-code. The default time-out time for Axis2-code is 40 seconds.
> The printstacktrace is below, but it is client side stacktrace
> I try a lot of things to solve the problem. I put a Thread.sleep(1000); 
> in my client-code between to postings, I thought, maybe the webservice 
> needs some rest to do garbage-clean up. Because it looks very much like 
> a memory blowing up. But it didn't help.
> Of course, if you need any information, I will be happy to provide it, 
> please give some hints how to provide it

You could start by telling us which version of Tomcat this is, under with Java JVM 
version, and on which platform (Windows, Linux,..).
Then tell us with how much available memory this Tomcat is running.

Making some wild guesses here, because you do not really provide any precise information 
about what exactly you are trying to do :

Let's suppose that your client application puts together one POST request, consisting of 
XML data composed of 1000, 2000, 3000 elements "person", each composed of up to 50 text 
data sub-elements, and then sends that POST to the server.
And that the server application receives this big POST request, reads the XML body of it,

parses this XML in memory as a large "XML document object", before it starts splitting it

into 1000, 2000, 3000 "person" elements in order to update records in the database..

Then, if all the above roughly matches what you are doing, I would not be very surprised 
if you got into serious memory usage problems, forcing the server to swap this data and 
slowing down your process dramatically (and exponentially) as the quantity of data increases.

Have you tried a design where you send the data to the server in more manageable chunks ?
What about a loop where you would send 100 persons's data at one time, and run the loop 80

times ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message