Hi,
sure, the conf follows:
=============
worker.list = worker_test,worker_status
worker.worker_status.type=status
worker.worker_test.type = lb
worker.worker_test.balance_workers = test1,test2,test3,test4
worker.worker_test.sticky_session = true
worker.worker_test.sticky_session_force = false
worker.worker_test.method = business
worker.worker_test.retries = 1
worker.default_params.type = ajp13
worker.default_params.host = localhost
worker.default_params.port = 8080
worker.default_params.lbfactor = 1
worker.default_params.socket_timeout = 40
worker_default_params.socket_keepalive = true
worker.default_params.connection_pool_size = 300
worker.default_params.connection_pool_minsize = 25
worker.default_params.connection_pool_timeout = 60
worker.default_params.reply_timeout = 500
worker.default_params.retries = 1
worker.default_params.recovery_options = 19
worker.test1.reference = worker.default_params
worker.test1.host = 127.0.0.1
worker.test1.port = 8009
worker.test2.reference = worker.default_params
worker.test2.host = 127.0.0.2
worker.test2.port = 8009
worker.test3.reference = worker.default_params
worker.test3.host = 127.0.0.3
worker.test3.port = 8009
worker.test4.reference = worker.default_params
worker.test4.host = 127.0.0.4
worker.test4.port = 8009
==================
On 03/19/2014 02:40 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Frederik,
On 3/18/14, 10:22 PM, Frederik Nosi wrote:
Each apache httpd talks with every tomcat.
mod_jk is configured with load balancing by business, sticky
sessions, only one try for ajp worker (so if it's busy i dont add
more stuff to the poor worker) and only 1 retry for all load
balanced workers, in short, here's the interesting part of my
conf:
worker.worker_lb.balance_workers = w1, w2, w3, w4 sticky session
on, sticky session force = off ecc
Could you post the whole configuration without editing?
[...]
Now, even with this settings, on peak times i have an
amplification effect, all tomcats are busy, mod_jk reaches atimeout
and retries again and again ... in a death spiral for the poor
cats.
This behaviour brings me two problems:
1) Even if apache httpd / mod_jk timeouts (read_timeout) from his
side this does not stop the tomcat thread proccessing that request.
It goes sometimes on and on but after all finishes the request.
This seems a resource waste, is there a way to let tomcat know
that mod_jk droped the connection and stop proccessingthe dropped
request? I tried to find a way to get this behaviour without
success, so any suggestions are welcome.
2) I noticed that the default behaviour of load balanced workers
and AJP workers is as follows:
a) ajp worker reaches retry_timeout, at this point retries again
to the same worker once, thus amplifying load. This onewas easy to
solve, just add a "worker.w1.retries = 1" and this does not happen
anymore
b) Load balancer worker goes to the next ajp worker.. till the
last one, than does another round of requests:
lb -> w1 -> timeout [...] lb-> w4 -> timeout
LB try 2 lb -> w1 -> timeout [...] request fails.
The second round to the workers IMHO is wasteful, but easy solved
with: "worker.worker_lb.retries = 1"
So at this point for every request all the busy tomcats get only
one request. I tryed finding a way to tell the LB worker to try
just once, only another worker for request but i didnt find an
option for doing this. Well, as i had an each to scratch i made a
patch that adds an option to a LB worker telling how much times to
retry before giving up, i'm glad to post it if somebody is
interested. Not sure it's perfect, but works for me.
Now, my questions:
1) Am i doing something wrong? 2) Is there a way to make a tomcat
thread stop proccessing when AJP timeouts?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTKZ5iAAoJEBzwKT+lPKRYeowQAJ1XufNZe0mc/DFwGHiIPYFK
4mqyVX00hjSwMQTSwxsTuFygiTMyTTgezsbg+EkoiDdMFtMKVRt3QZpXzCAWOthr
DWYSGcnnEONDcjWv4WMaPZ8cCnT4NCh/0FmAjbCAcVv+RiJBeoOEuNuIDX4DkS71
+4HmvUB9KwQGrSnAmtS17gA6Wauf4jW0QVe/yS642Kxv+1njFFp+n0Ezx8DnzJQr
VyRaKC7ITQTiAMbgHoYUOq+7Nwy1wOfRiwkfvWY8WNdJ1xOZJsicu5wnU1i4RDkp
rpUvhMvMJjvqO6waHO8HYcqoAhakOPBclTDpD24JuMlL5fJJVOMiFhD4iRp83tGr
X+FxMHZBTMlVhsz7ve+gQniy9zAvsTMJi5JMSkMO04WHRuqzY6dd4Iw7vrSm+LIQ
JfTUOS2Bv1NXv4MOwBCdwndQLftPDDmi1TVgFuoJH8BmeZPKqoLyGKbsOpIQkYFz
aZHtSViccTcNXQwQLl0pk9UVbYzGiRT4LdLFqRGEtq1yRdU7X3H9wuKkbQmRVrFe
Ou0xnx5/LF7RZ2cpeVnV5stZGTlTlnrlmkRX++78kplvoo7RRLP6J8A5Xmxk9zbN
Z8d8JWkNkoy1lbQr9tPaSR5A77qjwBChl3L6Elq7Gc3B1JV8SNJs8Pxau0uSm3dI
gSnf9kDocRm8ta6Ykgck
=PCNV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
