RE: Failing a JK Worker thread
We have an application running as a webapp which requires legacy systems and network resources which are not fault-tolerant. Luckily these resources are stateless. So we have replicated these resources so that one is available per tomcat instance. When we attempt to use one of these resources from within the webapp and it fails, we need a way to try the next pair (tomcat legacy) in the group. This will allow us to provide a balanced fault-tolerant service with a webapp interface. Since the tomcat instance is responding and functioning, the reply_timeout was not met so apache webserver considered the request a success. Providing a application error from tomcat (maybe a 503 or 401 instead of 500) seemed like the rightest way to do it. I see a few other options: 1. Put a layer on top of apache that tests the response and makes a new request. This doesn't buy us anything and circumvents the use of jk 2. (some how/maigcally) Send an out of process message from tomcat back to apache that the resource is down. 3. Modify AJP to handle this error (this may already have a mechanism that I missed) Does any one have any other suggestions for ensuring reliability when there is a 3rd party piece of hardware/software which your webapp relies on that has no fault-tolerance of its own? I may be totally missing the point here, but isn't this something that could be handled in a servlet filter. If you have an availability problem, set a flag in the response header that the filter can check for and take appropriate action? Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failing a JK Worker thread
I didn't hear back from any one so I looked through the code. I couldn't find any sign of code that would provide this functionality, so I added the following before line 605 of jk_ajp_common.c. I recompiled and it seems to be working as intended so far. if (d-status=500) { jk_log(l, JK_LOG_ERROR, Tomcat server returned status=%d,d-status); JK_TRACE_EXIT(l); return JK_FALSE; } I may end up using a case statement and preventing apache from trying the next worker on bad request or something like that. Hope this helps some one else too. -Dan Thiffault On Mar 13, 2005, at 12:01 PM, Dan Thiffault wrote: I am running apache web server 2.0.49 connected to tomcat 5.0.28 using the jk connector version 1.2.8. From my understanding, if I set the reply_timeout property of an ajpv13 worker, once the reply_timeout elapses for a particular request to a worker, apache web server will make a new request to the next worker in the group. Is there any way from within the webapp that is being contacted to induce a failure other than not returning before the reply_timeout? For instance, can you return an HTTP error message from tomcat that would cause web server to retry the request to the next worker in the group (assuming full recovery mode)? Thanks for any suggestions -Dan Thiffault - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failing a JK Worker thread
Dan Thiffault wrote: if (d-status=500) { jk_log(l, JK_LOG_ERROR, Tomcat server returned status=%d,d-status); JK_TRACE_EXIT(l); return JK_FALSE; } I may end up using a case statement and preventing apache from trying the next worker on bad request or something like that. Hope this helps some one else too. Yes, that is the problem, and that is why it wasn't implemented. In case your application returns 500, then entire worker is marked in error state and is unusable for consecutive requests until recycled. The solution would be to mark the url in error state, add url cache, and then recycle the context path, but this would require lots of work, add more complexity, with dubious usage. I would suggest that you rewrite your application to offer high availability. It would be much smarter then doing HTTP 500 tricks. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Failing a JK Worker thread
What is the situation where you find this useful? Byron -Original Message- From: Dan Thiffault [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 1:41 PM To: Tomcat Users List Subject: Re: Failing a JK Worker thread I didn't hear back from any one so I looked through the code. I couldn't find any sign of code that would provide this functionality, so I added the following before line 605 of jk_ajp_common.c. I recompiled and it seems to be working as intended so far. if (d-status=500) { jk_log(l, JK_LOG_ERROR, Tomcat server returned status=%d,d-status); JK_TRACE_EXIT(l); return JK_FALSE; } I may end up using a case statement and preventing apache from trying the next worker on bad request or something like that. Hope this helps some one else too. -Dan Thiffault On Mar 13, 2005, at 12:01 PM, Dan Thiffault wrote: I am running apache web server 2.0.49 connected to tomcat 5.0.28 using the jk connector version 1.2.8. From my understanding, if I set the reply_timeout property of an ajpv13 worker, once the reply_timeout elapses for a particular request to a worker, apache web server will make a new request to the next worker in the group. Is there any way from within the webapp that is being contacted to induce a failure other than not returning before the reply_timeout? For instance, can you return an HTTP error message from tomcat that would cause web server to retry the request to the next worker in the group (assuming full recovery mode)? Thanks for any suggestions -Dan Thiffault - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failing a JK Worker thread
We have an application running as a webapp which requires legacy systems and network resources which are not fault-tolerant. Luckily these resources are stateless. So we have replicated these resources so that one is available per tomcat instance. When we attempt to use one of these resources from within the webapp and it fails, we need a way to try the next pair (tomcat legacy) in the group. This will allow us to provide a balanced fault-tolerant service with a webapp interface. Since the tomcat instance is responding and functioning, the reply_timeout was not met so apache webserver considered the request a success. Providing a application error from tomcat (maybe a 503 or 401 instead of 500) seemed like the rightest way to do it. I see a few other options: 1. Put a layer on top of apache that tests the response and makes a new request. This doesn't buy us anything and circumvents the use of jk 2. (some how/maigcally) Send an out of process message from tomcat back to apache that the resource is down. 3. Modify AJP to handle this error (this may already have a mechanism that I missed) Does any one have any other suggestions for ensuring reliability when there is a 3rd party piece of hardware/software which your webapp relies on that has no fault-tolerance of its own? Thanks for any suggestions, Dan On Mar 15, 2005, at 2:50 PM, Guernsey, Byron ((GE Consumer Industrial)) wrote: What is the situation where you find this useful? Byron -Original Message- From: Dan Thiffault [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 1:41 PM To: Tomcat Users List Subject: Re: Failing a JK Worker thread I didn't hear back from any one so I looked through the code. I couldn't find any sign of code that would provide this functionality, so I added the following before line 605 of jk_ajp_common.c. I recompiled and it seems to be working as intended so far. if (d-status=500) { jk_log(l, JK_LOG_ERROR, Tomcat server returned status=%d,d-status); JK_TRACE_EXIT(l); return JK_FALSE; } I may end up using a case statement and preventing apache from trying the next worker on bad request or something like that. Hope this helps some one else too. -Dan Thiffault On Mar 13, 2005, at 12:01 PM, Dan Thiffault wrote: I am running apache web server 2.0.49 connected to tomcat 5.0.28 using the jk connector version 1.2.8. From my understanding, if I set the reply_timeout property of an ajpv13 worker, once the reply_timeout elapses for a particular request to a worker, apache web server will make a new request to the next worker in the group. Is there any way from within the webapp that is being contacted to induce a failure other than not returning before the reply_timeout? For instance, can you return an HTTP error message from tomcat that would cause web server to retry the request to the next worker in the group (assuming full recovery mode)? Thanks for any suggestions -Dan Thiffault - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Failing a JK Worker thread
I am running apache web server 2.0.49 connected to tomcat 5.0.28 using the jk connector version 1.2.8. From my understanding, if I set the reply_timeout property of an ajpv13 worker, once the reply_timeout elapses for a particular request to a worker, apache web server will make a new request to the next worker in the group. Is there any way from within the webapp that is being contacted to induce a failure other than not returning before the reply_timeout? For instance, can you return an HTTP error message from tomcat that would cause web server to retry the request to the next worker in the group (assuming full recovery mode)? Thanks for any suggestions -Dan Thiffault - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]