John,

I think I was a little vague about the TIME_WAIT state.  Seeing
a number of connections in this state when you run netstat is
normal -- it does not, by itself, point to any problem,
including a problem with the closing of connections.  (Again I
refer you to the Unix socket FAQ if you're interested in the
details.)

To really know that my guess is right you would have to find
an error message in Tomcat's logs (or printed to the screen)
about not being able to start the ajp12 listener with a message
"address already in use" or a code which has the same meaning.

At any rate it sounds like you may have solved the problem :-).

About the max setting, I'm not sure what you mean.  Are you
referring to the number of ajp listeners that can be active?
If so, see the end of the User Guide (section "Use a Thread Pool
in your Connectors" right at the bottom):
http://jakarta.apache.org/tomcat/tomcat-3.2-doc/uguide/tomcat_ug.html

-- Andrew

-----Original Message-----
From: John Thompson [mailto:[EMAIL PROTECTED]]
Sent: 27 July 2001 10:44
To: [EMAIL PROTECTED]
Subject: RE: Intermittent ferrors with ajp12 with tc3.2.1 on solaris
with stronghold (apache)


Andrew,

Thanks for your response.  As before, it has fixed itself over night.

There was nothing more than the exception itself on the command line - I 
expect that this was from my servlet - so apologies for the probable 
red-herring.

I had other problems this morning which were sorted out with a 'build.sh 
clean' this morning - this may have helped last night,  I don't know for 
sure.

If it happens again, I'll try the netstat again.  I think blind panic had 
set in by then.

It is showing entries now.  Today I get:
LISTEN on one - looks like a parent type (I'll read up on this)
TIME_WAIT on another.

Servlet goes in,  then I get two lots of ESTABLISHED,  then the two 
established entries go to TIME_WAIT (I sometimes catch CLOSE_WAIT,  and 
FIN_WAIT_2 as well).

However,  the number of TIME_WAIT entries sometimes increases.  it looks 
like something is not being closed off to one of the back ends.  This 
probably built up and ended in disaster.  I'll check all connections are 
closing OK.

I assume there is a max - do you know where this is set?

Thanks,
John.

Reply via email to