Re: BUG? - Mysterious "chunked" behavior
> - Are the results I get from those 3 examples > "expected" ? I actually tried to reproduce your experience. wget, FireFox etc. - all these HTTP-clients don't have any problems with tomcat. What HTTP-client are you using? Is it self-written maybe? signature.asc Description: OpenPGP digital signature
Re: AJP flush packets (tomcat 6.0.10 and mod_jk 1.2.21)
>> Any ideas? > > Any ideas why tomcat 6.0.10 doesn't send flush packets? I should see > them in mod_jk's log, right? (JkLogLevel is debug) The explanation is: Is the JNI APR stuff is installed, Tomcat will use org.apache.coyote.ajp.AjpAprProtocol. Not the JNI APR stuff is NOT installed, Tomcat does NOT use the org.apache.coyote.ajp.AjpProtocol, which would support flush packets. Instead, it uses org.apache.jk.server.JkCoyoteHandler which does NOT support flush packets :-(( signature.asc Description: OpenPGP digital signature
Re: AJP flush packets (tomcat 6.0.10 and mod_jk 1.2.21)
> in mod_jk's logfile, i don't see any flush-packets (= write packet of
> length 0) and so apache doesn't do flushing either.
>
> Of course the old "JkOption +FlushPackets" works.
> But the new flush-packets would be much nicer.
>
> I think, that i might have to enable the flush-packets thing within tomcat.
>
> Any ideas?
I was using this JSP-page:
<[EMAIL PROTECTED] contentType="text/plain; charset=utf-8" %>
<%
out.println("test1");
out.flush();
Thread.sleep(5000);
out.println("test2");
%>
And that's the corresponding part of mod_jk.log:
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_connection_tcp_send_message::jk_ajp_common.c (892): enter
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): sending to ajp13
pos=4 len=113 max=8192
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 12 34 00
6D 02 02 00 08 48 54 54 50 2F 31 2E 30 - .4.mHTTP/1.0
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 001000 00 09
2F 74 65 73 74 2E 6A 73 70 00 00 09 31 - .../test.jsp...1
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 002032 37 2E
30 2E 30 2E 31 00 FF FF 00 05 68 6F 73 - 27.0.0.1.hos
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 003074 31 00
00 50 00 00 05 A0 0E 00 0B 57 67 65 74 - t1..P...Wget
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 00402F 31 2E
31 30 2E 32 00 A0 01 00 03 2A 2F 2A 00 - /1.10.2.*/*.
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 0050A0 0B 00
06 61 6C 69 61 73 31 00 A0 06 00 0A 4B - alias1.K
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 006065 65 70
2D 41 6C 69 76 65 00 A0 08 00 01 30 00 - eep-Alive.0.
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (896): 0070FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 -
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_connection_tcp_send_message::jk_ajp_common.c (913): exit
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_send_request::jk_ajp_common.c (1287): request body to send 0 -
request body to resend 0
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_send_request::jk_ajp_common.c (1383): exit
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_get_reply::jk_ajp_common.c (1549): enter
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (938): enter
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): received from
ajp13 pos=0 len=119 max=8192
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 04 00 C8
00 02 4F 4B 00 00 02 00 0A 53 65 74 2D - .OK.Set-
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 001043 6F 6F
6B 69 65 00 00 33 4A 53 45 53 53 49 4F - Cookie..3JSESSIO
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 00204E 49 44
3D 35 42 30 30 44 42 35 37 38 37 32 32 - NID=5B00DB578722
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 003030 44 44
42 30 37 41 31 33 43 39 30 44 43 37 39 - 0DDB07A13C90DC79
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 004031 37 34
33 3B 20 50 61 74 68 3D 2F 00 00 0C 43 - 1743;.Path=/...C
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 00506F 6E 74
65 6E 74 2D 54 79 70 65 00 00 18 74 65 - ontent-Type...te
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 006078 74 2F
70 6C 61 69 6E 3B 63 68 61 72 73 65 74 - xt/plain;charset
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 00703D 75 74
66 2D 38 00 00 00 00 00 00 00 00 00 00 - =utf-8..
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (1049): exit
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_process_callback::jk_ajp_common.c (1398): enter
[Tue Mar 06 00:22:19 2007] [23687:63152] [trace]
ajp_unmarshal_response::jk_ajp_common.c (586): enter
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_unmarshal_response::jk_ajp_common.c (603): status = 200
[Tue Mar 06 00:22:19 2007] [23687:63152] [debug]
ajp_unmarshal_response::jk_ajp_common.c (610): Number of headers is = 2
[Tue Mar 06 00:22:19
Re: AJP flush packets (tomcat 6.0.10 and mod_jk 1.2.21)
> Any ideas? Any ideas why tomcat 6.0.10 doesn't send flush packets? I should see them in mod_jk's log, right? (JkLogLevel is debug) signature.asc Description: OpenPGP digital signature
AJP flush packets (tomcat 6.0.10 and mod_jk 1.2.21)
Hi, in mod_jk's logfile, i don't see any flush-packets (= write packet of length 0) and so apache doesn't do flushing either. Of course the old "JkOption +FlushPackets" works. But the new flush-packets would be much nicer. I think, that i might have to enable the flush-packets thing within tomcat. Any ideas? Thanks, Sven signature.asc Description: OpenPGP digital signature
Re: charset for querystring decoding
> Oh! This sounds, like it's a "bug" and like it might be fixed in tomcat > 6, for example. Now i'm curious, and will test tomcat 6 ... Ahh damn - i didn't read properly. It's the old story: it's NOT a bug, it's a feature ;-) signature.asc Description: OpenPGP digital signature
Re: charset for querystring decoding
>> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sven Köhler >> Subject: charset for querystring decoding >> >> And if you know: what's the reason, that the charset is not >> configurable via request.setCharacterEncoding() ? > > Might want to check out the FAQ entry on the topic: > http://tomcat.apache.org/faq/misc.html#tomcat5CharEncoding Oh! This sounds, like it's a "bug" and like it might be fixed in tomcat 6, for example. Now i'm curious, and will test tomcat 6 ... signature.asc Description: OpenPGP digital signature
charset for querystring decoding
Hi, as far as i remember, tomcat always uses a default-charset for decoding the querystring. A call to request.setCharacterEncoding() only matters for decoding POST-data. Somewhere, this charset can be changed - for example to UTF-8. Where can it be changed? And if you know: what's the reason, that the charset is not configurable via request.setCharacterEncoding() ? Thanks, Sven signature.asc Description: OpenPGP digital signature
Re: out.flush() not working with mod_jk
Sven Köhler schrieb: >> Use mod_jk 1.2.15 and add: >> JkOptions +FlushPackets > > That did the trick. > > But shouldn't this be enabled by default? Why i say that: - mod_jk shouldn't cause too many differences to using plain tomcat - how big is this mod_jk/apache-internal buffer that is not flushed? because the response that was buffered in my case, was many kilobytes big and i can't see any obvious reason for that buffering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out.flush() not working with mod_jk
> Use mod_jk 1.2.15 and add: > JkOptions +FlushPackets That did the trick. But shouldn't this be enabled by default? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out.flush() not working with mod_jk
> If i load the page with FireFox directly by connecting to my Tomcat on > port 8080, it works fine. But if i load the page via apache/mod_jk on > port 80 it doesn't work. By saying "it doesn't work" i mean, that the whole content is delayed by 3 seconds - so the flush() actually has no effect. The string "this should appear immediatly" is stuck somewhere in some buffer and is not delivered to the browser even though i call flush(). Using tomcat directly, it works fine. The first half of the content is displayed immediatly, the second half is delayed by 3 seconds. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
out.flush() not working with mod_jk
Hi,
take a look at the following JSP-page:
<[EMAIL PROTECTED] contentType="text/plain"%>
<%
out.println("this should appear immediatly");
out.flush();
Thread.sleep(3000);
out.println("this should appear after 3 seconds");
%>
If i load the page with FireFox directly by connecting to my Tomcat on
port 8080, it works fine. But if i load the page via apache/mod_jk on
port 80 it doesn't work.
mod_jk connects to the tomcat that also listenes on port 8080.
So something's pretty wrong here, don't you think?
Is it a bug? Or a configuration issue?
Greetings
Sven
P.S.: Tomcat 5.5.15, Apache 2.0.55, mod_jk 1.2.15
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk errors - are these normal?
> The system seems to work fine from a user's > perspective, but we still occasionally get these: > > [Wed Mar 01 20:00:42 2006] [error] > ajp_connection_tcp_get_message::jk_ajp_common.c (961): > Can't receive the response message from tomcat, > network problems or tomcat is down (10.0.0.9:8009), > err=-113 > [Wed Mar 01 20:00:42 2006] [error] > ajp_get_reply::jk_ajp_common.c (1503): Tomcat is down > or refused connection. No response has been sent to > the client (yet) > [Wed Mar 01 20:00:42 2006] [info] > ajp_service::jk_ajp_common.c (1721): Receiving from > tomcat failed, recoverable operation attempt=0 > [Wed Mar 01 20:00:42 2006] [info] > ajp_service::jk_ajp_common.c (1749): Sending request > to tomcat failed, recoverable operation attempt=1 > > For what it's worth, we have other completely separate > system setups using mod_jk2, and they also all seem to > get occasional ajp errors. This is our first setup > using mod_jk, and we are assuming these errors are a > bad thing. I always had those errors. I did anything i could do - change timeouts, change backlog, change this, change that - whatever - these errors remain. Just make sure, that the tomcat allows as much or more ajp-connctions, than there will be apache-processes/threads. I think the programmers have given up on solving this - whatever the problem is. AFAIK, mod_jk prints that error-messages to the log and then tries another connect which usually works. Actually i hear the developers say: "this is not a problem" - or something like that. Well, no comment on that ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setCharacterEncoding() für POST-data i n JSP
> But there is something i should first look at before i further complain: > some ServletFilters. Maybe one called getParameter() which could be the > cause. Yes, one of the servletfilters calls getParameter() on the request. Sorry for taking your time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setCharacterEncoding() für POST-data i n JSP
>> The above JSP-page will not work properly. The POST-data is decoded with >> ISO-8859-1 instead of UTF-8 in Tomcat 5.5. > Works for me using the latest 5.5 from svn. interesting! (and at least, there's some hope for me :-) ) > It would be a bug but since it is working for me it looks like a > configuration issue on your system. i will try to look at it. > What Tomcat version? I haven't checked the releaes notes but there may > have been an issue with an earlier version. 5.5.15 > Is the browser displaying the page as UTF-8? yes > Are you using the RequestDumperValve? This ignores any encoding and > forces ISO-8859-1 to be used for all parameters. afaik: no But there is something i should first look at before i further complain: some ServletFilters. Maybe one called getParameter() which could be the cause. Greetings Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
setCharacterEncoding() für POST-data in JSP
Hi,
<[EMAIL PROTECTED] contentType="text/html; charset=UTF8"%>
<%
request.setCharacterEncoding("UTF-8");
%>
Test: <%=request.getParameter("text")%>
The above JSP-page will not work properly. The POST-data is decoded with
ISO-8859-1 instead of UTF-8 in Tomcat 5.5.
Is this a bug or a feature?
If it's a bug - well - then a fix would be nice.
If it's a feature - well - what's the reason for this?
Thanks
Sven
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
