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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
