-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rajesh,

On 12/28/14 1:54 AM, Rajesh Cherukuri wrote:
> Thanks for the response here are the details , i can also see that
> the backend tomcat which has high cpu has processed less number of
> request when compared with  other tomcat's i checked this from
> tomcat access logs  , in the monotoring tool i can see that the
> tomcat which has issues have taken more hits/sec when compared  to
> others

Maybe your web application doesn't work well under load...

> as of now i am suspecting the busyness method has sent more request
> to the tomcat that served less number of request's (the tomcat 
> which has high cpu)  , which is unable to  serve the  requests due
> to hung threads to DB

If you have threads hanging waiting on db responses, then maybe you
should look there... mod_jk isn't the problem.

(Unless you suspect that there is a problem with the "busyness"
algorithm. If you think there is a problem with the busyness
algorithm, then you'll need to provide a LOT of data. As of yet, you
have provided exactly zero data. The mod_jk status worker can provide
a great deal of information about the state of your workers.)

> *Tomcat version * 6.0

6.0.what?

> *Apache Version * 2.2

2.2.what?

What about mod_jk? Version number?

> *Thread dump anylisis*
> 
>> From thread dump i can see that most of the threads are waiting
>> on DB ,and
> other are mod_jk threads  Application uses c3po mchange to connect
> to DB

I have no idea why people use c3p0. It's considered pre-alpha at this
point. If your threads are stuck waiting for db connections (and not
waiting for the db to complete some actual work), then you might
consider swapping-out your connection pool for one that a bit more
reliable.

> worker.propertires
> 
> 
> *here is my work.property file* worker.xxx.type=lb
> worker.xxx.method=Busyness Definite common values for all xxxlb
> workers
> 
> *worker.xxxlb.common.type=ajp13 worker.xxxlb.common.lbfactor=1 
> worker.xxxlb.common.ping_mode=A 
> worker.xxxlb.common.socket_connect_timeout=10000 
> worker.xxxlb.common.connection_pool_size=6*
> 
> *worker.xxxlb.common.connection_pool_timeout=600 
> worker.xxxlb.common.socket_keepalive=True*


Nothing seems amiss here. You need to give more information.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUoBoGAAoJEBzwKT+lPKRYWqQQAIt76zjfPhfCRfjkdf4txWwm
l801mc6RLVGCJT37vAH6FeCC9hMUTcAGNRnPjo3X7E5aZd+CDxQ129TGd/qbFSCv
PKp39Fg2x4Idv2YTuKWxBXTxngqoHpYotz6KaKMt1cbSVuaWhJk1t6nrwD597JI4
r1ZsjuqCvtexsw6/uPoKCCXioKnmLr9IGOPIWxmZrGtrt7mxPtdnkWHHvNVe+0Ct
RbB5TDWYCLWllpjE7sXNokYagGk5Ozfh8MFYGrDNkANCWnD9aL4XC2Z2sgglPBND
UEl7YY0UYPvgP72ISJ6vo3TpjaGE9R7aDSE1tEhPQH1+2hf+rRReJlC00Ynom2Jg
5IgC0uk87Vt26iUIdx+KJIuR6fGOKtKPexTolFq0iZEyzGhZ/wuxPczSuVgtNLS2
Qla4byTfE4Cx0YYylLdJTGYhPFAtCDCVZSp5BlQQxqruGN77+gsn0zZoXVT7pPH3
c0uL3poikjM3UQDNnbSzlxv+37qPS+ziAeAFNKcvNpx9z8dHrPP+Xk6NGGTEaQ+x
YLY6xuBF+3AqObGrg56zEcHOWsPrWD2oW8mb43S6y0DiZTq2tf2i5wWoofPk2Q3E
YacbaRqzlkNNBV8RBVq+qCVhPFoPFOthSwDbMcxw2NZRiv4l9rD9qNRvzsZpEb39
rgl+JKOYuwXRsNF7TCtf
=eE8h
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to