Re: bad content type mod_jk 1.2.27
Hi all, I have tried with apache 2.0.63 and modjk 1.2.6 and the result is the same. Someone can help me to identify which tomcat class set the content type about a request? I want to add a log on source in order to understand why the same request have two different response (content type text/html or bad text/plain) with random frequency. Many thanks, Marco marcobalc wrote: Hi, I attach the ajp log for two cases: one ok and one ko. http://www.nabble.com/file/p20971586/headers_ok_and_ko.txt headers_ok_and_ko.txt I'm going crazy in order to understand when tomcat lost headers... :( Many thanks, regards Marco marcobalc wrote: Hi, an other strange behavior is that some times when I reboot tomcat and I refresh browser while I wait that tomcat is up and runnig I see the normal error page displayed when the tomcat is not yet started but also in this case I see the source html code on the browser instead of HTML interpreted. This is the source the was displayed !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later./p /body/html and the response header visible on firefox Date: Thu, 11 Dec 2008 15:58:32 GMT Server: Apache/2.2.9 (Unix) mod_jk/1.2.27 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain 200 OK best regards, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, now I have the stacktrace but the problem is that the stack do not involve my classes :| java.lang.Throwable: Stack Info at org.apache.jk.core.MsgContext.action(MsgContext.java:263) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) Any idea? i'm going crazy on this problem :( Could you please post a more complete part of the log file, when used with the increased log level I posted to you earlier in this thread. With the more complete log we will have timestamps, and we can also see the second commit etc. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p21013440.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: bad content type mod_jk 1.2.27
From: marcobalc [mailto:m.bal...@i-contact.it] Subject: Re: bad content type mod_jk 1.2.27 Someone can help me to identify which tomcat class set the content type about a request? For static content, it's org.apache.catalina.servlets.DefaultServlet. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: bad content type mod_jk 1.2.27
Hi, I attach the ajp log for two cases: one ok and one ko. http://www.nabble.com/file/p20971586/headers_ok_and_ko.txt headers_ok_and_ko.txt I'm going crazy in order to understand when tomcat lost headers... :( Many thanks, regards Marco marcobalc wrote: Hi, an other strange behavior is that some times when I reboot tomcat and I refresh browser while I wait that tomcat is up and runnig I see the normal error page displayed when the tomcat is not yet started but also in this case I see the source html code on the browser instead of HTML interpreted. This is the source the was displayed !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later./p /body/html and the response header visible on firefox Date: Thu, 11 Dec 2008 15:58:32 GMT Server: Apache/2.2.9 (Unix) mod_jk/1.2.27 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain 200 OK best regards, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, now I have the stacktrace but the problem is that the stack do not involve my classes :| java.lang.Throwable: Stack Info at org.apache.jk.core.MsgContext.action(MsgContext.java:263) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) Any idea? i'm going crazy on this problem :( Could you please post a more complete part of the log file, when used with the increased log level I posted to you earlier in this thread. With the more complete log we will have timestamps, and we can also see the second commit etc. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20971586.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: bad content type mod_jk 1.2.27
Hi, in effect in the case of Excel download I set Header after I send the output stream because I do not know that tomcat start to flush before controller return. Now I have fixed this. But I don't understand why I have mime type problem with other normal page. An other repetitive case with same problem , is a controller where I upload and read an excel and I return to a normal page: the page source is printed on screen. I attach a souce fragment, my application log that show the output point CI SONO DEGLI ERRORI NELL'INPUT.. and catalina.out that contains modjk logs. http://www.nabble.com/file/p20957484/source.txt source.txt http://www.nabble.com/file/p20957484/myApplication.log myApplication.log http://www.nabble.com/file/p20957484/catalina.txt catalina.txt Thanks, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, now I have the stacktrace but the problem is that the stack do not involve my classes :| java.lang.Throwable: Stack Info at org.apache.jk.core.MsgContext.action(MsgContext.java:263) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) Any idea? i'm going crazy on this problem :( Could you please post a more complete part of the log file, when used with the increased log level I posted to you earlier in this thread. With the more complete log we will have timestamps, and we can also see the second commit etc. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20957484.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi, an other strange behavior is that some times when I reboot tomcat and I refresh browser while I wait that tomcat is up and runnig I see the normal error page displayed when the tomcat is not yet started but also in this case I see the source html code on the browser instead of HTML interpreted. This is the source the was displayed !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later./p /body/html and the response header visible on firefox Date: Thu, 11 Dec 2008 15:58:32 GMT Server: Apache/2.2.9 (Unix) mod_jk/1.2.27 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain 200 OK best regards, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, now I have the stacktrace but the problem is that the stack do not involve my classes :| java.lang.Throwable: Stack Info at org.apache.jk.core.MsgContext.action(MsgContext.java:263) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) Any idea? i'm going crazy on this problem :( Could you please post a more complete part of the log file, when used with the increased log level I posted to you earlier in this thread. With the more complete log we will have timestamps, and we can also see the second commit etc. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20958246.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
marcobalc schrieb: Hi, I have tested an other controller that return to a jsp with simple HTML. The last rows of this controller are ... log.debug(isCommitted?? +response.isCommitted()); Map m = new HashMap(); m.put(tutteListe, tutteListe); return new ModelAndView(getInputView(), m); I have invoked 5 times the same controller and the first 4 times the response is ok and the last call resulted on text/plain content type and in effect isCommitted return true. 2008-12-08 22:54:20,506 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:25,104 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:25,538 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:27,240 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:28,781 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? true Any idea about a possible cause of this issue? Not really. But since we know, we can detect the commit in class org.apache.jk.core.MsgContext, method action(), you can add there the output of a stack. So each time some code calls commit, you can see exactly where the call comes from. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi,
do you mean that I need to rebuild tomcat with a new log?
At the moment I have reproduced the problem with an MultiActionController
with this default method
public ModelAndView init(HttpServletRequest request, HttpServletResponse
response, RegistrationsSearch command)
throws Exception {
log.debug(isCommitted ?? +response.isCommitted());
return new ModelAndView(getInputView());
}
if I call repeatedly this method now and then the log
log.debug(isCommitted ?? +response.isCommitted());
write true, so the response was already committed.
Regards,
Marco
Rainer Jung-3 wrote:
marcobalc schrieb:
Hi,
I have tested an other controller that return to a jsp with simple HTML.
The last rows of this controller are
...
log.debug(isCommitted?? +response.isCommitted());
Map m = new HashMap();
m.put(tutteListe, tutteListe);
return new ModelAndView(getInputView(), m);
I have invoked 5 times the same controller and the first 4 times the
response is ok and the last call resulted on text/plain content type and
in
effect isCommitted return true.
2008-12-08 22:54:20,506 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:25,104 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:25,538 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:27,240 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:28,781 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? true
Any idea about a possible cause of this issue?
Not really. But since we know, we can detect the commit in class
org.apache.jk.core.MsgContext, method action(), you can add there the
output of a stack. So each time some code calls commit, you can see
exactly where the call comes from.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20913205.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Rainer thanks for support.
Now I have build tomcat but is not clear for me what you mean with output
of a stack
Could you seggest wath line write.
(I think the line should be added in this block of code)
if( actionCode==ActionCode.ACTION_COMMIT ) {
...
...
}
Rainer Jung-3 wrote:
marcobalc schrieb:
Hi,
I have tested an other controller that return to a jsp with simple HTML.
The last rows of this controller are
...
log.debug(isCommitted?? +response.isCommitted());
Map m = new HashMap();
m.put(tutteListe, tutteListe);
return new ModelAndView(getInputView(), m);
I have invoked 5 times the same controller and the first 4 times the
response is ok and the last call resulted on text/plain content type and
in
effect isCommitted return true.
2008-12-08 22:54:20,506 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:25,104 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:25,538 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:27,240 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? false
2008-12-08 22:54:28,781 DEBUG
[it.urlandus.events.app.web.controller.frontend.RegistrantsList] -
isCommitted?? true
Any idea about a possible cause of this issue?
Not really. But since we know, we can detect the commit in class
org.apache.jk.core.MsgContext, method action(), you can add there the
output of a stack. So each time some code calls commit, you can see
exactly where the call comes from.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20914634.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
marcobalc schrieb: do you mean that I need to rebuild tomcat with a new log? Yes, but for Tomcat 6 that's really easy to do. Download the source, have Java 5 and ant ready, and call ant download and ant. Then you should be able to already find the compiled classes. You only need to add log statements which output the stack at the moment of the commit action at the start of the action() method in the class I mentioned. Then you'll know precisely which part of the code does the unexpected commit. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
marcobalc schrieb:
Rainer thanks for support.
Now I have build tomcat but is not clear for me what you mean with output
of a stack
Could you seggest wath line write.
(I think the line should be added in this block of code)
if( actionCode==ActionCode.ACTION_COMMIT ) {
...
...
}
log.error(Stack at COMMIT:, new Throwable(Stack Info));
should be enough. If you want the info in textual form to do something
else with it, you could do:
import java.io.PrintWriter;
import java.io.StringWriter;
Throwable th = new Throwable(Stack Info);
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
th.printStackTrace(pw);
pw.close();
String result = sw.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi,
now I have the stacktrace but the problem is that the stack do not involve
my classes :|
java.lang.Throwable: Stack Info
at org.apache.jk.core.MsgContext.action(MsgContext.java:263)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:380)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
at
org.apache.catalina.connector.Response.finishResponse(Response.java:492)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
Any idea? i'm going crazy on this problem :(
best regards,
Marco
Rainer Jung-3 wrote:
marcobalc schrieb:
Rainer thanks for support.
Now I have build tomcat but is not clear for me what you mean with
output
of a stack
Could you seggest wath line write.
(I think the line should be added in this block of code)
if( actionCode==ActionCode.ACTION_COMMIT ) {
...
...
}
log.error(Stack at COMMIT:, new Throwable(Stack Info));
should be enough. If you want the info in textual form to do something
else with it, you could do:
import java.io.PrintWriter;
import java.io.StringWriter;
Throwable th = new Throwable(Stack Info);
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
th.printStackTrace(pw);
pw.close();
String result = sw.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20918077.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi,
I have found one other interesting information: If the Excel is very small
the problem do not appear. If the Excel is more big (some kb) the stack
trace with the error appear.
I think that should be a buffer problem but I don't know how to locate the
root cause.
regards
Marco
marcobalc wrote:
Hi,
now I have the stacktrace but the problem is that the stack do not involve
my classes :|
java.lang.Throwable: Stack Info
at org.apache.jk.core.MsgContext.action(MsgContext.java:263)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:380)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
at
org.apache.catalina.connector.Response.finishResponse(Response.java:492)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
Any idea? i'm going crazy on this problem :(
best regards,
Marco
Rainer Jung-3 wrote:
marcobalc schrieb:
Rainer thanks for support.
Now I have build tomcat but is not clear for me what you mean with
output
of a stack
Could you seggest wath line write.
(I think the line should be added in this block of code)
if( actionCode==ActionCode.ACTION_COMMIT ) {
...
...
}
log.error(Stack at COMMIT:, new Throwable(Stack Info));
should be enough. If you want the info in textual form to do something
else with it, you could do:
import java.io.PrintWriter;
import java.io.StringWriter;
Throwable th = new Throwable(Stack Info);
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
th.printStackTrace(pw);
pw.close();
String result = sw.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20918425.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi Marco, marcobalc schrieb: Hi, now I have the stacktrace but the problem is that the stack do not involve my classes :| java.lang.Throwable: Stack Info at org.apache.jk.core.MsgContext.action(MsgContext.java:263) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) Any idea? i'm going crazy on this problem :( Could you please post a more complete part of the log file, when used with the increased log level I posted to you earlier in this thread. With the more complete log we will have timestamps, and we can also see the second commit etc. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco, marcobalc wrote: I have found one other interesting information: If the Excel is very small the problem do not appear. If the Excel is more big (some kb) the stack trace with the error appear. I think the problem might be that you are generating the Excel file and sending it to the output stream /before/ setting the headers. Is that true? If you could post more of your action code, it would be helpful to see what you are doing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+9B0ACgkQ9CaO5/Lv0PBWbgCfa7KqutG8ZOFK4HSgDZpq9ZfQ ZXYAn2Dn/r0KCP/o4hTWDHlx4k87Aumu =Iwzm -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bad content type mod_jk 1.2.27
i all, I have a problem with tomcat 6.0.18 Apache/2.2.9 mod_jk/1.2.27 Some times the content-type sent from my tomcat is ignored and the response have content type text/plain. For this reason some servlet that should return excel file and set the contentType(application/excel) have bad beahviour on the browser: the file was not recognized as excel but as binary generic file. The problem is present also for normal html page: some times the HTML source are displayed on the browser. I have found that mod_jk 1.26 was affected by this problem but the problem was fixed http://markmail.org/message/jk7ssoyhuadvjvh3 This is my configuration: #Load mod_jk module LoadModule jk_module modules/mod_jk.so #Where to find workers.properties JkWorkersFile conf/workers.properties #Where to put jk logs JkLogFile logs/mod_jk.log #Set the jk log level JkLogLevel debug # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] #JkOptions indicate to send SSL KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +FlushHeader #JkRequestLogFormat set the request format #JkRequestLogFormat %w %V %T # Send /ROOT to worker named “myworker” #JkMount /* myworker Someone can help me ? Many thanks, regards Marco -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20892496.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi, no FlushHeader option is not vital: I have tried this option in order to solve the problem. With o without this option I have the same problem. I attach one request for Excel that return the bad result http://www.nabble.com/file/p20893729/logModJk.txt logModJk.txt Many thanks, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: i all, I have a problem with tomcat 6.0.18 Apache/2.2.9 mod_jk/1.2.27 Some times the content-type sent from my tomcat is ignored and the response have content type text/plain. For this reason some servlet that should return excel file and set the contentType(application/excel) have bad beahviour on the browser: the file was not recognized as excel but as binary generic file. The problem is present also for normal html page: some times the HTML source are displayed on the browser. I have found that mod_jk 1.26 was affected by this problem but the problem was fixed http://markmail.org/message/jk7ssoyhuadvjvh3 This is my configuration: #Load mod_jk module LoadModule jk_module modules/mod_jk.so #Where to find workers.properties JkWorkersFile conf/workers.properties #Where to put jk logs JkLogFile logs/mod_jk.log #Set the jk log level JkLogLevel debug # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] #JkOptions indicate to send SSL KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +FlushHeader #JkRequestLogFormat set the request format #JkRequestLogFormat %w %V %T # Send /ROOT to worker named “myworker” #JkMount /* myworker Is the FlushHeader option vital for your application? Can you check, if it also occurs without that option? Since you have log level debug: do you have a JK log file which contains at least one request, which resulted in this wrong behaviour? How easy can you reproduce? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20893729.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi Marco, marcobalc schrieb: i all, I have a problem with tomcat 6.0.18 Apache/2.2.9 mod_jk/1.2.27 Some times the content-type sent from my tomcat is ignored and the response have content type text/plain. For this reason some servlet that should return excel file and set the contentType(application/excel) have bad beahviour on the browser: the file was not recognized as excel but as binary generic file. The problem is present also for normal html page: some times the HTML source are displayed on the browser. I have found that mod_jk 1.26 was affected by this problem but the problem was fixed http://markmail.org/message/jk7ssoyhuadvjvh3 This is my configuration: #Load mod_jk module LoadModule jk_module modules/mod_jk.so #Where to find workers.properties JkWorkersFile conf/workers.properties #Where to put jk logs JkLogFile logs/mod_jk.log #Set the jk log level JkLogLevel debug # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] #JkOptions indicate to send SSL KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +FlushHeader #JkRequestLogFormat set the request format #JkRequestLogFormat %w %V %T # Send /ROOT to worker named “myworker” #JkMount /* myworker Is the FlushHeader option vital for your application? Can you check, if it also occurs without that option? Since you have log level debug: do you have a JK log file which contains at least one request, which resulted in this wrong behaviour? How easy can you reproduce? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
marcobalc schrieb: Hi, no FlushHeader option is not vital: I have tried this option in order to solve the problem. With o without this option I have the same problem. I attach one request for Excel that return the bad result http://www.nabble.com/file/p20893729/logModJk.txt logModJk.txt This seems to be an issue with the backend, most likely with the webapp. It is *not* sending any Header to mod_jk, so the response gets the default. Is this Excel sheet generated by code (servlet), or is it simply a static file in your webapp? The URL ends in the suffix .ic, so if it is a static file, I expect that neither in your web.xml (Tomcat) nor in the Apache config there is an entry for .ic=application/excel. Regards, Rainer Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: i all, I have a problem with tomcat 6.0.18 Apache/2.2.9 mod_jk/1.2.27 Some times the content-type sent from my tomcat is ignored and the response have content type text/plain. For this reason some servlet that should return excel file and set the contentType(application/excel) have bad beahviour on the browser: the file was not recognized as excel but as binary generic file. The problem is present also for normal html page: some times the HTML source are displayed on the browser. I have found that mod_jk 1.26 was affected by this problem but the problem was fixed http://markmail.org/message/jk7ssoyhuadvjvh3 This is my configuration: #Load mod_jk module LoadModule jk_module modules/mod_jk.so #Where to find workers.properties JkWorkersFile conf/workers.properties #Where to put jk logs JkLogFile logs/mod_jk.log #Set the jk log level JkLogLevel debug # Select the log format JkLogStampFormat [%a %b %d %H:%M:%S %Y] #JkOptions indicate to send SSL KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +FlushHeader #JkRequestLogFormat set the request format #JkRequestLogFormat %w %V %T # Send /ROOT to worker named “myworker” #JkMount /* myworker Is the FlushHeader option vital for your application? Can you check, if it also occurs without that option? Since you have log level debug: do you have a JK log file which contains at least one request, which resulted in this wrong behaviour? How easy can you reproduce? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi, .ic is the extension mapped to the controllers of my spring webapp. The Excel is generated by a controller (servlet): this controller execute this instructions response.setContentType(application/excel); response.setHeader(Content-Disposition,attachment; filename=\ nomeFileExcel \); response.flushBuffer(); For the Excel the problem is repetitive but also for other normal html page (generated by jsp) the text/plain content/type was returned with random frequency. If on apache I add AddType *.ic text/html all the html page are ok but the excel are printed with binary format on the browser. So AddType is not the correct solution: I need that the content type is the content type returned by tomcat. Regards, Marco -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20898121.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi Marco, marcobalc schrieb: Hi, .ic is the extension mapped to the controllers of my spring webapp. The Excel is generated by a controller (servlet): this controller execute this instructions response.setContentType(application/excel); response.setHeader(Content-Disposition,attachment; filename=\ nomeFileExcel \); response.flushBuffer(); I see. Do you have any errors in our log files (Tomcat/Webapp), e.g. about response already committed? It seems something either is sending the headers to the web server before the code sets those headers above, or they get reset after setting them. E.g. if the code under any condition calls flushBuffer() before setting those headers, the response will already be committed and you can't set the headers later on. Any call to getWriter() also makes it impossible to set headers later. If there are no error messages, you could try to check via isCommitted() before setting the headers to see, whether this assumption is true or not. You can also use register a ServletResponseWrapper in a filter to intercept the calls to the ServletResponse and to debug, why and when the response got committed prematurely (and also to see, whether your setContentType() got actually called. For the Excel the problem is repetitive but also for other normal html page (generated by jsp) the text/plain content/type was returned with random frequency. If on apache I add AddType *.ic text/html all the html page are ok but the excel are printed with binary format on the browser. So AddType is not the correct solution: I need that the content type is the content type returned by tomcat. Not sure, what that shows exactly, but you can set the log level of the connector components higher by adding org.apache.coyote.level = FINEST org.apache.jk.level = FINEST org.apache.tomcat.level = FINEST to conf/logging.properties. The log will then also contain messages like Dec 8, 2008 4:00:05 PM org.apache.jk.core.MsgContext action FINE: COMMIT Dec 8, 2008 4:00:05 PM org.apache.jk.common.JkInputStream appendHead FINE: COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === ETag = W/16763-1201552728000 Last-Modified = Mon, 28 Jan 2008 20:38:48 GMT So you can see the headers sent out by Tomcat. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi, many thanks for advice: I have enabled this log and I see the information that I attach. http://www.nabble.com/file/p20903814/committed.txt committed.txt The problem seem to be the row FINE: Response already committed but I don't understand why the response was committed... I investigate on it. Regards, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, .ic is the extension mapped to the controllers of my spring webapp. The Excel is generated by a controller (servlet): this controller execute this instructions response.setContentType(application/excel); response.setHeader(Content-Disposition,attachment; filename=\ nomeFileExcel \); response.flushBuffer(); I see. Do you have any errors in our log files (Tomcat/Webapp), e.g. about response already committed? It seems something either is sending the headers to the web server before the code sets those headers above, or they get reset after setting them. E.g. if the code under any condition calls flushBuffer() before setting those headers, the response will already be committed and you can't set the headers later on. Any call to getWriter() also makes it impossible to set headers later. If there are no error messages, you could try to check via isCommitted() before setting the headers to see, whether this assumption is true or not. You can also use register a ServletResponseWrapper in a filter to intercept the calls to the ServletResponse and to debug, why and when the response got committed prematurely (and also to see, whether your setContentType() got actually called. For the Excel the problem is repetitive but also for other normal html page (generated by jsp) the text/plain content/type was returned with random frequency. If on apache I add AddType *.ic text/html all the html page are ok but the excel are printed with binary format on the browser. So AddType is not the correct solution: I need that the content type is the content type returned by tomcat. Not sure, what that shows exactly, but you can set the log level of the connector components higher by adding org.apache.coyote.level = FINEST org.apache.jk.level = FINEST org.apache.tomcat.level = FINEST to conf/logging.properties. The log will then also contain messages like Dec 8, 2008 4:00:05 PM org.apache.jk.core.MsgContext action FINE: COMMIT Dec 8, 2008 4:00:05 PM org.apache.jk.common.JkInputStream appendHead FINE: COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === ETag = W/16763-1201552728000 Last-Modified = Mon, 28 Jan 2008 20:38:48 GMT So you can see the headers sent out by Tomcat. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20903814.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad content type mod_jk 1.2.27
Hi, I have tested an other controller that return to a jsp with simple HTML. The last rows of this controller are ... log.debug(isCommitted?? +response.isCommitted()); Map m = new HashMap(); m.put(tutteListe, tutteListe); return new ModelAndView(getInputView(), m); I have invoked 5 times the same controller and the first 4 times the response is ok and the last call resulted on text/plain content type and in effect isCommitted return true. 2008-12-08 22:54:20,506 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:25,104 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:25,538 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:27,240 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? false 2008-12-08 22:54:28,781 DEBUG [it.urlandus.events.app.web.controller.frontend.RegistrantsList] - isCommitted?? true Any idea about a possible cause of this issue? Many thanks, Marco marcobalc wrote: Hi, many thanks for advice: I have enabled this log and I see the information that I attach. http://www.nabble.com/file/p20903814/committed.txt committed.txt The problem seem to be the row FINE: Response already committed but I don't understand why the response was committed... I investigate on it. Regards, Marco Rainer Jung-3 wrote: Hi Marco, marcobalc schrieb: Hi, .ic is the extension mapped to the controllers of my spring webapp. The Excel is generated by a controller (servlet): this controller execute this instructions response.setContentType(application/excel); response.setHeader(Content-Disposition,attachment; filename=\ nomeFileExcel \); response.flushBuffer(); I see. Do you have any errors in our log files (Tomcat/Webapp), e.g. about response already committed? It seems something either is sending the headers to the web server before the code sets those headers above, or they get reset after setting them. E.g. if the code under any condition calls flushBuffer() before setting those headers, the response will already be committed and you can't set the headers later on. Any call to getWriter() also makes it impossible to set headers later. If there are no error messages, you could try to check via isCommitted() before setting the headers to see, whether this assumption is true or not. You can also use register a ServletResponseWrapper in a filter to intercept the calls to the ServletResponse and to debug, why and when the response got committed prematurely (and also to see, whether your setContentType() got actually called. For the Excel the problem is repetitive but also for other normal html page (generated by jsp) the text/plain content/type was returned with random frequency. If on apache I add AddType *.ic text/html all the html page are ok but the excel are printed with binary format on the browser. So AddType is not the correct solution: I need that the content type is the content type returned by tomcat. Not sure, what that shows exactly, but you can set the log level of the connector components higher by adding org.apache.coyote.level = FINEST org.apache.jk.level = FINEST org.apache.tomcat.level = FINEST to conf/logging.properties. The log will then also contain messages like Dec 8, 2008 4:00:05 PM org.apache.jk.core.MsgContext action FINE: COMMIT Dec 8, 2008 4:00:05 PM org.apache.jk.common.JkInputStream appendHead FINE: COMMIT sending headers [EMAIL PROTECTED] === MimeHeaders === ETag = W/16763-1201552728000 Last-Modified = Mon, 28 Jan 2008 20:38:48 GMT So you can see the headers sent out by Tomcat. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/bad-content-type-mod_jk-1.2.27-tp20892496p20904280.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
