Re: socket errors in catalina.out and mod_jk.log

[Sven Köhler <sk...@upb.de>]

>>I took a short look at the ajp13 protocol draft, and the design of the
>>protocol is really simple, too simple.
> 
> There are few knwon problems with the protocol - both sides of jk2 are
> designed to support multiple protocols and extensions. 

yes, but how? how can either client or server guess, which extensions 
the other side supports?

>>I can't see any possibility to send idle-packets to prevent a connection
>>from timing out. That's a basic requirement, but it seems, that nobody
>>thought of it. It also doens't include a "quit-command" (quits the
> 
> What prevents you from sending idle packets ? Or adding a quit command ? 

such are not part of ajp13, and adding them will surely brake 
compatibility to existing implementations as long as i can't determinte 
the supported features of the other side.

> You can implement both - either with new packet types or by using 
> normal Ajp requests with some special URIs ( that will be handled by a jk 
> handler or even by a servlet ).

same reason as above

>>connection), but a "shutdown"-command (shuts down the servlet container,
>>i think it's unused at the moment).
> 
> Again - both can be easily added, if anyone has an itch.

Henri was protesting. I'm just repeating the Henri's doubts.

>>so tomcat's connections will keep timing out, and i see no sollution for
>>this with the current protocl design.
> 
> The protocol is a simple request/response - with apache initiating the
> communication, and some twists to avoid some roundtrips. You can send any
> type of packet - and do any kind of action.

yes, but what will the other side do if it receives an unsupported 
package? it might drop a note to the log, and that would result in a 
log-flood again :-(

>>I cannot find a describtion of some kind of simple handshake in the
>>draft i've found. so mod_jk is totally unaware of the server it's
>>talking too.
> 
> Is there any handshake in the HTTP protocol ? 

You forget, that HTTP is designed, to be a temporal connection. Without 
keep-alive and such (which were added to HTTP1.0), a HTTP connection 
doesn't survive longer than one request.
Sending headers and receiving them could also be interpreted, as a 
handshake.

A connection between apache and tomcat should survive a longer time, and 
delivers many requests.

> Does anything in the current jk prevent you from adding any kind of
> handshake you need ?  

umm ... yes?
Adding new messages is a bad bad thing. I agree with Henri's opinion in 
this case. It's just a shame, that the protocol isn't designed to be 
extended without loosing compatibility.

> There is one proposal ( made by Henri ) - that include capabilities
> and version checking. I personally don't see the real need - in most
> cases it is much easier to just configure this explicitely.

So you really think, that many administrator cares about the 
documentation, or if they do understand it? You will have people mailing 
to the list, or just leaving the options "as is", so mod_jk wouldn't 
take advantage of the features with default configuration.

>>I think, AJP needs a better design than AJP13.
>>all i found about AJP14 shows, that it comes with more features, but
>>doesn't give a damn on the basic-problems.
> 
> Again - ajp13 defines a marshalling protocol and the 3-4 messages that 
> are needed for request processing. It is not an exclusive list - other
> messages can be added.

So where can i find the "final" draft or something, that explains all 
that stuff?
After all you wrote, this draft should include a statement like 
"additional message-type that can be added, and should be silently 
ignored", so every conformant implementaion reacts the same way.

> In many cases simpler is better - HTTP is a very good proof of that. 
> I don't see any good reason to make the ajp13 protocol any more complex 
> than it is. 

proof?
hmm ...
- HTTP includes a version in each request and each response
- a client does not know which features the server supports
- => it blindly sends a request with a "let's see what happens" strategy
- ...

this should not apply for AJP13
- the versions or feature information could be exchange at the start of 
the connection, a connection should remain for some amount of time
- a client should know, if the server supports idle-message or 
quit-messages, the server should also know, which message the client may 
understand (for future enhancements and full compatibility)

> I am perfectly fine with adding other message types via plugins ( Jk
> handlers and mod_jk components ), but the simple and stable base 
> protocol needs to remain stable.

why should it get "unstable". how can a protocol get unstable?
the protocol isself should be simple, and an implementaion shouldn't get 
to complicated (if we have to much additions, or even conflicting 
additions, it's time for a new protocol)



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

Re: socket errors in catalina.out and mod_jk.log

[Costin Manolache <cm...@yahoo.com>]

Sven Köhler wrote:

...
> 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.
...

Yes - it's a workaround that avoids bloating the protocol, same workaround
used by HTTP to keep the protocol (relatively) simple. There are plenty
of protocols far more sophisticated than HTTP - but it seems the http 
workaround worked.

AJP's goal is to optimize the transfer of requests and responses. 
Jk goal was to support multiple protocols ( like AJP13 ).

I'm -1 on bloating the protocol for things that can be implemented 
much cleaner using the request/response mechanism that we already 
support. 

I'm +1 if someone wants to implement/use XDR/IIOP/RMI, 
and I'm +1 on adding a new request message format that simplifies
the current request. I think both are well justified. 

Costin 

 


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

Re: socket errors in catalina.out and mod_jk.log

[Henri Gomez <hg...@apache.org>]

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

Re: socket errors in catalina.out and mod_jk.log

[Costin Manolache <cm...@yahoo.com>]

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.

Costin




 


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

Re: socket errors in catalina.out and mod_jk.log

[Sven Köhler <sk...@upb.de>]

> 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.



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

Re: socket errors in catalina.out and mod_jk.log

[Costin Manolache <cm...@yahoo.com>]

Sorry, my previous mail got a bit long ( and a bit unfriendly :-)

The short version:
There are 3 ways to extend jk2:
1. With a completely different protocol module - marshalling and all low
level stuff. I'm +1 on such a thing if the new marshalling is a standard
one - and I think XDR is the right one ( i.e. simple enough, supported in
many places ). 

2. With new message types. Again - I'm +1 on a new message format for
the request, as it got a bit hairy. New messages can be added without
affecting the existing ones as long as both ends are proper configured.

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 )

I believe the high level features like discovery, introspection,
negotitation, etc are mostly orthogonal - they can be implemented using 
normal protocol requests, without requiring anything special in the 
protocol. All you need is the basic request/response ( or message ).

I'm +1 on any change that is required in jk to better support protocol
abstraction and to support new features - but with a lot of care to 
avoid bloat and keep things as simple as is reasonable.

Costin



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

Re: socket errors in catalina.out and mod_jk.log

[Costin Manolache <cm...@yahoo.com>]

Sven Köhler wrote:

>>>I took a short look at the ajp13 protocol draft, and the design of the
>>>protocol is really simple, too simple.
>> 
>> There are few knwon problems with the protocol - both sides of jk2 are
>> designed to support multiple protocols and extensions.
> 
> yes, but how? how can either client or server guess, which extensions
> the other side supports?

By default - client and server assume the base protocol, ajp13.
You extend the server and the client by adding more components ( handlers,
etc). Then you configure those handlers.

Whoever configures the system is supposed to know what versions are
installed and what features he wants to use.

There is no reason to not add a "FeatureNegotiationHandler" and do whatever
complex thing you want. 

However there is a very simpler solution - both sides support JMX ( or the 
equivalent in C ). Listing all components is quite easy ( I already checked
in the proxy - so now all jk C components are visible in the JMX console ).
JMX is a registry for all the components, and each component supports a
certain API. 

If the other side doesn't support a feature - you'll just get an error,
which is the normal thing to happen. 

Can you be a bit more concrete and describe what exactly you want to do 
and can't because of the current architecture ? It is just a plain RPC
with some modifications for the part that is performance critical - any
handler you want can be implemented as a normal sync RPC call. I just can't
see what you would want to do and can't be done using normal and simple
RPC, but you could do with some complex negotiation.


>>>I can't see any possibility to send idle-packets to prevent a connection
>>>from timing out. That's a basic requirement, but it seems, that nobody
>>>thought of it. It also doens't include a "quit-command" (quits the
>> 
>> What prevents you from sending idle packets ? Or adding a quit command ?
> 
> such are not part of ajp13, and adding them will surely brake
> compatibility to existing implementations as long as i can't determinte
> the supported features of the other side.

Yes - they are not part of ajp13. And yes - if you send those packets to 
an ajp13-only container, it'll not work. Think of Ajp13 request processing
as an interface - if you add more methods, you'll break existing
implementations. But that doesn't mean everything you want to do should 
be added to ajp13.

Don't confuse the Ajp13RequestProcessing API - the 3-4 messages that are 
used for sending request and response - with the whole jk2. It's just 
one interface. It is not concerned with discovery or anything else - just 
sending requests and receiving responses.

Besides - there is a huge number of features that could be implemented using
only the Ajp13RequestProcessing - just think about HTTP, which also has 
about 2-3 usefull messages ( 99% of the web uses GET and POST with one
header + body message in both sides ). On top of HTTP you can implement a
huge amount of features.

Do you want idle packets ? Send a AJP13 request to a URI "/_jk/idlePing". 
Want a quit ? Send a request to "/_jk/quit". Add whatever headers, user,
pass or other info you want. 

Both are reasonably easy to implement - the first will probably have less
overhead ( specialized packets ), the second will require the least amount
of work - and will be the easiest to maintain.

 
>> You can implement both - either with new packet types or by using
>> normal Ajp requests with some special URIs ( that will be handled by a jk
>> handler or even by a servlet ).
> 
> same reason as above

What do you mean ? Make a AjpRequest to
"/_jk/ListAllTheBloatedFeaturesYouSupport" and you can get any answer you
want. Why would this discovery be part of the request/response processing ?



>> The protocol is a simple request/response - with apache initiating the
>> communication, and some twists to avoid some roundtrips. You can send any
>> type of packet - and do any kind of action.
> 
> yes, but what will the other side do if it receives an unsupported
> package? it might drop a note to the log, and that would result in a
> log-flood again :-(

What will HTTP do if it receive an unuspported message ? Return an 
error and log a message. What should jk do ? 
Such mismatch happens only as a result of a config error - when you have 
a client asking for some unsupported server features.

If you implement the new message types as normal requests - you'll just 
get a 404 response code - and the normal access_log message.


>>>I cannot find a describtion of some kind of simple handshake in the
>>>draft i've found. so mod_jk is totally unaware of the server it's
>>>talking too.
>> 
>> Is there any handshake in the HTTP protocol ?
> 
> You forget, that HTTP is designed, to be a temporal connection. Without
> keep-alive and such (which were added to HTTP1.0), a HTTP connection
> doesn't survive longer than one request.
> Sending headers and receiving them could also be interpreted, as a
> handshake.

And exactly the same "send headers and receive headers" is possible in
exactly same way in AJP. ( I'll not answer to the HTTP lesson, I think
most people on this list know about keep-alive and http versions )

 
>> Does anything in the current jk prevent you from adding any kind of
>> handshake you need ?
> 
> umm ... yes?
> Adding new messages is a bad bad thing. I agree with Henri's opinion in
> this case. It's just a shame, that the protocol isn't designed to be
> extended without loosing compatibility.

The protocol _is_ designed to be extended, and you don't loose 
compatibility as long as you:
- use reqest/response
- configure correctly ( i.e. you don't enable a feature if you know the
other side doesn't support it )
- use any form of query - from just a list of mbeans/components to whatever
negotiation you want. 



>> There is one proposal ( made by Henri ) - that include capabilities
>> and version checking. I personally don't see the real need - in most
>> cases it is much easier to just configure this explicitely.
> 
> So you really think, that many administrator cares about the
> documentation, or if they do understand it? You will have people mailing
> to the list, or just leaving the options "as is", so mod_jk wouldn't
> take advantage of the features with default configuration.

That's how the world is. If you don't know about a feature - most likely 
you won't use it. If you read the docs ( or ask ) - you may find out.

Nothing stops you from implementing jk components to do whatever discovery -
I just want to keep the base version simple enough, and avoid featurism
and bloat. 


>> Again - ajp13 defines a marshalling protocol and the 3-4 messages that
>> are needed for request processing. It is not an exclusive list - other
>> messages can be added.
> 
> So where can i find the "final" draft or something, that explains all
> that stuff?
> After all you wrote, this draft should include a statement like
> "additional message-type that can be added, and should be silently
> ignored", so every conformant implementaion reacts the same way.

Probably searching the mailing lists archives is the only way to get 
good answers. Or you can write it yourself :-)

I think "silently ignoring" is a pretty bad choice.

Every use case I can think of can be covered with simple
request/response without any new message type. Henri is the only 
person who added new message types - and if I remember correctly he 
fixed both ends to deal with unknown messages. 

The only protocol change I would like to make is replacing the marshalling
with XDR ( that would require both ends to be explicitely configured ), and
adding a new message format to send requests without the ugly hack we do for
the POST body and with a simpler format. ( probably if we ever add XDR, this
can replace the request packet by default ).



>> In many cases simpler is better - HTTP is a very good proof of that.
>> I don't see any good reason to make the ajp13 protocol any more complex
>> than it is.
> 
> proof?
> hmm ...
> - HTTP includes a version in each request and each response
> - a client does not know which features the server supports
> - => it blindly sends a request with a "let's see what happens" strategy
> - ...
> this should not apply for AJP13
> - the versions or feature information could be exchange at the start of
> the connection, a connection should remain for some amount of time
> - a client should know, if the server supports idle-message or
> quit-messages, the server should also know, which message the client may
> understand (for future enhancements and full compatibility)

I have to disagree. 

The wire protocol shouldn't care about hight level stuff. All the
negotiation and discovery can be done at a higher level. 


>> I am perfectly fine with adding other message types via plugins ( Jk
>> handlers and mod_jk components ), but the simple and stable base
>> protocol needs to remain stable.
> 
> why should it get "unstable". how can a protocol get unstable?
> the protocol isself should be simple, and an implementaion shouldn't get
> to complicated (if we have to much additions, or even conflicting
> additions, it's time for a new protocol)

I think it's time for an old protocol :-) 

I am thinking to implement an XDR message format and the simplified request
- but I don't think it is a big priority. Jk supports multiple protocols
and I want to take advantage of it ( a lot of tools can talk XDR - python
has it buit-in for example ).


Costin


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