tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: JK connector issues ?
Date Tue, 02 Dec 2008 18:48:35 GMT
André Warnier schrieb:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> André,
>>
>> André Warnier wrote:
>>> mod_jk 1.2.x (sorry, don't know the exact version)
>>
>> This is actually quite important when mod_jk is acting funny. Try this:
>>
>> $ strings /path/to/mod_jk.so | grep mod_jk/
>> mod_jk/1.2.26
>>
>> Mine appears to be 1.2.26.
>>
>>> 26.11.2008 13:20:01 org.apache.jk.core.MsgContext action
>>> WARNUNG: Error sending end packet
>>> java.net.SocketException: Broken pipe
>>>     at java.net.SocketOutputStream.socketWrite0(Native Method)
>>>     at
>>> java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
>>>     at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>>
>> This occurs when the client hangs up the phone before the response is
>> complete. There's nothing to worry about, here.
>>
> Hi.
> I don't have easy access to that customer system, so it'll take me a
> while before I get the mod_jk version.  Unfortunately, it does not
> appear in the Apache start line.

It does since version 1.2.23 (info message during startup). From the log
line numbers I guess you are using 1.2.21 released in March 2007. That
was a time of a lot of small releases, so I would suggest your customer
should plan an upgrade to 1.2.26 or 1.2.27 in the next few months (which
seems to be quite stable, because we get a lot of downloads but no real
new bugs until now).

> Attached is a sample of the mod_jk logfile (level INFO).
> The messages which appear there are most of the time synchronous with
> the kind of message above in the Tomcat catalina.out.
> 
> Let me describe what I find strange in all this :
> We have quite a few customers with the same basic setup and
> applications, and this is the only one to my knowledge where this happens.
> The requests that are re-directed to Tomcat are a very specific subset :
> they are accesses to a text retrieval engine (say Lucene-like).
> So the users who are issuing such requests are rather unlikely to madly
> click on the stop button in the browser, or walk away before they have
> seen the results to their heavy searches.
> Yet the logfile is chock-full of such messages.

Add %D to your LogFormat in the Apache access log (microsecond response
time) and check, whether at the time of those messages you caqn find
long running requests or not. Beware that the timestamp in the httpd 2.x
access log is the beginning of the request, whereas the timestamp of the
JK message would usually be close to the end of the handling. The access
log lines are sorted according to the end of the response, although the
timestamp in the line is the beginning of the response...

You can (and should) also add the PID (process id) and thread id to the
access log, because JK logs those too (after the time stamp) and with
the time stamp, the pid and tid and the duration, you will most likely
be able to find the exact requests, for which the messages happen. hen
you can check, whether they are taking to long, or something else looks
stange (client IP and network, User Agent, URL, ...).

> There are also quite a few messages that (to me) seem to indicate that
> something might be misconfigured.

Possible, but how to tell without the configuration ...

> Do some of these messages not seem to
> say that mod_jk is trying to pass a request to Tomcat, but there is no
> Tomcat available for him to talk to ?

In the old versions, if there were no usable connections to Tomcat, you
would first get a message, that it is unable to send the request
(attempt=1), and then it would use the second attempt to start a fresh
connection and send the request. In 1.2.27 (and I think 1.2.26), the
reconnect is done transparently during the first attempt.

This can happen a lot, if Tomcat has a configured connectionTimeout on
the connector, but mod_jk has no timeout for idle connections. Again we
would need the configuration, this time also the server.xml.

If you want to keep effort low, let your customer

- first do a JK update
- check, that workers.properties contains good timeout and cping/cpong
configurations

There were only two incompatible changes during the last many releases:

- local_worker and local_worker_only worker attributes have been
dropped. If they are in the configuration, Apache httpd will not start
and the JK log will contain the info about the unknown property

- JkMount needs to be in VirtualHost, if you are using VirtualHosts. Or
you can use JkMountCopy.

So updating is simple and easy.

Regards,

Rainer


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


Mime
View raw message