Re: In jk_endpoint_t::service, get_reply failed in send loop 1

[Bill Barker <wb...@wilshire.com>]

I'm the first to admit to grasping straws here.  I've never had problems
with TC on Solaris up to and including 8.  The error you are getting in the
logs is "connection refused".  The lame guesses I can make are:

-- Mis-configuration between the host-port pare in server.xml and the
workers.properties files

-- A firewall between the two that is blocking the connections.

-- You're using the 3.0 mod_jk.so with 3.3.1.

>From your description, these are almost certainly wrong (since the result
should be no connections ever).  You can try "netstat -a" to see that Tomcat
is actually listening on 8009.  But without more info, I'm out of guesses.
:(

>There is nothing in the tomcat logs, which is why I didn't post them.
>It took me awhile to run through all of the logs and find that only this
>one logfile showed any errors.
>I'm especially baffled that the other servlet jar works so well, without
>errors, and simply by adding a few servlets to the jar for the same
>context we have managed to lose apache/tomcat communication.  It seems
>like this shouldn't be possible.

>I appreciate your effort to help.

>-Paul



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

Re: TC3.3 blocking (was: In jk_endpoint_t::service, get_reply failed in send loop 1)

[Bill Barker <wb...@wilshire.com>]

----- Original Message -----
From: "PSA" <li...@posom.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Tuesday, April 02, 2002 9:34 AM
Subject: TC3.3 blocking (was: In jk_endpoint_t::service, get_reply failed in
send loop 1)


> Bill - Thanks for your efforts.
> We finally tracked the problem to a servlet which was trying to make a
> JDBC connection to a server that it couldn't reach.  This was easy to
> fix, but what I don't understand is
> 1) Why did all of the other requests to the server have to wait for this
> one?  Is something synchronized here?  With no traffic to the server the
> misbehaving servlet would eventually return when it caught the SQL
> exception for the timed out connection.  All pending requests would go
> through at that time as well.

Tomcat isn't synchronizing in the service method (except for STM servlets of
course, when it is on the servlet), and only synchronizing on the servlet in
the init method.  In the case of a jsp:useBean, it will synchronize on the
"scope" during the init calls however.  Of course, the servlet is free to
synchronize on anything that it can get it's hands on.

> 2) Why did the other contexts also get held up for this one servlet?  We
> have been considering allowing some users to use JSPs in their own
> (restricted) contexts.  But this will never be possible when one servlet
> can take everything down.

No clue.  It shouldn't happen (and doesn't for me).

> 3) Why all of the failed connection entries in the jk.log?  It appears
> that all of tomcat was blocking for this one servlet (and not even a
> singleton) while mod_jk tried in vain to contact it.

It looks like you exceeded the "maxThreads" paramater on the
Ajp13Interceptor during the time your servlet was stuck.
> 4) Is there any way to fix this?  We are using an only slightly modified
> version of the tomcat 3.3(.1) default configuration (though Apache is
> heavily configured and mod_rewrite directives abound).  I'd really
> prefer to not have to make configuration changes to the httpd.conf
> includes, but would a different connector have the same problem?  JK2?
>
You probably want to increase the maxThreads on Ajp13Interceptor (it should
be > MaxChild in Apache).  Then people coming in might get stuck until the
servlet times out.  AFAIK all of the connectors would have the same problem.
> Thanks.
>
> Paul Anguiano
> Unix SysAdmin/Webmaster
> Seattle Public Schools
>
>


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

TC3.3 blocking (was: In jk_endpoint_t::service, get_reply failed in send loop 1)

[PSA <li...@posom.com>]

Bill - Thanks for your efforts.
We finally tracked the problem to a servlet which was trying to make a 
JDBC connection to a server that it couldn't reach.  This was easy to 
fix, but what I don't understand is
1) Why did all of the other requests to the server have to wait for this 
one?  Is something synchronized here?  With no traffic to the server the 
misbehaving servlet would eventually return when it caught the SQL 
exception for the timed out connection.  All pending requests would go 
through at that time as well.
2) Why did the other contexts also get held up for this one servlet?  We 
have been considering allowing some users to use JSPs in their own 
(restricted) contexts.  But this will never be possible when one servlet 
can take everything down.
3) Why all of the failed connection entries in the jk.log?  It appears 
that all of tomcat was blocking for this one servlet (and not even a 
singleton) while mod_jk tried in vain to contact it.
4) Is there any way to fix this?  We are using an only slightly modified 
version of the tomcat 3.3(.1) default configuration (though Apache is 
heavily configured and mod_rewrite directives abound).  I'd really 
prefer to not have to make configuration changes to the httpd.conf 
includes, but would a different connector have the same problem?  JK2?

Thanks.

Paul Anguiano
Unix SysAdmin/Webmaster
Seattle Public Schools


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>