Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Costin Manolache wrote: Henri Gomez wrote: Another point is that adding new message to protocol make it incompatible with olders java implementations or with alternate This is not entirely true. It is quite easy to configure what messages get sent by mod_jk - the admin is supposed to know what type of worker it connects to, and if the worker is an old tomcat or other config he can just disable the new messages. All that's needed is a simple piece of code on both ends of jk2. I'm worry not about JTC/JK2, but JK and old AJP13 implementations ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
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.
Re: socket errors in catalina.out and mod_jk.log
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Henri Gomez wrote: > Another point is that adding new message to protocol make > it incompatible with olders java implementations or with alternate This is not entirely true. It is quite easy to configure what messages get sent by mod_jk - the admin is supposed to know what type of worker it connects to, and if the worker is an old tomcat or other config he can just disable the new messages. All that's needed is a simple piece of code on both ends of jk2. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote: >> There is another problem with how mod_jk handles the ajp connetor >> sockets. That is the one to one mapping of apache child process to an ajp >> connector. On an apache server that serves normal http requests you can >> end up with many idle socket connections to Tomcat, and Tomcat will spawn >> many more Connector threads than it needs to handle the request volume. > Changing this, is much work, and it might get better with Apache 2.0 as > it uses Threads. I don't know any way to avoid this for apache1.3 - if we close the connections the performance will drop. The next request can come on any of the apache childs. > 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. > 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 ? 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 ). > 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. > 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. The only change to the protocol that I think we should do is to replace the marshalling with XDR. Besides that - we can add as many packets and messages as we want - it's just RPC. > 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 ? Does anything in the current jk prevent you from adding any kind of handshake you need ? 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. > 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. 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. 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. Costin > But AJP was flamed enough now! If we have enough ideas, we could write > our own connector for Tomcat and a module for Apache HTTPD. > Any volunteers ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
So, we had a problem trying to port mod_jk2 to NetWare, and that is why we decided to stick with mod_jk. Basically the problem was that mod_jk2 assumed that some data table that existed when Apache does its first load will still be there when apache unloads mod_jk and reloads it. This is not the case on some OS platforms, so this code did not port well at alll. Is this still the case? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] 2/28/03 3:56:59 AM >>> [EMAIL PROTECTED] wrote: > Why not restart work on mod_webapp? I still wonder why it got dropped. Because there was only one developper, Pier, with little help from JF Clere. BTW, jk2 is here, it's modular and use solid foundations. Why not works on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Henri Gomez wrote: [EMAIL PROTECTED] wrote: Why not restart work on mod_webapp? I still wonder why it got dropped. Because there was only one developper, Pier, with little help from JF Clere. BTW, jk2 is here, it's modular and use solid foundations. Why not works on it ? And JK2 support also Apache 1.3/IIS ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
[EMAIL PROTECTED] wrote: Why not restart work on mod_webapp? I still wonder why it got dropped. Because there was only one developper, Pier, with little help from JF Clere. BTW, jk2 is here, it's modular and use solid foundations. Why not works on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Glenn Nielsen wrote: Henri Gomez wrote: Sven Köhler wrote: When Apache will be closing connections at a high rate, you make Tomcat spend precious cycle to catch exceptions, and so you'll slow tomcat also. FYI, Apache close ajp13 connections each time it recycle/kill a child and under heavy load on webserver, it happen very often. I also dislike how mod_jk handles ajp socket connections. There is another problem with how mod_jk handles the ajp connetor sockets. That is the one to one mapping of apache child process to an ajp connector. On an apache server that serves normal http requests you can end up with many idle socket connections to Tomcat, and Tomcat will spawn many more Connector threads than it needs to handle the request volume. I have been toying with the idea of implementing a global worker socket connection pool using APR for the Apache 2 version of mod_jk 1.2. A global pool would allow the sockets to survive a child exit so they don't have to be closed/reopened. This would also reduce the number of socket connections and Tomcat Connectors to the bare miniumum needed to handle the request volume. This would get rid of the "normal operation" exceptions and would not require changing the AJP protocol. This could also be done with mod_jk for Apache 1.3 if a dependency on the APR were added. In the end, I think this is the best solution. +1, that's a great idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
i guess server-admins want to distinguish between normal-server operation and network-errors. currently the log is flooded with unimportant log-messages that are the result of bad error-detection (i hope, i can do better) Without specifics add-ons on the protocol, I doubt you could distinguiss between normal and error socket close.. Another point is that adding new message to protocol make it incompatible with olders java implementations or with alternate implementations (like jetty). OK, but is there a handshake when mod_jk connects to tomcat? mod_jk could receive a sub-version of the protocol to determine which extensions are available. Features present in ajp13++ (ajp14) proposal but not in standard ajp13. So sending unknown messages may crash old ajp13 implementations and that's certainly something we don't want. That was one of the reason why I started to think about an ajp13++ or ajp14. I hope that ajp14 will do better. I would also use JNI-workers, if mod_jk2 would be stable enough. I read that it didn't enjoy such extensive tests as mod_jk. Is this still true? Still i'm worriing about apache-stability when using JNI-workers. JK2 is less tested than JK and we need help here. IMO spending times testing jk2 is more important than trying to resolve this missing ajp13 feature (gracefull close). - update the protocol paper (easy) - update java side implementations (easy for JTC, dunno for Jetty, may be impossible for Tomcat 3.2.x). Some protocols include version-numbers in their handshake, to overcome such problems. I agree with you, that the protocol should be some kind of KISS (keep it simply stupid) ajp13++/ajp14 will be able to do this, I'll work when I could find some times (no before 3 or 4 months ;( But it will be available only in JK2. - add native side code to trap child/thread handle the shutdown more gracefully. that would be a much more "cleaner" sollution. You could start studying where and how to trap this child/thread kill/stop, will put gracefull exit code for ajp13++ here later. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: socket errors in catalina.out and mod_jk.log
Why not restart work on mod_webapp? I still wonder why it got dropped. Travis Original Message From: =?ISO-8859-1?Q?Sven_K=F6hler?= <[EMAIL PROTECTED]> Sent: 2003-02-27 To: [EMAIL PROTECTED] Subject: Re: socket errors in catalina.out and mod_jk.log > There is another problem with how mod_jk handles the ajp connetor sockets. > That is the one to one mapping of apache child process to an ajp connector. > On an apache server that serves normal http requests you can end up with > many idle socket connections to Tomcat, and Tomcat will spawn many more > Connector threads than it needs to handle the request volume. Changing this, is much work, and it might get better with Apache 2.0 as it uses Threads. I took a short look at the ajp13 protocol draft, and the design of the protocol is really simple, too simple. 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 connection), but a "shutdown"-command (shuts down the servlet container, i think it's unused at the moment). so tomcat's connections will keep timing out, and i see no sollution for this with the current protocl design. 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. 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. But AJP was flamed enough now! If we have enough ideas, we could write our own connector for Tomcat and a module for Apache HTTPD. Any volunteers ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
There is another problem with how mod_jk handles the ajp connetor sockets. That is the one to one mapping of apache child process to an ajp connector. On an apache server that serves normal http requests you can end up with many idle socket connections to Tomcat, and Tomcat will spawn many more Connector threads than it needs to handle the request volume. Changing this, is much work, and it might get better with Apache 2.0 as it uses Threads. I took a short look at the ajp13 protocol draft, and the design of the protocol is really simple, too simple. 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 connection), but a "shutdown"-command (shuts down the servlet container, i think it's unused at the moment). so tomcat's connections will keep timing out, and i see no sollution for this with the current protocl design. 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. 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. But AJP was flamed enough now! If we have enough ideas, we could write our own connector for Tomcat and a module for Apache HTTPD. Any volunteers ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Henri Gomez wrote: Sven Köhler wrote: When Apache will be closing connections at a high rate, you make Tomcat spend precious cycle to catch exceptions, and so you'll slow tomcat also. FYI, Apache close ajp13 connections each time it recycle/kill a child and under heavy load on webserver, it happen very often. I also dislike how mod_jk handles ajp socket connections. There is another problem with how mod_jk handles the ajp connetor sockets. That is the one to one mapping of apache child process to an ajp connector. On an apache server that serves normal http requests you can end up with many idle socket connections to Tomcat, and Tomcat will spawn many more Connector threads than it needs to handle the request volume. I have been toying with the idea of implementing a global worker socket connection pool using APR for the Apache 2 version of mod_jk 1.2. A global pool would allow the sockets to survive a child exit so they don't have to be closed/reopened. This would also reduce the number of socket connections and Tomcat Connectors to the bare miniumum needed to handle the request volume. This would get rid of the "normal operation" exceptions and would not require changing the AJP protocol. This could also be done with mod_jk for Apache 1.3 if a dependency on the APR were added. In the end, I think this is the best solution. Regards, Glenn that makes it even worse. Contact new-httpd team ;) If the webserver has closed a connection, tomcat detect it has close the connection silently - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Yes, Exception is a special object which is costly to create and costly to trap. i hope, that catching Exception is optimized by the Java, because it happens quite often in java-programs. creating on exception object, throwing it etc. should happen quite seldom. When Apache will be closing connections at a high rate, you make Tomcat spend precious cycle to catch exceptions, and so you'll slow tomcat also. i respect that within my patch. I'll study your patch at this time. BTW, you should also consider that Windows TCP implementation differs a little from the one in Unix (see the catch code) I will do tests on both platforms. Where should i send my patch? I think i'll have something ready within the next two weeks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
read-error should not happen, as mod_jk could send a quit-paket or something (analog to the ftp-protocol) read-error happen BECAUSE APACHE HTTPD server close client when it recycle them. i hoped, you would react on this one. What's the problem with this connection closing handling ? tomcat detect a closed connection, and close its own socket side then free the thread. i guess server-admins want to distinguish between normal-server operation and network-errors. currently the log is flooded with unimportant log-messages that are the result of bad error-detection (i hope, i can do better) i'm not very much into apache httpd's internals, but i guess, that a child isn't just killed, but notified to terminate itself (OK, perhaps a kill-signal is used), but the question is, if mod_jk is called when a child exits/gets killed. if mod_jk can catch this case, it should gracefully close the connection (like quit-command in FTP-protocol), so tomcat knows, that everything is OK. As I said previously, Apache kill childs under heavy load, and you want add extra delays by sending a message to warn tomcat that the connection will be closed ? I'm not talking about a warning. I'm talking about a "close the connection"-command which mod_jk is sending to tomcat. that's the "perfect" sollution. Tomcat can blindly close the connection, and if the connection was closed without such command, we would have some kind of error-situation. Another point is that adding new message to protocol make it incompatible with olders java implementations or with alternate implementations (like jetty). OK, but is there a handshake when mod_jk connects to tomcat? mod_jk could receive a sub-version of the protocol to determine which extensions are available. That was one of the reason why I started to think about an ajp13++ or ajp14. I hope that ajp14 will do better. I would also use JNI-workers, if mod_jk2 would be stable enough. I read that it didn't enjoy such extensive tests as mod_jk. Is this still true? Still i'm worriing about apache-stability when using JNI-workers. i know, that apache kills and spawns new child every now and than, but as this is normal, this should be handled more gracefully. i cannot supply you with a patch, because i'm not that good in writing apache-modules (in fact, i never did that before, and i didn't write any C/C++ for some years now) I don't see, for now, much need for Tomcat to know that the connection has been dropped gracefully or abnormally, since it will make us : - update the protocol paper (easy) - update java side implementations (easy for JTC, dunno for Jetty, may be impossible for Tomcat 3.2.x). Some protocols include version-numbers in their handshake, to overcome such problems. I agree with you, that the protocol should be some kind of KISS (keep it simply stupid) - add native side code to trap child/thread handle the shutdown more gracefully. that would be a much more "cleaner" sollution. Updating the protocol may create problems with old implementations and as such will great unnecessary questions/problems reports from users... only, if future extensions were not part of the protocol-design (for example via version-numbers). i guess this is the case. I'd rather like to see such energy invested in jk2 and ajp13 extensions. i would look forward to use JNI-workers, if somebody would tell me, how stable this is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote: i looked into these sources, and i am shocked!!! this.receive() uses this.read(), and this method finally calls the InputStream.read(). as everybody should know, InputStrean.read() returns -1 if the end of the inputstream is reached. this case is checked, but instead of doing something useful, the case is not really handled. It's handled, the connection is closed. yes, but it's important to be abled to differ between a "normal" connection shutdown, and a erroneous connection shutdown. i don't see such a difference in the code right now. There is no difference... i suggest throwing an EOSException (EOS=EndOfStream) which is derived from IOException. as this.read() is supposed to read exactly len bytes, it should only throw the EOSException, if the first call of InputStream.read() in the loop returns -1. I'd prefer avoid generation too many exceptions in real-time environnement. After all if read return something < 0, the loop is exited and the connection closed in the finally block. return special values is quite C-stylish. If you want to have quick java programs, you shouldn't be too OOPist. using exception is the OOP way. i don't know, if throwing an exception is that slow, although a new object has to be created every time :-( which might make things slow. Yes, Exception is a special object which is costly to create and costly to trap. on the other hand, exceptions don't occur very often (that's why they're called exceptions) and they shouldn't make it that slow. When Apache will be closing connections at a high rate, you make Tomcat spend precious cycle to catch exceptions, and so you'll slow tomcat also. FYI, Apache close ajp13 connections each time it recycle/kill a child and under heavy load on webserver, it happen very often. that makes it even worse. Contact new-httpd team ;) If the webserver has closed a connection, tomcat detect it has close the connection silently ... except writing those messages to the log. Usually I'd rather like see patches instead of coding style critics. You're welcome to provide us your solution. I'm currently trying to compile tomcat (checked out from cvs) and i will supply you with a patch as soon as i've solved the problem. I'll study your patch at this time. BTW, you should also consider that Windows TCP implementation differs a little from the one in Unix (see the catch code) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote: read-error should not happen, as mod_jk could send a quit-paket or something (analog to the ftp-protocol) read-error happen BECAUSE APACHE HTTPD server close client when it recycle them. i hoped, you would react on this one. What's the problem with this connection closing handling ? tomcat detect a closed connection, and close its own socket side then free the thread. i'm not very much into apache httpd's internals, but i guess, that a child isn't just killed, but notified to terminate itself (OK, perhaps a kill-signal is used), but the question is, if mod_jk is called when a child exits/gets killed. if mod_jk can catch this case, it should gracefully close the connection (like quit-command in FTP-protocol), so tomcat knows, that everything is OK. As I said previously, Apache kill childs under heavy load, and you want add extra delays by sending a message to warn tomcat that the connection will be closed ? Another point is that adding new message to protocol make it incompatible with olders java implementations or with alternate implementations (like jetty). That was one of the reason why I started to think about an ajp13++ or ajp14. i know, that apache kills and spawns new child every now and than, but as this is normal, this should be handled more gracefully. i cannot supply you with a patch, because i'm not that good in writing apache-modules (in fact, i never did that before, and i didn't write any C/C++ for some years now) I don't see, for now, much need for Tomcat to know that the connection has been dropped gracefully or abnormally, since it will make us : - update the protocol paper (easy) - update java side implementations (easy for JTC, dunno for Jetty, may be impossible for Tomcat 3.2.x). - add native side code to trap child/thread handle the shutdown more gracefully. Updating the protocol may create problems with old implementations and as such will great unnecessary questions/problems reports from users... I'd rather like to see such energy invested in jk2 and ajp13 extensions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
i looked into these sources, and i am shocked!!! this.receive() uses this.read(), and this method finally calls the InputStream.read(). as everybody should know, InputStrean.read() returns -1 if the end of the inputstream is reached. this case is checked, but instead of doing something useful, the case is not really handled. It's handled, the connection is closed. yes, but it's important to be abled to differ between a "normal" connection shutdown, and a erroneous connection shutdown. i don't see such a difference in the code right now. i suggest throwing an EOSException (EOS=EndOfStream) which is derived from IOException. as this.read() is supposed to read exactly len bytes, it should only throw the EOSException, if the first call of InputStream.read() in the loop returns -1. I'd prefer avoid generation too many exceptions in real-time environnement. After all if read return something < 0, the loop is exited and the connection closed in the finally block. return special values is quite C-stylish. using exception is the OOP way. i don't know, if throwing an exception is that slow, although a new object has to be created every time :-( which might make things slow. on the other hand, exceptions don't occur very often (that's why they're called exceptions) and they shouldn't make it that slow. FYI, Apache close ajp13 connections each time it recycle/kill a child and under heavy load on webserver, it happen very often. that makes it even worse. If the webserver has closed a connection, tomcat detect it has close the connection silently ... except writing those messages to the log. Usually I'd rather like see patches instead of coding style critics. You're welcome to provide us your solution. I'm currently trying to compile tomcat (checked out from cvs) and i will supply you with a patch as soon as i've solved the problem. cu Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
read-error should not happen, as mod_jk could send a quit-paket or something (analog to the ftp-protocol) read-error happen BECAUSE APACHE HTTPD server close client when it recycle them. i hoped, you would react on this one. i'm not very much into apache httpd's internals, but i guess, that a child isn't just killed, but notified to terminate itself (OK, perhaps a kill-signal is used), but the question is, if mod_jk is called when a child exits/gets killed. if mod_jk can catch this case, it should gracefully close the connection (like quit-command in FTP-protocol), so tomcat knows, that everything is OK. i know, that apache kills and spawns new child every now and than, but as this is normal, this should be handled more gracefully. i cannot supply you with a patch, because i'm not that good in writing apache-modules (in fact, i never did that before, and i didn't write any C/C++ for some years now) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote: Could you give us more information : - jk version you're using (jk or jk2) mod_jk (not mod_jk 2) version 1.2.2 - Apache webserver (1.3/2.0) apache 1.3.27 - Operating system hosting tomcat and apache it's suse linux 7.3 with kernel 2.4.20 with sun jdk 1.4.1_01 This message appears in tomcat in wait for ajp message, since Operating system return Read timed out instead of Read error. read-error should not happen, as mod_jk could send a quit-paket or something (analog to the ftp-protocol) read-error happen BECAUSE APACHE HTTPD server close client when it recycle them. In such case, the connection is dropped and when tomcat see the connection close, it close it's own side of the connection and free the thread. How many times we discussed this on tomcat-user and tomcat-dev lists. Did you take a look at mailing list archives before ? if mod_jk doesn't do that, it's a design-error. Again, you're welcome to provide a better design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote:
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
InputStream.read(). as everybody should know, InputStrean.read() returns
-1 if the end of the inputstream is reached.
this case is checked, but instead of doing something useful, the case is
not really handled.
It's handled, the connection is closed.
i suggest throwing an EOSException (EOS=EndOfStream) which is derived
from IOException.
as this.read() is supposed to read exactly len bytes, it should only
throw the EOSException, if the first call of InputStream.read() in the
loop returns -1.
I'd prefer avoid generation too many exceptions in real-time
environnement. After all if read return something < 0, the loop
is exited and the connection closed in the finally block.
FYI, Apache close ajp13 connections each time it recycle/kill a child
and under heavy load on webserver, it happen very often.
If the webserver has closed a connection, tomcat detect it has close the
connection silently
This exception can be catched down below, to more gracefully handle a
connection-close.
BTW: there's also a comment that this improvement should be in AJP14.
This has nothing to do with AJP14 (which is a protocol) but it's just
bad programmed.
May be.
Usually I'd rather like see patches instead of coding style critics.
You're welcome to provide us your solution.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
InputStream.read(). as everybody should know, InputStrean.read() returns
-1 if the end of the inputstream is reached.
this case is checked, but instead of doing something useful, the case is
not really handled.
i suggest throwing an EOSException (EOS=EndOfStream) which is derived
from IOException.
as this.read() is supposed to read exactly len bytes, it should only
throw the EOSException, if the first call of InputStream.read() in the
loop returns -1.
This exception can be catched down below, to more gracefully handle a
connection-close.
BTW: there's also a comment that this improvement should be in AJP14.
This has nothing to do with AJP14 (which is a protocol) but it's just
bad programmed.
if( status <= 0 ) {
if( status==-3)
log.debug( "server has been restarted or reset
this connection" );
else
log.warn("Closing ajp connection " + status );
break;
}
ep.setLong( MsgContext.TIMER_RECEIVED,
System.currentTimeMillis());
ep.setType( 0 );
// Will call next
status= this.invoke( recv, ep );
if( status!= JkHandler.OK ) {
log.warn("processCallbacks status " + status );
break;
}
}
} catch( Exception ex ) {
if( ex.getMessage().indexOf( "Connection reset" ) >= 0)
log.debug( "Server has been restarted or reset this
connection");
else if (ex.getMessage().indexOf( "Read timed out" ) >=0 )
log.info( "connection timeout reached");
else
log.error( "Error, processing connection", ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Could you give us more information :
- jk version you're using (jk or jk2)
mod_jk (not mod_jk 2) version 1.2.2
- Apache webserver (1.3/2.0)
apache 1.3.27
- Operating system hosting tomcat and apache
it's suse linux 7.3 with kernel 2.4.20 with sun jdk 1.4.1_01
This message appears in tomcat in wait for ajp message,
since Operating system return Read timed out instead of
Read error.
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
if mod_jk doesn't do that, it's a design-error.
Are you using Windows OS ?
no
===>
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
if( status <= 0 ) {
if( status==-3)
log.debug( "server has been restarted or reset
this connection" );
else
log.warn("Closing ajp connection " + status );
break;
}
ep.setLong( MsgContext.TIMER_RECEIVED,
System.currentTimeMillis());
ep.setType( 0 );
// Will call next
status= this.invoke( recv, ep );
if( status!= JkHandler.OK ) {
log.warn("processCallbacks status " + status );
break;
}
}
} catch( Exception ex ) {
if( ex.getMessage().indexOf( "Connection reset" ) >= 0)
log.debug( "Server has been restarted or reset this
connection");
you analyse the text within the exception's message?
this is not the best way, because the message's might change, or is
there any statement by sun, that these texts won't change?
else if (ex.getMessage().indexOf( "Read timed out" ) >=0 )
log.info( "connection timeout reached");
else
log.error( "Error, processing connection", ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Is this mod_jk 2? no, i'm not using mod_jk 2 because i read, that it isn't that well testet yet. I am very familiar with mod_jk 1.2/AJP13 and could answer your questions for it, but your log message imply you are using mod_jk 2 which I am not familiar with enough to answer your question. Costin? why do these log-messages imply, that i'm using mod_jk 2 ? the text i posted was from catalina.out, not from mod_jk's log. this is, what my mod_jk.log looks like (only if i set JkLogLevel to "error"): [Tue Feb 25 16:08:28 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverab le operation. err=0 [Tue Feb 25 16:08:29 2003] [jk_ajp_common.c (926)]: Error sending request body [Tue Feb 25 16:08:30 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Tue Feb 25 16:08:30 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is dow n or network problems. [Tue Feb 25 16:08:30 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverab le operation. err=0 [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is dow n or network problems. [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverab le operation. err=0 [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is dow n or network problems. [Tue Feb 25 16:08:31 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverab le operation. err=0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
Sven Köhler wrote:
hi,
i didn't get any useful response in the tomcat-user-mailinglist.
many users have messages in their catalina.out, saying that a socket
times out, or a connection had been closed.
these messages look like this:
25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processConnection
INFO: connection timeout reached
25.02.2003 20:22:50 org.apache.jk.common.ChannelSocket processConnection
INFO: server has been restarted or reset this connection
Could you give us more information :
- jk version you're using (jk or jk2)
- Apache webserver (1.3/2.0)
- Operating system hosting tomcat and apache
This message appears in tomcat in wait for ajp message,
since Operating system return Read timed out instead of
Read error.
Are you using Windows OS ?
===>
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
if( status <= 0 ) {
if( status==-3)
log.debug( "server has been restarted or reset
this connection" );
else
log.warn("Closing ajp connection " + status );
break;
}
ep.setLong( MsgContext.TIMER_RECEIVED,
System.currentTimeMillis());
ep.setType( 0 );
// Will call next
status= this.invoke( recv, ep );
if( status!= JkHandler.OK ) {
log.warn("processCallbacks status " + status );
break;
}
}
} catch( Exception ex ) {
if( ex.getMessage().indexOf( "Connection reset" ) >= 0)
log.debug( "Server has been restarted or reset this
connection");
else if (ex.getMessage().indexOf( "Read timed out" ) >=0 )
log.info( "connection timeout reached");
else
log.error( "Error, processing connection", ex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: socket errors in catalina.out and mod_jk.log
I just noticed something else too, that these messages occur exactly every 15 minutes: ex: [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=1 [Tue Feb 25 17:15:30 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=2 [Tue Feb 25 17:15:30 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [Tue Feb 25 17:30:26 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=1 [Tue Feb 25 17:30:26 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=2 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:30:26 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=0 [Tue Feb 25 17:30:26 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:30:42 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:30:42 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:30:42 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:30:42 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=2 [Tue Feb 25 17:30:42 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [Tue Feb 25 17:45:26 2003] [jk_connect.c (203)]: jk_open_socket, connect() failed errno = 111 [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (626)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 111 [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (874)]: Error connecting to the Tomcat process. [Tue Feb 25 17:45:26 2003] [jk_ajp_common.c (1190)]: sending request to tomcat failed in send loop. err=1 Travis Original Message From: [EMAIL PROTECTED] Sent: 2003-02-25 To: Tomcat Developers List <[EMAIL PROTECTED]> Subject: RE: socket errors in catalina.out and mod_jk.log I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday. Travis Original Message From: =?UTF-8?B?U3ZlbiBLw7
Re: socket errors in catalina.out and mod_jk.log
Is this mod_jk 2? I am very familiar with mod_jk 1.2/AJP13 and could answer your questions for it, but your log message imply you are using mod_jk 2 which I am not familiar with enough to answer your question. Costin? Glenn Sven Köhler wrote: hi, i didn't get any useful response in the tomcat-user-mailinglist. many users have messages in their catalina.out, saying that a socket times out, or a connection had been closed. these messages look like this: 25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processConnection INFO: connection timeout reached 25.02.2003 20:22:50 org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection these messages appear frequently (about every second) the first message occurs more often than the second one. i know now, that the second message appears, if apache closes it socket, and tomcat get a read-error or such. i don't know, why the first message appears. would be nice to know! in addition, i see many errors in mod_jk's error-log, if i set the log-level to "error". WHY (and i have asked myself a thousand times) is this? - why doesn't mod_jk send a quit-command to tomcat, and both sides will gracefully close the connection? - why do the connections timeout? why isn't there something like a keep-alive which is send my mod_jk every now and than? does the AJP13 protocol include keep-alives? does it include something like quit-command? if not (that would be a shame btw) is this included in AJP14? is this a known, but still not fixed, problem? why isn't it fixed? i cannot understand, how you can live with that!? it might be my fault, but nobody seems to know anything about these strange messages! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: socket errors in catalina.out and mod_jk.log
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday. i think everbody gets these messages, but nobody has ever states, if they are normal, should be fixed, can be fixed or where the hell they came from! when will finally somebody of the tomcat-team comment the situation!? i think i will have to take a look the sources, altough i doubt, that my patches would be ever accepted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: socket errors in catalina.out and mod_jk.log
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday. Travis Original Message From: =?UTF-8?B?U3ZlbiBLw7ZobGVy?= <[EMAIL PROTECTED]> Sent: 2003-02-25 To: [EMAIL PROTECTED] Subject: socket errors in catalina.out and mod_jk.log hi, i didn't get any useful response in the tomcat-user-mailinglist. many users have messages in their catalina.out, saying that a socket times out, or a connection had been closed. these messages look like this: 25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processConnection INFO: connection timeout reached 25.02.2003 20:22:50 org.apache.jk.common.ChannelSocket processConnection INFO: server has been restarted or reset this connection these messages appear frequently (about every second) the first message occurs more often than the second one. i know now, that the second message appears, if apache closes it socket, and tomcat get a read-error or such. i don't know, why the first message appears. would be nice to know! in addition, i see many errors in mod_jk's error-log, if i set the log-level to "error". WHY (and i have asked myself a thousand times) is this? - why doesn't mod_jk send a quit-command to tomcat, and both sides will gracefully close the connection? - why do the connections timeout? why isn't there something like a keep-alive which is send my mod_jk every now and than? does the AJP13 protocol include keep-alives? does it include something like quit-command? if not (that would be a shame btw) is this included in AJP14? is this a known, but still not fixed, problem? why isn't it fixed? i cannot understand, how you can live with that!? it might be my fault, but nobody seems to know anything about these strange messages! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
