tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: socket errors in catalina.out and mod_jk.log
Date Wed, 05 Mar 2003 11:22:24 GMT
Costin Manolache wrote:
> Sven Köhler wrote:
>>>3. On top of regular request/response. Almost everything related with
>>>auth, pings, discovery, reconfiguration can be implemented by just using
>>>regular Ajp13 requests - with a special URL. That is by far my favorite
>>>mechanism. It also has the advantage that it can reuse other parts of
>>>tomcat - mapper, coyote actions, etc. I strongly believe that most
>>>features should be implemented at this layer ( regardless of the request
>>>message or the wire protocol changes )
>>special URLs are by far the best mechanism?
>>the next simpson-episode should start with bart writing "special urls
>>are by far the worst mechanism ever" to the board.
>>it's working around a missing feature - nothing more, nothing less.
>>it's the worse method i could imagine.
>>your are talking about seomthing like
>>   /_ajp/config
>>or somethin, right?
>>what if this URL occurs within the users directory structure?
>>using illegal URLs like
>>   _ajp/config
>>could confuse other ajp-implementation that are not aware of such sh*t.
> Old ajp implementations will just return the regular 404 or 500 - what else
> would you want to happen ? To ignore the unknown messages and let the other
> side believe all is ok ? 
> It can also use a AJP method ( instead of GET ). Again - a regular error
> message will be returned. 
> And again, the confusion happens only if you use new features with old
> implementations. I think new features should be explicitedly turned on - or
> at least you should be able to turn them off if you know you are talking
> with an old version.
> IMO this mechanism is far better than bloating the protocol - all experience
> we had in the last 3 years shows only few people are willing to mess with
> the C code and the lower layers. Higher level constructs are easier to
> maintain and debug than wire protocols.

I'm confortable with C code ;)

BTW, I think we should close this noisy thread and tell :

- ajp13 protocol didn't support 'gracefull' exit feature since
   we don't want to break old implementation.

A solution could be to set a worker option to make it enable,
and send the wanted 'gracefull exit code' when will detect
that the connection will be dropped.

It could be done, but I don't have time right now, so it will
be in a future JK 1.2.3 release.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message