tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Configure Apache & Tomcat for atleast 50 concurrent users
Date Wed, 07 Apr 2010 21:10:37 GMT
Munirathinavel,

You have been posting essentially the same questions multiple times over 
a period of 2 months.  I don't have the patience to go through all of 
them, and the responses you received, and whether you have been 
listening to them or not.  But someone else here suggested that you have 
been given some responses, and that you are not listening to them.

I see quite a few strange things in your mod_jk configuration, many of 
them suggesting that you have not read the documentation properly.
Or that, considering the knowledge you seem to have about how this stuff 
works, maybe you are trying to bite more than you can chew.
Maybe your best option would be to hire some qualified Tomcat 
consultant, to bring some order into your configuration and try to 
resolve your problem.

This being said, this is my one try to help you.

First, I would suggest removing /all/ the following <Listener> tags from 
your Tomcat server.xml configuration file :

                         <Listener className =
"org.apache.jk.config.ApacheConfig"
workersConfig="C:/Apache/conf/workers.properties"
modJk="C:/Apache/modules/mod_jk.so" jkLog="logs/mod_jk.log" jkDebug="info"
noRoot="false"/>

Why remove them ? mainly because they make it confusing who is "in 
charge" of creating your workers.properties file.  With a configuration 
such as yours, it is better to create the workers.properties file yourself.
The second reason is that I am not even sure that the above Listener is 
working properly with Tomcat 6.0, or in a case with multiple <Host> tags 
in the Tomcat setup.


Second, in your workers.properties file, quite a number of lines are 
suspect to me :

 > workers.tomcat_home=C:/Tomcat
 > workers.java_home=C:/java/jdk1.6.0_16
 > ps=/

The above 3 lines are obsolete, since a long time. Remove them, they are 
useless.

 > worker.list=worker1
 > worker.list=worker2
 > worker.list=supportWorker
 > worker.list=crmWorker
 > worker.list=renta4wheelerWorker
 >

The above may be ok, but it would be more understandable to write it 
this way :

  worker.list=worker1,worker2,supportWorker,crmWorker,renta4wheelerWorker

which does the same thing.

 > worker.worker1.list=ajp13

This line does not make sense : worker1 is a worker. It does not have a 
"list" property.  Remove that line, and all the similar ones like 
worker.worker2.list etc..

 > worker.worker1.ajp13.port=8009

The above is also bizarre.
I do not see where this extra "ajp13" comes from.
That line should probably be

worker.worker1.port=8009

The same applies for all the other "worker" lines in your 
workers.properties file (for worker2, supportWorker, etc..).

Now there is this section :
 >
 > worker.loadbalancer.type=lb
 > worker.loadbalancer.sticky_session=1
 > worker.loadbalancer.balance_workers= worker1
 >

Remove that section, as it does not seem that you are doing any 
load-balancing; and in addition you only have one Tomcat, so what would 
you be balancing anyway ?

Also remove the following obsolete line :
 > worker.inprocess.type=jni

Now something more fundamental does not seem to make sense :

You define 5 different workers, but you have only 1 Tomcat (with several 
virtual hosts, but only one Tomcat anyway).
So what is the point of the 5 workers ? They all connect to the same 
Tomcat anyway.
As long as you have a single Tomcat server back-end, one single worker 
should be sufficient.  There is no need to have a different worker per 
VirtualHost, that has nothing to do with it.



Next, the practical problem which you are indicating :

..
> I'm not getting anything in tomcat log.
> In apache mod_jk.log I'm getting the following error....
> 
> [Tue Apr 06 18:12:08 2010][1624:3032] [info] jk_ajp_common.c (1788): Writing
> to client aborted or client network problems
> [Tue Apr 06 18:12:08 2010][1624:3032] [info] jk_ajp_common.c (2447):
> (worker1) sending request to tomcat failed (unrecoverable), because of
> client write error (attempt=1)

In a (much) earlier post, you indicated that your application, at the 
browser level, uses an XMLHttpRequest, presumably to send a request to 
Tomcat, via Apache/mod_jk.

In 99.99% of the cases, the error above indicates the following :
- a request was sent to Tomcat via Apache and mod_jk.
- the request was properly received by Apache, and forwarded to Tomcat 
via mod_jk
- Tomcat received the request, and passed it to a webapp for processing
- the webapp processed the request and generated a response
- Tomcat passed this response back to mod_jk, and for Tomcat everything 
was fine, and the request was processed and finished.
(That's why there is nothing special in your Tomcat logs)
- now mod_jk tries to pass this response back to the client (the 
browser), by writing to the client connection (the one between the 
browser and Apache) and, surprise, there is no connection there anymore 
! : the client has closed it, or something between Apache and the client 
has closed it.
- then mod_jk writes to the log, the message you see above.  It is a 
very clear and very precise message.

This can happen, for example, if the XMLHttpRequest has a timeout in 
waiting for the webserver to respond (say, 120 seconds), and the 
webserver takes longer to respond than this timeout (say 180 seconds). 
Then the client will time out, close the connection, and return an error 
to the user.  And when mod_jk will try to write the response to the 
client (after 180 seconds), it will find a closed socket.

Tomcat per se can handle hundreds of request/responses every second.
So if Tomcat is too slow to respond, it is probably your webapp that is 
too slow.  Maybe when you have 20 clients simultaneously, something in 
your web application is locking some resource, and 19 clients have to wait ?

What I mean here is that the above problem probably has nothing to do 
with the configuration issues which I mentioned earlier.  It is most 
problably either your application that is too slow to respond, or else 
it is a network problem between Apache and the clients.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message