Re: Using logback for Tomcat internal logging
On 1/28/11 7:39 AM, Brett Delle Grazie wrote: On 27 January 2011 15:17, Roy McMorranmcmor...@mdibl.org wrote: Can anyone point me to a document detailing how to replace Tomcat's internal logging (via JULI) with logback? Not for access logs, or the logging output of webapps, but the Tomcat internal logging that ordinarily goes to tomcat.log, etc. Try here: https://github.com/grgrzybek/tomcat-slf4j-logback Brilliant, that's working very well, thank you. -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using logback for Tomcat internal logging
Can anyone point me to a document detailing how to replace Tomcat's internal logging (via JULI) with logback? Not for access logs, or the logging output of webapps, but the Tomcat internal logging that ordinarily goes to tomcat.log, etc. Something analogous to this doc I suppose: http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_Log4j but for logback? Many thanks. -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using logback for Tomcat internal logging
On 1/27/11 10:25 AM, Mark Thomas wrote: On 27/01/2011 15:17, Roy McMorran wrote: Can anyone point me to a document detailing how to replace Tomcat's internal logging (via JULI) with logback? Not for access logs, or the logging output of webapps, but the Tomcat internal logging that ordinarily goes to tomcat.log, etc. Something analogous to this doc I suppose: http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_Log4j but for logback? You'd need to implement JULI for logback. I'm not aware of any such implementation. But logback can implement log4j, which Tomcat can use (if my admittedly naive understanding is correct)? Thanks. -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Errors not logging to catalina.out after redeploy
On 9/23/10 8:15 PM, Roy McMorran wrote: We are observing an odd behavior after upgrading to 6.0.29. Ordinarily if an exception occurs this will be logged to catalina.out. When Tomcat is first started (we use jsvc) this is the case as expected. However if the webapp is redeployed (without a restart of Tomcat) errors are no longer logged to catalina.out. Restarting will return it to the normal behavior (until the next redeploy). Prior to upgrading we were using 6.0.20 and did not have this issue. Running under Solaris 10 with JDK 1.6.0_21. I'd be happy to provide any other information that might be useful. Any suggestions? Thanks! Well, we never did find out why this behavior changed, but we've implemented a workaround by configuring Tomcat to use log4j as described at http://tomcat.apache.org/tomcat-6.0-doc/logging.html#log4j and setting swallowOutput in the Context element. Now everything is logging to tomcat.log (instead of catalina.out) and it behaves the same way before and after any redeploy. Cheers, -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Errors not logging to catalina.out after redeploy
Hi Chuck, thanks for your reply. On 9/24/10 12:14 AM, Caldarale, Charles R wrote: From: Roy McMorran [mailto:mcmor...@mdibl.org] Subject: Errors not logging to catalina.out after redeploy Ordinarily if an exception occurs this will be logged to catalina.out. When Tomcat is first started (we use jsvc) this is the case as expected. However if the webapp is redeployed (without a restart of Tomcat) errors are no longer logged to catalina.out. Restarting will return it to the normal behavior (until the next redeploy). What kind of errors are you referring to? For instance the stack trace from a null pointer exception (this is a development box). See below for a better description of the behavior. Do they show up in any of the Tomcat logs? No. Do you have swallowOutput set for the webapp? No. Didn't when at 6.0.20 either. Does the webapp have its own logging mechanism? Yes, log4j, but these are messages that wouldn't ordinarily be logged by this mechanism, eg a NPE. If so, is there some form of console handler configured for it? No, no console handler. Here is a more succinct description of the symptoms as described by the developer: (1) Servlet contains the following code: System.out.println((1) to stdout); System.err.println((2) to stderr before NPE); String foo = null; System.out.println(foo.toUpperCase()); // Cause NPE System.err.println((3) to stderr after NPE); (2) Deploy app to tomcat (3) Re-start tomcat-jsvc (4) Access servlet (unlimited times): catalina.out shows System.out message, first System.err message, and then the NPE stacktrace. (5) Re-deploy app to servlet without restarting tomcat (6) Access servlet: catalina.out shows shows System.out message, first System.err message, but NOT the NPE stacktrace (even though it is occurring). (7) Re-start tomcat-jsvc (8) Same behavior as #4. The behavior at #6 is new since our upgrade from 6.0.20 to 6.0.29. Thanks, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Errors not logging to catalina.out after redeploy
We are observing an odd behavior after upgrading to 6.0.29. Ordinarily if an exception occurs this will be logged to catalina.out. When Tomcat is first started (we use jsvc) this is the case as expected. However if the webapp is redeployed (without a restart of Tomcat) errors are no longer logged to catalina.out. Restarting will return it to the normal behavior (until the next redeploy). Prior to upgrading we were using 6.0.20 and did not have this issue. Running under Solaris 10 with JDK 1.6.0_21. I'd be happy to provide any other information that might be useful. Any suggestions? Thanks! -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
Hi Jorge, thanks for the reply. Actually no, these are the access logs from the Tomcat cluster members; you can view the corresponding AccessLogValve entries in the server.xml files referenced below. I included those logs for illustration, but I have confirmed that those are the actual session IDs at the browser. After the failover the new Tomcat cluster member sends a new Set-Cookie header with the new session ID. You're right that the first portion of the session ID does seem to be replicated properly, but I thought it was the function of JvmRouteBinderValve to update the entire session ID in a failover, including the jvmRoute portion. Best wishes, Roy Jorge Medina wrote: Are your logs Apache logs? Mod_jk logs? If it is Apache, the question would probably better answer in the Apache mailing list. Anyway, What does your LogFormat string looks like? I bet what you see in the logs is the concatenation of the session ID and the worker name. I doubt two servers would generate the same hex digits for the session. Therefore, your server must be working as expected, you are just interpreting the logs incorrectly. -Original Message- From: Roy McMorran [mailto:mcmor...@mdibl.org] Sent: Thursday, April 02, 2009 10:59 AM To: Tomcat Users List Subject: Session Replication in Cluster Hello all, I've built a very simple 2-member Tomcat cluster for testing, but I am unable to get the session replication quite right. The problem is when I fail one member of the cluster. The behavior I was expecting is that the other cluster member would take over the session ids for the failed member. However it is appending it's own jvmRoute value to the session id, and thus setting a new cookie. Details: I have 2 cluster members, itchy and scratchy, running on the same physical server, and CATALINA_BASE is /var/tomcat/itchy and /var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at /usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also on the same server). I am using sticky sessions. Here are the access logs for the 2 members from a short failover experiment (note I'm including the session ID in the 2nd field). The session starts on scratchy. From scratchy_access_log.2009-04-02.txt: 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - [02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - [02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507 At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic goes to the other cluster member as expected. From itchy_access_log.2009-04-02.txt: 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - [02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200 18263 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - [02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736 Note however that the new member's jvmRoute value is now appended to the session id. I thought is was supposed to stay exactly the same after failover. Additional details can be found as follows: server.xml for itchy - see: http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt server.xml for scratchy - see: http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt context.xml (identical) - see: https://gillnet.mdibl.org/~mcmorran/context.xml.txt workers.properties: https://gillnet.mdibl.org/~mcmorran/workers.properties I've also included the catalina.out file for both, from startup and through the test at: https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out I'd appreciate any advice on where I went wrong. Thanks and best wishes, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
Mark Thomas wrote: Nope. The job of that valve is to change the route - exactly what you are seeing. Thanks Mark, Is it the expected behavior then, that the 2nd part of the session ID changes after a failover, and a new cookie is set? Thanks, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
Mark Thomas wrote: Roy McMorran wrote: Thanks Mark, Is it the expected behavior then, that the 2nd part of the session ID changes after a failover, and a new cookie is set? Yes Mark Interesting. I am certain I saw the other behavior (both parts of the session ID were preserved) earlier in my testing, but I haven't been able to reproduce it since...now I know why. Thanks for your help Mark and Jorge. Cheers, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
Mark Thomas wrote: Roy McMorran wrote: Is it the expected behavior then, that the 2nd part of the session ID changes after a failover, and a new cookie is set? Yes OK, please bear with me here, I may be just showing my ignorance with respect to Tomcat and web applications in general, but... If the session ID changes from ABC123.node1 to ABC123.node2, then you will start a new session at the browser. If you are going to establish a new session anyway, why bother replicating the first part of the session ID at all? Thanks, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
Caldarale, Charles R wrote: From: Roy McMorran [mailto:mcmor...@mdibl.org] Subject: Re: Session Replication in Cluster If the session ID changes from ABC123.node1 to ABC123.node2, then you will start a new session at the browser. No, you get a new *cookie* at the browser; the session is something only the server has cognizance of. Assuming your session replication across nodes is working properly, the user sitting at the browser won't know that anything has changed. Thanks Chuck, that was helpful. I think I was being misled by the behavior of the application I'm trying to cluster. It looked like a whole new session had been established after the failover, but upon closer investigation I can see now that is not the case. Best wishes, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
János Löbb wrote: If You look the values created by the session earlier with ...node1, than You will see the same values after fail over with ...node2. A new session would not know about them. To verify it You can use the supplied SessionExmaple webapp. It is like passing a baby among family members and making a snapshot. As long as the baby the same everything is alright :) Thank you János, that is a great analogy! Appreciate your reply. Cheers, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Replication in Cluster
János Löbb wrote: If You look the values created by the session earlier with ...node1, than You will see the same values after fail over with ...node2. A new session would not know about them. To verify it You can use the supplied SessionExmaple webapp. OK, trying that. So, using an example webapp (see: https://gillnet.mdibl.org/~mcmorran/session.jsp.txt (which just uses session.getID() ) ...should it return *just* the session ID part, or the concatenation of the session ID and the jvmRoute? Here's what I see: Before failover: This is the session id FEBA6A8127A69079C79B7A641158CE20.itchy This is an existing session After failover: This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy This is an existing session Thanks, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Session Replication in Cluster
Hello all, I've built a very simple 2-member Tomcat cluster for testing, but I am unable to get the session replication quite right. The problem is when I fail one member of the cluster. The behavior I was expecting is that the other cluster member would take over the session ids for the failed member. However it is appending it's own jvmRoute value to the session id, and thus setting a new cookie. Details: I have 2 cluster members, itchy and scratchy, running on the same physical server, and CATALINA_BASE is /var/tomcat/itchy and /var/tomcat/scratchy respectively. Tomcat 6.0.18 binaries, etc. are at /usr/local/tomcat. Using mod_jk 1.2.27 on Apache 2.2.11 (Apache is also on the same server). I am using sticky sessions. Here are the access logs for the 2 members from a short failover experiment (note I'm including the session ID in the 2nd field). The session starts on scratchy. From scratchy_access_log.2009-04-02.txt: 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - [02/Apr/2009:10:19:55 -0400] GET / HTTP/1.1 200 14612 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.scratchy - [02/Apr/2009:10:20:14 -0400] GET /about/ HTTP/1.1 200 19507 At 10:21:39 AM I do a kill -9 on the scratchy instance. Now the traffic goes to the other cluster member as expected. From itchy_access_log.2009-04-02.txt: 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - [02/Apr/2009:10:22:11 -0400] GET /about/publications/ HTTP/1.1 200 18263 192.168.200.177 E5BF3FFA9AEE1E3AB0DD4A96BA5E4011.itchy - [02/Apr/2009:10:22:32 -0400] GET /about/changes/ HTTP/1.1 200 12736 Note however that the new member's jvmRoute value is now appended to the session id. I thought is was supposed to stay exactly the same after failover. Additional details can be found as follows: server.xml for itchy - see: http://gillnet.mdibl.org/~mcmorran/itchy-server.xml.txt server.xml for scratchy - see: http://gillnet.mdibl.org/~mcmorran/scratchy-server.xml.txt context.xml (identical) - see: https://gillnet.mdibl.org/~mcmorran/context.xml.txt workers.properties: https://gillnet.mdibl.org/~mcmorran/workers.properties I've also included the catalina.out file for both, from startup and through the test at: https://gillnet.mdibl.org/~mcmorran/itchy-catalina.out https://gillnet.mdibl.org/~mcmorran/scratchy-catalina.out I'd appreciate any advice on where I went wrong. Thanks and best wishes, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmor...@mdibl.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk - ajp hangs indefinitely on some requests
Hello all, I'm seeing frequent cases where requests sent via mod_jk to Tomcat will hang indefinitely. The request will never return to Apache and the client will eventually time out. There are no error messages. In my test case I run wget against various URLs until the hang occurs (usually within 2-3 minutes). Here are the last few entries from my mod_jk.log file (JkLogLevel = trace): [Thu Dec 04 13:28:08.509 2008] [27224:1] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 00c0FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Thu Dec 04 13:28:08.510 2008] [27224:1] [trace] ajp_connection_tcp_send_message::jk_ajp_common.c (928): exit [Thu Dec 04 13:28:08.510 2008] [27224:1] [debug] ajp_send_request::jk_ajp_common.c (1325): (ajp13) request body to send 0 - request body to resend 0 [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_send_request::jk_ajp_common.c (1422): exit [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_get_reply::jk_ajp_common.c (1613): enter [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (953): enter Beyond this point there is no activity. There are never any error messages generated, not in mod_jk.log, catalina.out, nor in the Apache logs. There is a thread dump of Tomcat (after the hang begins) at: http://www.mdibl.org/~mcmorran/tomcat_thread_dump.txt This is a pretty simple setup, both Apache Tomcat are running on the same host, so there is no firewall issue. No load balancing, just one worker defined. workers.properties file: worker.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.socket_timeout=120 (have tried with and without the socket_timeout parameter - makes no difference) My server.xml file is at: http://www.mdibl.org/~mcmorran/server.xml.txt (I've tried various settings (or none) for connectionTimeout inside the AJP connector - makes no difference) mod_jk related parts of my httpd.conf file are at: http://www.mdibl.org/~mcmorran/httpd.conf.txt Version info: Server: Solaris 10 Apache: 2.2.6 mod_jk: 1.2.25 Tomcat: 6.0.14 libtcnative: 1.10 Java: 1.5.0_14 I'm running Tomcat under jsvc. The JVM gets 2G of memory (there are 8G total on the system) - I don't think there's any memory issue. I'm in test mode so I'm the only user; there's virtually no CPU load on the box. I've reached a dead end here -I'm hoping someone on the list may have some ideas. Thanks for any help you may be able to provide. Cheers, Roy -- Roy McMorran Systems Administrator MDI Biological Laboratory [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - ajp hangs indefinitely on some requests
Mark Thomas wrote: Roy McMorran wrote: Hello all, I'm seeing frequent cases where requests sent via mod_jk to Tomcat will hang indefinitely. The request will never return to Apache and the client will eventually time out. There are no error messages. In my test case I run wget against various URLs until the hang occurs (usually within 2-3 minutes). Here are the last few entries from my mod_jk.log file (JkLogLevel = trace): [Thu Dec 04 13:28:08.509 2008] [27224:1] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (911): 00c0FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Thu Dec 04 13:28:08.510 2008] [27224:1] [trace] ajp_connection_tcp_send_message::jk_ajp_common.c (928): exit [Thu Dec 04 13:28:08.510 2008] [27224:1] [debug] ajp_send_request::jk_ajp_common.c (1325): (ajp13) request body to send 0 - request body to resend 0 [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_send_request::jk_ajp_common.c (1422): exit [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_get_reply::jk_ajp_common.c (1613): enter [Thu Dec 04 13:28:08.511 2008] [27224:1] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (953): enter Beyond this point there is no activity. There are never any error messages generated, not in mod_jk.log, catalina.out, nor in the Apache logs. There is a thread dump of Tomcat (after the hang begins) at: http://www.mdibl.org/~mcmorran/tomcat_thread_dump.txt This is a pretty simple setup, both Apache Tomcat are running on the same host, so there is no firewall issue. No load balancing, just one worker defined. workers.properties file: worker.list=ajp13 worker.ajp13.type=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8009 worker.ajp13.socket_timeout=120 (have tried with and without the socket_timeout parameter - makes no difference) My server.xml file is at: http://www.mdibl.org/~mcmorran/server.xml.txt (I've tried various settings (or none) for connectionTimeout inside the AJP connector - makes no difference) mod_jk related parts of my httpd.conf file are at: http://www.mdibl.org/~mcmorran/httpd.conf.txt Version info: Server: Solaris 10 Apache: 2.2.6 mod_jk: 1.2.25 Tomcat: 6.0.14 libtcnative: 1.10 Java: 1.5.0_14 I'm running Tomcat under jsvc. The JVM gets 2G of memory (there are 8G total on the system) - I don't think there's any memory issue. I'm in test mode so I'm the only user; there's virtually no CPU load on the box. I've reached a dead end here -I'm hoping someone on the list may have some ideas. Thanks for any help you may be able to provide. Have you tried: JkOptions +DisableReuse ? Mark Hi Mark, thanks for the reply. I hadn't tried DisableReuse - the documentation at http://tomcat.apache.org/connectors-doc/reference/apache.html led me to believe that 1) it would likely be very detrimental to performance and 2) it probably doesn't apply my situation (no firewall, no network involved at all). Nevertheless, I gave it a go just now. Unfortunately it made no difference. Thanks, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - ajp hangs indefinitely on some requests
Mark Thomas wrote: Roy McMorran wrote: libtcnative: 1.10 Sorry, should have seen this sooner. Try disabling it or using a newer version. I'll give it a try but I'm not hopeful. You see I have two systems exhibiting this hang behavior. The other one (dev) has the latest libtcnative (1.1.15). And I have a third (the production box) also using 1.1.10 that is fine (it doesn't hang). I admit, it's strange. Thanks -r -- Roy McMorran Systems Administrator MDI Biological Laboratory [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - ajp hangs indefinitely on some requests
Roy McMorran wrote: Mark Thomas wrote: Roy McMorran wrote: libtcnative: 1.10 Sorry, should have seen this sooner. Try disabling it or using a newer version. I'll give it a try but I'm not hopeful. You see I have two systems exhibiting this hang behavior. The other one (dev) has the latest libtcnative (1.1.15). And I have a third (the production box) also using 1.1.10 that is fine (it doesn't hang). I admit, it's strange. Despite my misgivings, 1.1.5 seems to have helped. It's run my test script for about 30 minutes now without problems (previously would have hung by minute 3). However! My dev system (which was already running 1.1.15) still exhibits the problem. It also has newer versions of Tomcat (6.0.18), Apache (2.2.10) and mod_jk (1.2.27). Looks like I'm not done yet. Thanks, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk - ajp hangs indefinitely on some requests
Roy McMorran wrote: Despite my misgivings, 1.1.5 seems to have helped. It's run my test script for about 30 minutes now without problems (previously would have hung by minute 3). However! My dev system (which was already running 1.1.15) still exhibits the problem. It also has newer versions of Tomcat (6.0.18), Apache (2.2.10) and mod_jk (1.2.27). Correction. The combination of updating libtcnative to 1.1.15 _AND_ setting JkOptions +DisableReuse prevents both systems from hanging. I'm concerned about the performance implications of using this directive based on what I read at http://tomcat.apache.org/connectors-doc/reference/apache.html and I'm unclear as to why it's necessary. Can anyone educate me on this? Do I still have a problem with my configuration? Thanks again, -r -- Roy McMorran Systems Administrator MDI Biological Laboratory [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
