You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dan Thiffault <dt...@checkernet.com> on 2005/03/13 18:01:35 UTC

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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Failing a JK Worker thread

Posted by Mladen Turk <ml...@jboss.com>.
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Failing a JK Worker thread

Posted by Dan Thiffault <dt...@checkernet.com>.
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org