Re: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Please witch over to tomcat-user for discussion. This is not really a developer issue. === My previous comments (bugzilla) === First hints from my side: reduce to equal number of apache and tomcat instances, configure F5 with rule that sends URLs with session cookie or jsessionid in URL to the correct apache. Furthermore configure mod_jk, such that each apache sends requests without sessions to it's preferred tomcat partner. That way almost all apache processes will connect to only one tomcat. If you still need 16K apache processes per instance you are in trouble (maybe upgrade to apache 2), if you manage to handle the workload with 1K apache processes, 1K Threads in Tomcat should be OK. === Additional comments === If you don't want to reuse the connections between apache and tomcat (last ressort solution) switch over to connectors of type ajp12 (they will close the connection after each request-response cycle) or set cachesize to 0 which will use ajp13 protocol, but I think it will close connections after each request too. I hope you don't use HTTP keep alive? Also: I vaguely remember there was an experimental connector/thread pool implementation with asynchroneous features. It might be, that this implementation does not need one fixed thread for each apache connection and I think it is beeing shipped with 5.5.x, but not enabled on default. Concerning this topic tomcat-dev might be the right place to ask. Rainer Remy Gendron wrote: Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too
DO NOT REPLY [Bug 36827] New: - Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36827 Summary: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle. Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Heres the situation as it stands today and what can be done to solve it. Ill try to keep this short. Running configuration: Running on Linux Red-Hat Ent 3 1 X F5 load balancer and hardware SSL box. 5 X Apache 1.3.33/mod_jk 1.2.14 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too many web server children are created to serve the company load. Thus, many different routes can be taken by requests targeted to our application, keeping all the connection alive. 12. We tried really small recycle_timeout values (e.g. 20) with no effect. A netstat reveals that connections remain ESTABLISHED. 13. The maxRequestsPerChild setting is set to 0 in PROD. It means that Apache child processes will never die, unless you reach the maxSpareServers value. Thus, at least 100 connections per web server will always remain actively connected to Tomcat. A 0 value would at least guarantee that a child process would eventually die, freeing
Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too many web server children are created to serve the company load. Thus, many different routes can be taken by requests targeted to our application, keeping all the connection alive. 12. We tried really small recycle_timeout values (e.g. 20) with no effect. A netstat reveals that connections remain ESTABLISHED. 13. The maxRequestsPerChild setting is set to 0 in PROD. It means that Apache child processes will never die, unless you reach the maxSpareServers value. Thus, at least 100 connections per web server will always remain actively connected to Tomcat. A 0 value would at least guarantee that a child process would eventually die, freeing Tomcat connections and releasing back leaked memory to the OS. It's hard to see a path out of this one. One solution would be to reduce the MaxClients Apache config back to 256. This would mean that a single instance of Tomcat would not be hit by more than 256 * 5 = 1280 (5 is the web farm size) connections. Our current jvm settings (heap + thread stack sizes) would allow us to do it. We would also need to bump our current 1200 limit a bit higher. However, this solution if not compatible with other applications which have really high loads. Second option would be to patch mod_jk so that connections are dropped as soon as the response has been received from Tomcat. Drawbacks include preventing us from upgrading to new releases (unless we re-apply the modifications), introduce
DO NOT REPLY [Bug 36538] - (Apache 2.0.54) mod_jk 1.2.14 ignores -ForwardDirectories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36538. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36538 [EMAIL PROTECTED] changed: What|Removed |Added Summary|(Apache 2.0.54) mod_jk |(Apache 2.0.54) mod_jk |1.2.10 ignores -|1.2.14 ignores - |ForwardDirectories |ForwardDirectories -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-21 07:19 --- CVS head from earlier today works for me on SGI IRIX and Fedora Core 4. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-18 20:52 --- Same problem here. Please let us know how we can help debugging that issue. Thanks Alex -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-19 00:48 --- (In reply to comment #10) Same problem here. Please let us know how we can help debugging that issue. Thanks Alex It's pretty clear what is happening: mod_jk isn't sending the POST body before the Tomcat-configured connectionTimeout has been reached. What isn't clear is why. In the first dump example, the worker in the JSESSIONID cookie isn't in the list (there are also some decoding problems, but they shouldn't affect Tomcat). In the second dump example, mod_jk has decided to send the request to a different worker than the one in the cookie for some reason. Otherwise, they are perfectly normal POST request records. Probably, somebody is going to have to be able to reproduce this with 'JkLogLevel debug' (or even 'JkLogLevel trace' :) to get some idea why the POST body wasn't sent. As an aside, Tomcat 5.5.11+ won't have this particular error, but it is also extremely unlikely to actually work. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36525.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36525
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-17 11:50 ---
I just tried compiling on IRIX using latest CVS, but the modified jk_shm.c does
not compile using the SGI CC compiler:
jk_shm.c, line 50: warning(1040): expected an identifier
Apparently the compiler doesn't like the union inside of the struct. Removing
the union makes it compile and seems to function OK as well (sorry, even though
my C is a bit rusty my change sure looks like a hack!):
diff -u -r1.20 jk_shm.c
--- common/jk_shm.c 16 Sep 2005 05:52:26 - 1.20
+++ common/jk_shm.c 17 Sep 2005 09:43:10 -
@@ -43,10 +43,8 @@
/** jk shm header record structure */
struct jk_shm_header
{
-union {
-jk_shm_header_data_t data;
-char alignbuf[JK_SHM_ALIGN(sizeof(jk_shm_header_data_t))];
-};
+jk_shm_header_data_t data;
+char alignbuf[JK_SHM_ALIGN(sizeof(jk_shm_header_data_t))];
char buf[1];
};
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36525.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36525
--- Additional Comments From [EMAIL PROTECTED] 2005-09-17 12:00 ---
The compiler probably does not like un named unions rather then
unions itself.
Can you try something like:
union {
...
...
} h;
Of course you will need to change the jk_shm.c code
for each 'hdr-data.XXX' to the 'hdr-h.data.XXX'
Tell me if that helps.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-17 12:32 --- Created an attachment (id=16437) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16437action=view) unnamed-union.patch Yes, that appears to compile and run OK. Here is the attached diff I used against jk_shm.c. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-17 13:21 --- Hi, I have commited the patch. Can you double check with the current HEAD and close the issue if all is working. Thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 08:55 --- Mladen Turk applied the patch. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug or Feature inside mod_jk loadbalancer algo?
Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug or Feature inside mod_jk loadbalancer algo?
Sounds good to me. Wrote a spec before implementation is very helpfull :-) The domain case with sticky session and real clustered szenarios is not easy. Peter Mladen Turk schrieb: Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? Regards, Mladen. - 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]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 01:03 --- Created an attachment (id=16424) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16424action=view) Correct misalignment There is an alignment problem in the shared memory. The bug only shows up, when gcc is used with -O or -O2. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-09-16 01:05 --- I reopen the bug, because: - I think the above patch will resolve the problem and still allow to use 64 Bit counters - I think that without the patch there might result further cores when the members of the structs in the shared memory are changed in the future (even without 64 Bit members) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36655] New: - mod_jk 1.2.12+ does not submit correct request port number to tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36655 Summary: mod_jk 1.2.12+ does not submit correct request port number to tomcat Product: Tomcat 4 Version: 4.1.31 Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: Connector:JK/AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In our infrastructure a https request is handled in this way: https request(port 443) - SSL-accelerator (Nortel/Alteon) - decrypted request port 50443 - Apache-2.0.53 listening on 80, 55443 using virtual hosts - mod_jk 1.2.12, AJP13 port 8200 - Tomcat 4.1.31 with application The application checks wether a request hit the Apache2 on port 55443 or 80. If the port was 80, a warning message is sent back to the client about unencrypted traffic. Now we got the warning message also with a request on port 55443. mod_jk logs in debug mode: [Fri Sep 09 11:28:20 2005] [22238:0006] [debug] init_ws_service::mod_jk.c (510): Service pro tocol=HTTP/1.1 method=GET host=(null) addrr=192.168.70.130 name=jportal1-riat-p.bap.fiducia. de port=80 auth=(null) user=(null) laddr=10.253.52.65 raddr=192.168.70.130 So there is a wrong port number sent to Tomcat/application. I have traced the problem down to jakarta-tomcat-connectors-1.2.12-src/jk/native/apache-2.0/mod_jk.c where I've found the following: /* get the real port (otherwise redirect failed) */ /* XXX: use apache API for getting server port * * Pre 1.2.7 versions used: * s-server_port = r-connection-local_addr-port; */ s-server_port = ap_get_server_port(r); So I uncommented the old code and commented the new line: /* get the real port (otherwise redirect failed) */ /* XXX: use apache API for getting server port * * Pre 1.2.7 versions used: */ s-server_port = r-connection-local_addr-port; /*s-server_port = ap_get_server_port(r); */ Now the mod_jk log says: [Fri Sep 09 13:15:10 2005] [22238:0006] [debug] init_ws_service::mod_jk.c (510): Service pro tocol=HTTP/1.1 method=GET host=(null) addrr=192.168.70.130 name=jportal1-riat-p.bap.fiducia. de port=55443 auth=(null) user=(null) laddr=10.253.52.65 raddr=192.168.70.130 The port is now sent correctly to Tomcat/application. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36655] - mod_jk 1.2.12+ does not submit correct request port number to tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36655 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-14 14:17 --- Hi, You should supply the port with ServerName. This is from ap_get_server_port: /* With UseCanonicalName on (and in all versions prior to 1.3) * Apache will use the hostname and port specified in the * ServerName directive to construct a canonical name for the * server. (If no port was specified in the ServerName * directive, Apache uses the port supplied by the client if * any is supplied, and finally the default port for the protocol * used. So, since probably nothing matched, the 80 (as default) was used. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 15:03 --- Fixed in the CVS. This was really strange. Seems that shared memory gets corrupted if 64 bit access is desired. Can you try the current HEAD? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36538] - (Apache 2.0.54) mod_jk 1.2.10 ignores -ForwardDirectories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36538. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36538 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 15:32 --- Please use the most recent stable version, and see if the problem is in there too. Prior versions will not be fixed, so it's useless to file a bug report on previous versions. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36022] - It is not possible to set property 'recover_time' to a value less then 60 seconds (mod_jk)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36022 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 15:34 --- Like Rainer said, the 60 seconds is uses as compiled minimum. If you need a lower value for experiments (I doubt something like that would make sense in production), change default settings and recompile. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36538] - (Apache 2.0.54) mod_jk 1.2.10 ignores -ForwardDirectories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36538. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36538 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-09-12 17:12 --- (In reply to comment #1) Please use the most recent stable version, and see if the problem is in there too. Prior versions will not be fixed, so it's useless to file a bug report on previous versions. Hi, I have tested the latest version of JK (JK1.2.14). The problem is still there (same results as with JK version 1.2.10) Best Regards. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-13 00:38 --- Checked out from CVS today, and can confirm that the new build appears to work properly. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36538] New: - (Apache 2.0.54) mod_jk 1.2.10 ignores -ForwardDirectories
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36538. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36538 Summary: (Apache 2.0.54) mod_jk 1.2.10 ignores - ForwardDirectories Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Using Apache 2.0.54 / JK1.2.10 / Tomcat 5.5.9 -ForwardDirectories (defauted or explicitly coded) has no effects : all URIs that map to a directory are passed to and responded by tomcat, instead of Apache 1/ If no index.html, no index.jsp, and without 'Options Indexes' is present : Expected : 403 Forbidden returned by Apache Actually : Directory listing returned by Tomcat 2/ If no index.html, no index.jsp, but with 'Options Indexes' : Expected : Directory listing returned by Apache Actually : Directory listing returned by Tomcat Directives used --- DirectoryIndex index.html JkOptions -ForwardDirectories SetEnvIf Request_URI .htm$|\.html$|\.css$|\.js$|\.gif$|\.jpg$|\.jpeg$ no-jk VirtualHost *:* ... Alias /context-root /path/to/webapp/docs JkMount /context-root/* workerName /VirtualHost Aditionnal information -- I found a similar problem, reported in the bug 25104, for mod_jk 1.2.5 and Tomcat 4. It was not solved, because jk 1.2 was told to be deprecated. But it is actually not. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 11:25 --- I can confirm that I fully shut down Apache before installing the new mod_jk and starting Apache back up. Removing the mod_jk.shm after shutting down, installing the new module and starting back up doesn't make a difference. Using ipcs to view shared memory after Apache shutdown shows that Apache has correctly released the shared memory that was in use. Hope to try commenting out the lines in the next day or 2. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:18 --- I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] New: - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 Summary: mod_jk 1.2.14.1 core dump Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: IRIX Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] On SGI IRIX mod_jk 1.2.14.1 crashes on every request in jk_lb_worker.c line 605. Going back to 1.2.11 works fine. Stack trace below: 0 service(e = 0x1035afe8, s = 0x7fff2b28, l = 0x10281f68, is_error = 0x7fff1af4) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_lb_worker.c:605, 0x4315080] 1 jk_handler(r = 0x103719a0) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/apache-2.0/mod_jk.c:1889, 0x4305648] 2 ap_run_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:152, 0x1008b624] 3 ap_invoke_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:364, 0x1008c390] 4 ap_process_request(r = 0x103719a0) [/tmp/httpd-2.0.54/modules/http/http_request.c:249, 0x10071990] 5 ap_process_http_connection(c = 0x10365460) [/tmp/httpd-2.0.54/modules/http/http_core.c:251, 0x10070f78] 6 ap_run_process_connection(c = 0x10365460) [/tmp/httpd-2.0.54/server/connection.c:43, 0x100a3e94] 7 ap_process_connection(c = 0x10365460, csd = 0x10365378) [/tmp/httpd-2.0.54/server/connection.c:176, 0x100a4568] 8 child_main(child_num_arg = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:610, 0x1007c444] 9 make_child(s = 0x102941c0, slot = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:704, 0x1007c6ac] 10 startup_children(number_to_start = 5) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:722, 0x1007c75c] 11 ap_mpm_run(_pconf = 0x1025aac0, plog = 0x1028cb88, s = 0x102941c0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:941, 0x1007cda0] 12 main(argc = 3, argv = 0x7fff2f44) [/tmp/httpd-2.0.54/server/main.c:618, 0x100b1c48] 13 __start() [/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:177, 0x1004b9e8] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-06 20:28 --- First email sent to tomcat-dev: http://marc.theaimsgroup.com/?l=tomcat-devm=112501659012202w=2 Another user has reported what appears to be the exact same crash on Solaris. I am guessing that this is either some sort of 64-bit or big endian bug that does not show up on i386 (where mod_jk 1.2.14.1 works fine for me) http://marc.theaimsgroup.com/?l=tomcat-userm=112569118927613w=2 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36525] - mod_jk 1.2.14.1 core dump
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36525 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 07:44 --- Hi, Can you comment lines 605 and 606 in jk_lb_worker.c and see if it still core dumps. Also, did you try to stop the previous version and delete .shm file? Nou sure, but even reboot might be required if OS catched the shared memory. The shared memory slot was enlarged with 1.2.14 version so the stuctures are different, and if old one are catched then the new one will core dump. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 core dump
On 8/28/05, Jean-frederic Clere [EMAIL PROTECTED] wrote: David Rees wrote: I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? When does it happend? It happens the first time I try a request which is mapped to a Tomcat instance. Instead of the page getting served up by Tomcat, I get a blank page. Tomcat is 5.5.9 if it matters. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 core dump
David Rees wrote: I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? When does it happend? -Dave 0 service(e = 0x1035afe8, s = 0x7fff2b28, l = 0x10281f68, is_error = 0x7fff1af4) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_lb_worker.c:605, 0x4315080] 1 jk_handler(r = 0x103719a0) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/apache-2.0/mod_jk.c:1889, 0x4305648] 2 ap_run_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:152, 0x1008b624] 3 ap_invoke_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:364, 0x1008c390] 4 ap_process_request(r = 0x103719a0) [/tmp/httpd-2.0.54/modules/http/http_request.c:249, 0x10071990] 5 ap_process_http_connection(c = 0x10365460) [/tmp/httpd-2.0.54/modules/http/http_core.c:251, 0x10070f78] 6 ap_run_process_connection(c = 0x10365460) [/tmp/httpd-2.0.54/server/connection.c:43, 0x100a3e94] 7 ap_process_connection(c = 0x10365460, csd = 0x10365378) [/tmp/httpd-2.0.54/server/connection.c:176, 0x100a4568] 8 child_main(child_num_arg = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:610, 0x1007c444] 9 make_child(s = 0x102941c0, slot = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:704, 0x1007c6ac] 10 startup_children(number_to_start = 5) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:722, 0x1007c75c] 11 ap_mpm_run(_pconf = 0x1025aac0, plog = 0x1028cb88, s = 0x102941c0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:941, 0x1007cda0] 12 main(argc = 3, argv = 0x7fff2f44) [/tmp/httpd-2.0.54/server/main.c:618, 0x100b1c48] 13 __start() [/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:177, 0x1004b9e8] - 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]
mod_jk 1.2.14.1 core dump
I'm getting a core dump on my SGI IRIX machine using mod_jk 1.2.14.1 in jk_lb_worker.c line 605. The stack trace is below. This happens on any JK request I try. Going back to 1.2.11 works fine. Any ideas? -Dave 0 service(e = 0x1035afe8, s = 0x7fff2b28, l = 0x10281f68, is_error = 0x7fff1af4) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_lb_worker.c:605, 0x4315080] 1 jk_handler(r = 0x103719a0) [/tmp/jakarta-tomcat-connectors-1.2.14.1-src/jk/native/apache-2.0/mod_jk.c:1889, 0x4305648] 2 ap_run_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:152, 0x1008b624] 3 ap_invoke_handler(r = 0x103719a0) [/tmp/httpd-2.0.54/server/config.c:364, 0x1008c390] 4 ap_process_request(r = 0x103719a0) [/tmp/httpd-2.0.54/modules/http/http_request.c:249, 0x10071990] 5 ap_process_http_connection(c = 0x10365460) [/tmp/httpd-2.0.54/modules/http/http_core.c:251, 0x10070f78] 6 ap_run_process_connection(c = 0x10365460) [/tmp/httpd-2.0.54/server/connection.c:43, 0x100a3e94] 7 ap_process_connection(c = 0x10365460, csd = 0x10365378) [/tmp/httpd-2.0.54/server/connection.c:176, 0x100a4568] 8 child_main(child_num_arg = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:610, 0x1007c444] 9 make_child(s = 0x102941c0, slot = 0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:704, 0x1007c6ac] 10 startup_children(number_to_start = 5) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:722, 0x1007c75c] 11 ap_mpm_run(_pconf = 0x1025aac0, plog = 0x1028cb88, s = 0x102941c0) [/tmp/httpd-2.0.54/server/mpm/prefork/prefork.c:941, 0x1007cda0] 12 main(argc = 3, argv = 0x7fff2f44) [/tmp/httpd-2.0.54/server/main.c:618, 0x100b1c48] 13 __start() [/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:177, 0x1004b9e8] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inprocess Tomcat/apache via mod_jk
With worker - it may work. However you may find mod_jk inprocess to be slower than ajp and mod_proxy ( or comparable in speed ), this is due to the way parameters are passed as strings ( i.e. lots of unoptimized char-byte conversion ). Porting to 5.5.x shouldn't be hard - the interface between tomcat and modjk is very simple: you need to startup, i.e. make sure classpath is set and the class that executes launches tomcat correctly, and then it's a simple class that does the request/response passing. If you do this for performance reasons - you may want to look at the code in jk2, and try to backport it. A benefit would be that the interface is even simpler - the req/response are passed in the same kind of buffer as ajp requests. AFAIK that's the only major difference. Since Remy, Mladen, etc have greatly optimized the regular tcp connectors - probably the difference on performance ( with this optimization backported ) will be small. But if you use the old style of interface - I'm sure jni will be slower (it was slower 2 years ago). Costin Christine Ho wrote: Hi, Thanks a lot. I am really appreciated for your reply. How about the worker MPM? My team is running the httpd.worker on RHEL4. The current setting is: StartServers 1 ServerLimit 1 MaxClients 64 MinSpareThreads 32 MaxSpareThreads 64 ThreadsPerChild 64 Does the inprocess Tomcat 5.5.9 work for the worker MPM? thanks, Christine --- Bill Barker [EMAIL PROTECTED] wrote: Well, inprocess doesn't really work for any MPM on *nix systems (e.g. with the prefork MPM, you end up with MaxChild copies of Tomcat running :). As a result, there just hasn't been that much interest in implementing (or even back-porting) a feature that only works on Windows and NetWare. - Original Message - From: Christine Ho [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 3:30 PM Subject: inprocess Tomcat/apache via mod_jk Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
inprocess Tomcat/apache via mod_jk
Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inprocess Tomcat/apache via mod_jk
Well, inprocess doesn't really work for any MPM on *nix systems (e.g. with the prefork MPM, you end up with MaxChild copies of Tomcat running :). As a result, there just hasn't been that much interest in implementing (or even back-porting) a feature that only works on Windows and NetWare. - Original Message - From: Christine Ho [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Tuesday, August 16, 2005 3:30 PM Subject: inprocess Tomcat/apache via mod_jk Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inprocess Tomcat/apache via mod_jk
Hi, Thanks a lot. I am really appreciated for your reply. How about the worker MPM? My team is running the httpd.worker on RHEL4. The current setting is: StartServers 1 ServerLimit 1 MaxClients 64 MinSpareThreads 32 MaxSpareThreads 64 ThreadsPerChild 64 Does the inprocess Tomcat 5.5.9 work for the worker MPM? thanks, Christine --- Bill Barker [EMAIL PROTECTED] wrote: Well, inprocess doesn't really work for any MPM on *nix systems (e.g. with the prefork MPM, you end up with MaxChild copies of Tomcat running :). As a result, there just hasn't been that much interest in implementing (or even back-porting) a feature that only works on Windows and NetWare. - Original Message - From: Christine Ho [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Tuesday, August 16, 2005 3:30 PM Subject: inprocess Tomcat/apache via mod_jk Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk logging buffer
Hi, the problem is not only a delay but also an order of the messages. I think all messages should be flushed to the file as soon as they come. When I choosing to log 'info' messages I accept the fact that it will slow down the processing of requests. That is always a drawback of logging. The users should be aware of this. I have never see apache server showing log entries in a wrong order or delayed? Then why delay it in mod_jk?? By not flushing output immediatelly you are shirnking the functionality of logging mechanism. -- Radek Mladen Turk wrote: Jean-frederic Clere wrote: Radek Wierzbicki wrote: Hello, better : if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || level==JK_LOG_ERROR) No? Flush should not be executed for INFO level. It slows the things down by the factor of 2. I agree for ERROR and EMERG. DEBUG and TRACE uses fflush so the order of messages can be traced, but that is also dubious because the messages could come from different threads, so the best would be to use the fflush only with ERROR and EMERGE levels. Regards, Mladen. - 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: mod_jk logging buffer
Mladen Turk wrote:
Jean-frederic Clere wrote:
Radek Wierzbicki wrote:
Hello,
better :
if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
No?
Flush should not be executed for INFO level. It slows the things
down by the factor of 2. I agree for ERROR and EMERG.
DEBUG and TRACE uses fflush so the order of messages can be traced,
but that is also dubious because the messages could come from
different threads, so the best would be to use the fflush only
with ERROR and EMERGE levels.
So it is OK to commit the following:
++
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.71
diff -u -r1.71 jk_util.c
--- common/jk_util.c1 Jul 2005 15:41:08 - 1.71
+++ common/jk_util.c14 Aug 2005 18:28:29 -
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level JK_LOG_INFO_LEVEL)
+if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
fflush(p-logfile);
}
++
isn't it?
Regards,
Mladen.
-
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]
mod_jk logging buffer
Hello,
I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger
buffers and delays the output of messages with levels below 'info'
(info, warning, error, emergency, request).
With the new version, setting the log level to 'error' on production
setups will delay the output of critical error messages. I think that is
unacceptable.
Wouldn't it make sense to reverse the logic and immediatelly flush the
log messages with level 'info' and below, and buffer 'debug' and 'trace'
messages?
Maybe a configuration option for log buffering would make sense?
Patch:
--- jk_util.c.orig 2005-07-01 17:41:08.0 +0200
+++ jk_util.c 2005-08-12 13:44:01.0 +0200
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level JK_LOG_INFO_LEVEL)
+if (l-level JK_LOG_DEBUG_LEVEL)
fflush(p-logfile);
}
... awaiting comments ...
-Radek W.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk logging buffer
Radek Wierzbicki wrote:
Hello,
I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger
buffers and delays the output of messages with levels below 'info'
(info, warning, error, emergency, request).
With the new version, setting the log level to 'error' on production
setups will delay the output of critical error messages. I think that
is unacceptable.
Wouldn't it make sense to reverse the logic and immediatelly flush the
log messages with level 'info' and below, and buffer 'debug' and
'trace' messages?
Maybe a configuration option for log buffering would make sense?
Patch:
--- jk_util.c.orig 2005-07-01 17:41:08.0 +0200
+++ jk_util.c 2005-08-12 13:44:01.0 +0200
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level JK_LOG_INFO_LEVEL)
+if (l-level JK_LOG_DEBUG_LEVEL)
fflush(p-logfile);
}
... awaiting comments ...
better :
if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
level==JK_LOG_ERROR)
No?
-Radek W.
-
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: mod_jk logging buffer
Jean-frederic Clere wrote: Radek Wierzbicki wrote: Hello, better : if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || level==JK_LOG_ERROR) No? Flush should not be executed for INFO level. It slows the things down by the factor of 2. I agree for ERROR and EMERG. DEBUG and TRACE uses fflush so the order of messages can be traced, but that is also dubious because the messages could come from different threads, so the best would be to use the fflush only with ERROR and EMERGE levels. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36155] New: - tomcat chooses wrong host if using mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36155. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36155 Summary: tomcat chooses wrong host if using mod_jk Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, my config is as follows: tomcat 5.5.9 knows two hosts, let's say the host host1 and the host host2. http://host1/ is basically a jsp-page echoing the string host1 - http://host2/ echos the string host2. apache 2.0.54 is configured with two vhost with ServerName host1 and host2. Both servers have a ServerAlias too - the one has ServerAlias alias1, the other has ServerAlias alias2 mod-jk 1.2.14 only knows one worker. My worker.properties looks like this: worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=127.0.0.1 A very simple config. Both apache vhosts contain a JkMount *.jsp worker1 Apache's UseCanonialName is on and Tomcats AJP-connector has useIPVHosts turned on. Therefor tomcat will chose the host by the server-name that mod_jk sends. So calling http://alias1/ results in a page containing the string host1, and calling http://alias2/ results in a page containing the string host2. The problem: Sometimes (not always and very selden) http://alias1 returns the string host2 and http://alias2 returns the string host1. I'm not sure, where the problem is, but i'm almost sure it's mod_jk - although i don't know, what should go wrong. I now defined a second worker with the same address and each of apache's vhosts use a different worker. The error didn't come up yet. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36138] New: - mod_jk load balance algorithm that accounts for current worker load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36138. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36138 Summary: mod_jk load balance algorithm that accounts for current worker load Product: Tomcat 5 Version: Unknown Platform: All OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] This is the mod_jk patch I mentioned on the tomcat-dev mailing list on August 6. The patch adds a new lb.method option 'B' for 'Busyness'. The algorithm picks the lbworker with the lowest current load, based on how many requests the worker is currently serving (the Busy column in the jkstatus page). This number is divided by the worker's lbfactor, and the lowest value (least busy) worker is picked. We tested about 25-30 threads against 6 load-balanced tomcats with requests that take about 250ms each to complete. Using the Busyness algorithm improved our throughput from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server started lagging, its Busy value increased, so it received fewer requests. If a request is received when none of the workers are busy, this algorithm is effectively an evenly-weighted round-robin. Note that we found some race conditions with the code that updates the various lb status values, especially the lbworker busy value, which our algorithm requires to be accurate. To fix this, we had to refactor some of the shared memory and critical-section locking code, by moving the lock into get_most_suitable_worker() (jk_lb_worker.c). We also found some problems that would cause the 'busy' value to be set to less than zero (displaying MAX_INT - 1, for example, in jkstatus). We fixed this by setting the busy value to 0 if it is ever less than 0. See jk_lb_worker.c lines 389-400. Finally, we added a new column to the jkstatus page. The Ssc column now reports the number of times the worker was reused from sticky session. See jk_shm.c line 89, and jk_lb_worker.c line 584. We have load-tested this patch under apache 2.0.50, and we've also been running it in a busy production site for almost a week. This patch is donated by Andrew Hudson and Chris Lamprecht. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36138] - mod_jk load balance algorithm that accounts for current worker load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36138. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36138 --- Additional Comments From [EMAIL PROTECTED] 2005-08-11 06:12 --- Created an attachment (id=16009) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16009action=view) New load balancing algorithm for mod_jk -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch: mod_jk load balance algorithm that accounts for current worker load
Excellent, I'd love to see this end up in the proxy loadbalancer. I just submitted the patch: http://issues.apache.org/bugzilla/show_bug.cgi?id=36138 Please do so... There is also some overlap with Apache's proxy load balancer as well, which I would want to fold back in. For example, in Apache I added the bytraffic method, which was then folded into mod_jk by Mladen. So once busyness is added to mod_jk, I'll look on adding it to the Apache tree. - 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: patch: mod_jk load balance algorithm that accounts for current worker load
On Aug 6, 2005, at 3:48 AM, Chris Lamprecht wrote: We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Please do so... There is also some overlap with Apache's proxy load balancer as well, which I would want to fold back in. For example, in Apache I added the bytraffic method, which was then folded into mod_jk by Mladen. So once busyness is added to mod_jk, I'll look on adding it to the Apache tree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch: mod_jk load balance algorithm that accounts for current worker load
mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any
RE: RE: RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris
Re: patch: mod_jk load balance algorithm that accounts for current worker load
Chris Lamprecht wrote: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. Great! Can you open an bugzilla entry for Native:JK and attach the patch. Please file that as enhancement. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36022] New: - It is not possible to set property 'recover_time' to a value less then 60 seconds (mod_jk)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36022 Summary: It is not possible to set property 'recover_time' to a value less then 60 seconds (mod_jk) Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I've tested it by using the status page and using a test application. I configured a load balancer with 2 workers (tom1 tom2) (linux, apache 2.0.54, mod_jk 1.2.14, tomcat 5.5.9 and jdk_1.5.0 update 3). I configured the property recover_time with a value of 10 seconds. First, I stop one tomcat instance (tom1). The status page immediately shows that this worker is in error state. Then, i restart this tomcat instance (tom1), wait 10 seconds, and then stop tomcat instance 2 (tom2). In most times my application shows a 503 Service Temporarily Unavailable page. However, it may occur that the application is working properly. The status page as well does not show that within 10 seconds a tomcat instance is recovered fully (in most cases). The status page of mod_jk 1.2.14 offers the user to alter the recovery time. However, using a value less then 60 does *not* affect a change. Is it possible for future versions to allow a recovery time less than 60 seconds ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36022] - It is not possible to set property 'recover_time' to a value less then 60 seconds (mod_jk)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36022. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36022 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 12:40 --- 60 seconds is the defualt. The load balancer code only allows values at least 60 seconds. If you try a short recover_time, it will be set to 60 seconds. Recovery is not cheap, so trying to often will not really help. If you have a load balanced application 1 minute recovery interval looks like a reasonable minimum. I think the parameter is not yet documented, so especially it's minimum value is not in the docs. You might supply a documentation patch, if you like to. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:05 --- Created an attachment (id=15844) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15844action=view) workers.properties from mod_jk configuration -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:07 --- Created an attachment (id=15845) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15845action=view) modjk directives -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:09 --- I have attached our workers.properties file and a file jk.conf including the directives. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:29 --- (In reply to comment #3) Hmm, This seems like you are using 'application/x-www-form-urlencoded' with GET request. Can you post the full mod_jk log from the beggining of the transaction to the end for that request. There must be some errors in ajp protocol, either setting timeout too low or forbidding post requests. Hello, I have sent attachements concerning workers.properties an directives. Our application is using webservers running behind a loadbalancer. Therefore it is a little bit difficult to find the exact statement that matches the stack trace of the tomcat. But there some stack traces in our Tomcats logfile and I will sent a you a typical error sequence from a modjk log file [Mon Aug 01 18:56:03 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any moreajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:54:17 2005] [info] jk_open_socket::jk_connect.c (444): connect to 145.228.205.181:16008 failed with errno=111 [Mon Aug 01 18:54:17 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (889): Failed opening socket to (145.228.205.181:16008) with (errno=111) [Mon Aug 01 18:54:17 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Error connecting to the Tomcat process. [Mon Aug 01 18:54:17 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=2 [Mon Aug 01 18:54:17 2005] [info] jk_open_socket::jk_connect.c (444): connect to 145.228.205.181:16008 failed with errno=111 [Mon Aug 01 18:54:17 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (889): Failed opening socket to (145.228.205.181:16008) with (errno=111) [Mon Aug 01 18:54:17 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Error connecting to the Tomcat process. [Mon Aug 01 18:54:17 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=3 [Mon Aug 01 18:54:17 2005] [error] ajp_service::jk_ajp_common.c (1758): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=ASTPPRMB failed [Mon Aug 01 18:54:17 2005] [info] service::jk_lb_worker.c (662): service failed, worker ASTPPRMB is in error state [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any more (errno=-1) [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:09 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 13 is not connected any more (errno=-1) [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:53 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any more (errno=-1) [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:09 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 13 is not connected any more (errno=-1) [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:53 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:57 2005] [info] ajp_process_callback::jk_ajp_common.c (1384): Connection aborted or network problems [Mon Aug 01 18:55:57 2005] [info] ajp_service::jk_ajp_common.c (1731): Receiving from tomcat failed, because
DO NOT REPLY [Bug 9936] - http tunnel could not work with mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9936 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 15:50 --- 2+ months gone with no further comment, and specifically no experimentation with the multiple mod_jk updates that have been released since the original filing, nor a response to Mark's last post. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35957] - tomcat chooses wrong host if using mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35957. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35957 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 08:02 --- Set useIPVHosts=true on the Connector element for TC 5.5.10+ will do what you want. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 09:21 --- The servlet spec (@see section 14.2.16) is very specific that request.getServerName() must be the value of the Host header. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 09:39 --- I feel a bit misunderstood. I'm sure, the Servlet Spec is clear about HTTP-Headers. The HTTP-Headers should be transmitted unchanged to Tomcat, no dought! The thing i talk about is the AJP13 layer. Beside the headers, mod_jk sends another field. You talked about it in Bug 34648. You called it request.getLocalName() I'd like mod_jk to alway send the servername of apache's vhost no matter what UseCanonicalName is set to. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 09:48 --- Addition: I will refer to http://jakarta.apache.org/tomcat/connectors-doc/common/ajpv13a.html AJP13_FORWARD_REQUEST contains a field called server_name. I expect this to the what you referred to as request.getLocalName(). I'd like an option for mod_jk, so that field server_name always matches the ServerName of apache's vhost - which is not the case AFAIK. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 09:58 --- This field is meant to implement the new Servlet API call, nothing more, nothing less. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 10:31 --- Section 14.2.16 doesn't say anything, how this data is obtained - for example whether the result of getLocalName() is obtained by a DNS-reverselookup or by using the host-header or the name of the host like it is stored in tomcat's config. Well, there's no secure source for that _except_ a reverselookup. The host-header isn't reliable, so why should the data send by mod_jk be? Well, it isn't, since mod_jk sends the host-header if UseCanonicalName iss off and sends the ServerName of apache's vhost if UseCanonicalName is enabled. So where's you're point? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 10:36 --- Hello, thank you very much for your help so far. We have now installed newest mod_jk version (1.2.14) but the bug still exists. Does the newest version include the bugfix already ? If yes it would be very kind if you would reinvestigate: 29.07.2005 15:55:00 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:598) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:535) at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:247) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) 12 34 02 f2 02 04 00 08 48 54 54 50 2f 31 2e 31 | .4.?HTTP/1.1 00 00 2b 2f 63 6f 6d 6d 6f 6e 2f 63 75 73 74 6f | ..+/common/custo 6d 65 72 2f 62 6f 75 6e 64 61 72 79 2f 6c 6f 67 | mer/boundary/log 69 6e 5a 69 70 63 6f 64 65 52 48 2e 64 6f 00 00 | inZipcodeRH.do.. 0d 31 39 35 2e 39 33 2e 36 30 2e 31 30 35 00 ff | .195.93.60.105.? ff 00 0f 77 77 77 2e 70 72 65 6d 69 65 72 65 2e | ?..www.premiere. 64 65 00 00 50 00 00 0c a0 01 00 a4 69 6d 61 67 | de..P...?..?imag 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 2d 78 | e/gif, image/x-x 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f 6a 70 | bitmap, image/jp 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 67 2c | eg, image/pjpeg, 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 73 | application/x-s 68 6f 63 6b 77 61 76 65 2d 66 6c 61 73 68 2c 20 | hockwave-flash, 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6d 73 77 6f | application/mswo 72 64 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f | rd, application/ 76 6e 64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 | vnd.ms-excel, ap 70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 | plication/vnd.ms 2d 70 6f 77 65 72 70 6f 69 6e 74 2c 20 2a 2f 2a | -powerpoint, */* 00 a0 03 00 0d 67 7a 69 70 2c 20 64 65 66 6c 61 | .?...gzip, defla 74 65 00 a0 04 00 02 64 65 00 00 0d 43 61 63 68 | te.?...de...Cach 65 2d 43 6f 6e 74 72 6f 6c 00 00 08 6e 6f 2d 63 | e-Control...no-c 61 63 68 65 00 a0 08 00 03 31 36 31 00 a0 07 00 | ache.?...161.?.. 21 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 | !application/x-w 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 | ww-form-urlencod 65 64 00 a0 09 00 43 4a 53 45 53 53 49 4f 4e 49 | ed.?..CJSESSIONI 44 3d 33 38 44 31 41 46 42 43 32 39 33 30 30 31 | D=38D1AFBC293001 46 42 33 45 44 37 44 31 41 45 35 43 32 33 38 39 | FB3ED7D1AE5C2389 37 43 2e 41 53 54 50 50 52 4d 42 3b 20 63 6f 6f | 7C.ASTPPRMB; coo 6b 69 65 63 68 65 63 6b 3d 31 00 a0 0b 00 0f 77 | kiecheck=1.?...w 77 77 2e 70 72 65 6d 69 65 72 65 2e 64 65 00 a0 | ww.premiere.de.? 0c 00 08 6e 6f 2d 63 61 63 68 65 00 a0 0d 00 3a | ...no-cache.?..: 68 74 74 70 3a 2f 2f 77 77 77 2e 70 72 65 6d 69 | http://www.premi 65 72 65 2e 64 65 2f 63 6f 6d 6d 6f 6e 2f 63 75 | ere.de/common/cu 73 74 6f 6d 65 72 2f 62 6f 75 6e 64 61 72 79 2f | stomer/boundary/ 6c 6f 67 69 6e 52 48 2e 64 6f 00 a0 0e 00 53 4d | loginRH.do.?..SM 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 | ozilla/4.0 (comp 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 | atible; MSIE 6.0 3b 20 41 4f 4c 20 39 2e 30 3b 20 57 69 6e 64 6f | ; AOL 9.0; Windo 77 73 20 4e 54 20 35 2e 31 3b 20 53 56 31 3b 20 | ws NT 5.1; SV1; 2e 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 | .NET CLR 1.1.432 32 29 00 00 03 56 69 61 00 00 6d 48 54 54 50 2f | 2)...Via..mHTTP/ 31 2e 31 20 28 56 65 6c 6f 63 69 74 79 2f 31 2e | 1.1 (Velocity/1. 31 2e 31 20 5b 75 53 63 4d 73 20 66 20 70 20 65 | 1.1 [uScMs f p e 4e 3a 74 20 63 43 4d 70 20 73 20 5d 29 2c 20 48 | N:t cCMp s ]), H 54 54 50 2f 31 2e 30 20 66 72 72 2d 61 64 30 33 | TTP/1.0 frr-ad03 5b 43 33 35 44 33 43 36 39 5d 20 28 54 72 61 66 | [C35D3C69] (Traf 66 69 63
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 11:08 --- Hmm, This seems like you are using 'application/x-www-form-urlencoded' with GET request. Can you post the full mod_jk log from the beggining of the transaction to the end for that request. There must be some errors in ajp protocol, either setting timeout too low or forbidding post requests. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 20:33 --- You should also attach your mod_jk configuration (workers.properties and Jk-directives from httpd.conf) as well as the connector configuration from server.xml. This way we can check your timeout settings etc. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 09:11 --- Please show where the Tomcat bug is (response dumps, etc): we're not going to install the crap that is quicktime simply to investigate this. Likely the old qt release doesn't support the HTTP response that JK is sending. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35957] New: - tomcat chooses wrong host if using mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35957. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35957 Summary: tomcat chooses wrong host if using mod_jk Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, with apache's option UseCanonicalName turned on, mod_jk used to send the ServerName of the virtualhost to tomcat. Since the HTTP-Host-Header didn't change its value, i guess that the AJP protocol defines a way to send the servername _and_ the host-header. This worked fine with apache 1.3, tomcat 4.1. Now, i'm using Tomcat 5.5.9 and Apache 2.0. I have defined a VirtualHost with the ServerName abc and the ServerAlias def in Apache. In Tomcat, there's a host called abc without any alias. The UseCanonicalName-option is turned on. If i surf to http://abc/, everything works. When i try http://def/, it doesn't work. Tomcat searches for a host/alias called def which isn't there. it seems that the AJP-Connector only uses the http-host-header instead of the seperate filed defined by AJP (which i assume exists). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35959] New: - mod_jk not independant of UseCanonicalName
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35959. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35959 Summary: mod_jk not independant of UseCanonicalName Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, people must enable apache's UseCanonicalName-option to make sure, that mod_jk sends the servername (and not the http-hosh-header value) to tomcat. It would be nice to leave UseCanonicalName off and instead set a mod_jk specific option for it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:AJP |Connector:HTTP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|All |Windows XP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.14.1 Released?
Was 1.2.14.1 ever officially released? If not, will it be soon? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? Well, it was voted as stable, so we only need announcement. If not, will it be soon? Think that Jean-Frederic will make official announcement. OTOH it might be that the heat wave in Spain put him in some deep shade :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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: mod_jk 1.2.14.1 Released?
Where are the zip/tar balls of the sources for those wishing to jump the gun? [I assume they're not changing at this point...] Jean-frederic Clere wrote: Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Where are the zip/tar balls of the sources for those wishing to jump the gun? [I assume they're not changing at this point...] Just try http://jakarta.apache.org/site/downloads/downloads_tomcat-connectors.cgi Jean-frederic Clere wrote: Jess Holle wrote: Was 1.2.14.1 ever officially released? I have to annonce it ;-) If not, will it be soon? -- Jess Holle - 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] - 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: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? 1.2.14.1 is only a repackaging of 1.2.14. If not, will it be soon? -- Jess Holle - 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]
[ANN] Apache Tomcat mod_jk 1.2.14 Web Server Connector released
The Apache Tomcat team is pleased to announce the release of version 1.2.14 of the Apache Tomcat mod_jk web server connector. Tomcat is the reference implementation of a web application server which implements the Java Servlet and JavaServer Pages specifications. mod_jk is a connector which allows a web server such as Apache HTTPD to act as a front end to the Tomcat web application server. This version fixes a number of minor bugs. See http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: (they are named jakarta-tomcat-connectors-1.2.14.1-src.tar.gz and jakarta-tomcat-connectors-1.2.14.1-src.zip) http://jakarta.apache.org/site/sourceindex.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://jakarta.apache.org/site/binindex.cgi Documentation for using mod_jk with Tomcat 3.3, 4.1, 5.0 and 5.5 can be found at: http://jakarta.apache.org/tomcat/ The Apache Tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary streaming / content-type problem with mod_jk ?
Thanks for your answer Henri :) I agree with you, finally I don't think the problem comes from mod_jk It may be Apache (using mod_jk and Tomcat) like described by Stuart Hynd in his post on this page : http://www.junlu.com/msg/107218.html Or, perhaps, QuickTime 6 which is more weaker than QT7 which doesn't care about the thing which makes the problem (and I would like to know where this thing comes from). But the incredible thing is that, using this : http://localhost:8080/my_test/BinaryStreamingit works perfectly on QT6 (without the 8080 port, the latence problem appears - QT6 or the servlet or Apache, is waiting for the video file entirely created before starting to play it)... Any other suggestions or opinions about this mystery ? :) Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com Le 20 juil. 05, à 23:24, Henri Gomez a écrit : not true, mod_jk didn't change the mime type provided by servlet output. I'm doing it on productions servers to handle on the fly generated PDFs 2005/7/20, Jérôme Chauvin [EMAIL PROTECTED]: Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary streaming / content-type problem with mod_jk ?
Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com
Re: binary streaming / content-type problem with mod_jk ?
not true, mod_jk didn't change the mime type provided by servlet output. I'm doing it on productions servers to handle on the fly generated PDFs 2005/7/20, Jérôme Chauvin [EMAIL PROTECTED]: Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
inprocess Tomcat/apache via mod_jk
Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] New: - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 Summary: binary streaming / content-type problem with mod_jk ? Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Keywords: APIBug, FAQ Severity: major Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
binary streaming / content-type problem with mod_jk ?
Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com
Re: binary streaming / content-type problem with mod_jk
Hi all ! I've developed a servlet which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it. (- like it does with QT7 and QT6 with :8080 or without :8080 and when I use QT7). I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) Thanks in advance. Regards, Jérôme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Thank you Bill! I will happily continue to the other list, at least I know my logging is set to capture the correct events and I have a clue as to what might be the cause. -Collin Bill Barker wrote: Collin McClendon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've enabled the logging per your suggestions, and not having heard back in a bit, I was hoping someone could clue in to why I get plenty of FINE messages for org.apache.jk.common.MsgAjp, but no longer get SEVERE messages. I'm also trying consistently crash mod_jk, but not having much luck, OpenCMS is the webapp invovled here, I haven't gotten any feed back from their dev list. You get plenty of FINE messages, since those are primarily for developers trying to understand the protocol traffic ;-). You haven't gotten SEVERE messages for the simple reason that none of them have been triggered. (as an aside, MsgAjp only currently logs at either SEVERE or FINE). As Remy mentions below, the most likely problems are with a 'Set-Cookie' header (with a ridiculously big cookie), or with a 'Location' header (from a sendRedirect with a ridiculously big query-string). Personally, I'm betting on the second (since the Response body was less than 8K). In any case, this is starting to border on [OT] for this list, and may be better continued on [EMAIL PROTECTED] Don't worry, both Remy an me lurk there ;-). Thanks, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - 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: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)
Bill, so far all I've gotten out of FINE logging is a lot of these: Jul 14, 2005 1:44:36 PM org.apache.jk.common.MsgAjp processHeader FINE: Received 560 18 We have been monitoring the server, and even though I got no SEVERE messages, it appears to have hung as before. Am I excluding SEVERE logging messages when I specify FINE as logging such as this? (I'm quite positive this is an inclusive logging setting) org.apache.jk.common.MsgAjp.level = FINEST org.apache.jk.server.JkMain.level = FINEST I any case, I have yet to catch the mod_jk in the act of doing a buffer overflow since changing the logging parameters. Thanks for any help you can give, Collin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
I've enabled the logging per your suggestions, and not having heard back in a bit, I was hoping someone could clue in to why I get plenty of FINE messages for org.apache.jk.common.MsgAjp, but no longer get SEVERE messages. I'm also trying consistently crash mod_jk, but not having much luck, OpenCMS is the webapp invovled here, I haven't gotten any feed back from their dev list. Thanks, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Collin McClendon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've enabled the logging per your suggestions, and not having heard back in a bit, I was hoping someone could clue in to why I get plenty of FINE messages for org.apache.jk.common.MsgAjp, but no longer get SEVERE messages. I'm also trying consistently crash mod_jk, but not having much luck, OpenCMS is the webapp invovled here, I haven't gotten any feed back from their dev list. You get plenty of FINE messages, since those are primarily for developers trying to understand the protocol traffic ;-). You haven't gotten SEVERE messages for the simple reason that none of them have been triggered. (as an aside, MsgAjp only currently logs at either SEVERE or FINE). As Remy mentions below, the most likely problems are with a 'Set-Cookie' header (with a ridiculously big cookie), or with a 'Location' header (from a sendRedirect with a ridiculously big query-string). Personally, I'm betting on the second (since the Response body was less than 8K). In any case, this is starting to border on [OT] for this list, and may be better continued on [EMAIL PROTECTED] Don't worry, both Remy an me lurk there ;-). Thanks, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)
Bill, Thanks again for this tip. After reading the document to my best ability, I added this line to the end of /usr/local/tomcat/common/classes/logging.propeties : org.apache.jk.common.MsgAjp = ALL I got as a result what seemed like no logging at all for this class. I am setting it to DEBUG now to see what happens, but am I doing this correctly at all? Thanks for your help, Collin Bill Barker wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)
That's for log4j. For Juli, you want FINE (or FINEST). - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, July 13, 2005 8:15 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging) Bill, Thanks again for this tip. After reading the document to my best ability, I added this line to the end of /usr/local/tomcat/common/classes/logging.propeties : org.apache.jk.common.MsgAjp = ALL I got as a result what seemed like no logging at all for this class. I am setting it to DEBUG now to see what happens, but am I doing this correctly at all? Thanks for your help, Collin Bill Barker wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)
Thanks, I didn't have my head screwed on right there. I see now after re-reading the documentation, I have to use the right keyword and I wasn't adding .level = at the end of the class name. Thanks so much for your help, I hope to have a crash to show logged in detail. If you or someone would glance at it, that would be of great help to me. Thanks, Collin Bill Barker wrote: That's for log4j. For Juli, you want FINE (or FINEST). - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Wednesday, July 13, 2005 8:15 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging) Bill, Thanks again for this tip. After reading the document to my best ability, I added this line to the end of /usr/local/tomcat/common/classes/logging.propeties : org.apache.jk.common.MsgAjp = ALL I got as a result what seemed like no logging at all for this class. I am setting it to DEBUG now to see what happens, but am I doing this correctly at all? Thanks for your help, Collin Bill Barker wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon Corporation [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Hello all, I was kindly redirected to this list by Mr. Turk, the author of mod_jk. He suggested that someone here might be able to determine why when using mod_jk and tomcat and apache, I am getting buffer overflow messages in the catalina.out logfile. This tends to happen after 8 hours or so, and after users have been visiting the website, not when idle. I have the relevant portion of the log here: My mod_jk as stated is 1.2.10, tomcat is 5.5.9, and apache is 2.0.52-12 (RedHat 4.0ES build). SEVERE: Buffer overflow: buffer.len=8192 pos=70 data=18568 Jun 28, 2005 6:16:21 PM org.apache.jk.common.MsgAjp cpBytes SEVERE: Overflow java.lang.Throwable at org.apache.jk.common.MsgAjp.cpBytes(MsgAjp.java:172) at org.apache.jk.common.MsgAjp.appendByteChunk(MsgAjp.java:146) at org.apache.jk.common.MsgAjp.appendBytes(MsgAjp.java:132) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:407) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:425) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:278) at org.apache.catalina.connector.Response.finishResponse(Response.java:473) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) I'd appreciate any help you can offer, Thank you, Collin McClendon -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 9:38 AM Subject: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Hello all, I was kindly redirected to this list by Mr. Turk, the author of mod_jk. He suggested that someone here might be able to determine why when using mod_jk and tomcat and apache, I am getting buffer overflow messages in the catalina.out logfile. This tends to happen after 8 hours or so, and after users have been visiting the website, not when idle. I have the relevant portion of the log here: My mod_jk as stated is 1.2.10, tomcat is 5.5.9, and apache is 2.0.52-12 (RedHat 4.0ES build). SEVERE: Buffer overflow: buffer.len=8192 pos=70 data=18568 Jun 28, 2005 6:16:21 PM org.apache.jk.common.MsgAjp cpBytes SEVERE: Overflow java.lang.Throwable at org.apache.jk.common.MsgAjp.cpBytes(MsgAjp.java:172) at org.apache.jk.common.MsgAjp.appendByteChunk(MsgAjp.java:146) at org.apache.jk.common.MsgAjp.appendBytes(MsgAjp.java:132) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:407) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:425) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:278) at org.apache.catalina.connector.Response.finishResponse(Response.java:473) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Thread.java:595) I'd appreciate any help you can offer, Thank you, Collin McClendon -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
