You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by MAHAINDRA Ketut <ke...@gemalto.com> on 2007/06/01 09:41:37 UTC
Problem with mod_jk / tomcat on file streaming
Hello all,
I have a problem when using Tomcat 5.5.23 and apache/mod_jk 1.2.23.
I have a piece of code that will stream a file when a download request
is made by a user.
...
response.setContentType("application/octet-stream");
response.setContentLength((int)fDownload.length());
response.setHeader("Content-Disposition", "attachment; filename=\"" +
fromFileName + "\"");
// read the fromFile and write to output stream
FileInputStream fis = new FileInputStream(location + "/" +
fromFileName); //$NON-NLS-1$
BufferedOutputStream bos = new
BufferedOutputStream(response.getOutputStream());
int iLen =0;
byte[] buffer = new byte[4096];
while ((iLen = fis.read(buffer)) != -1) {
bos.write(buffer,0,iLen);
}
fis.close();
bos.close();
...
When the application is accessed directly through Tomcat on port 8080,
there is no problem.
But when we put apache / mod_jk to provide connection to tomcat, the
stream is disconnected prematurely at around 450K with the following
exceptions logged in catalina.out.
ClientAbortException: java.io.IOException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
ava:366)
at
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
at
org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:347)
at
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:
392)
at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStrea
m.java:89)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at
java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at
com.gemalto.tools.lkms.actions.ManageVersionAction.downloadFile(Unknown
Source)
at
com.gemalto.tools.lkms.actions.ManageVersionAction.execute(Unknown
Source)
at
org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAc
tion.java:58)
at
org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractE
xecuteAction.java:67)
at
org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommand
Base.java:51)
at
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at
org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.jav
a:304)
at
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at
org.apache.struts.chain.ComposableRequestProcessor.process(ComposableReq
uestProcessor.java:283)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
com.gemalto.tools.lkms.util.SetCharacterEncodingFilter.doFilter(Unknown
Source)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:117)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542
)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
51)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
at
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
Protocol.java:472)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException
at
org.apache.coyote.ajp.AjpAprProcessor.flush(AjpAprProcessor.java:1197)
at
org.apache.coyote.ajp.AjpAprProcessor$SocketOutputBuffer.doWrite(AjpAprP
rocessor.java:1282)
at org.apache.coyote.Response.doWrite(Response.java:560)
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
ava:361)
... 36 more
Is there any issue on the code ?
Or is it a known mod_jk issue ? Or is it perhaps a configuration issue
on my side ?
--
Best regards,
Ketut Mahaindra (Ito)
RE: Problem with mod_jk / tomcat on file streaming
Posted by MAHAINDRA Ketut <ke...@gemalto.com>.
Hello,
Anyone can help on this?
Any help will be greatly appreciated.
Thanks again for your kind attention
Best regards
Ketut Mahaindra (Ito)
________________________________
From: MAHAINDRA Ketut [mailto:ketut.mahaindra@gemalto.com]
Sent: Fri 06/01/2007 16:40
To: Tomcat Users List
Subject: RE: Problem with mod_jk / tomcat on file streaming
Hello,
Here is the log after changing the JkLogLevel to "trace"
( most of the beginning of the log were removed as it indicates the data
receives from the stream )
You see below the log when the stream is cut prematurely after sequence
"1ff0"
...
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 1fe0 43 0B F9
D0 EF F9 D8 78 A1 65 88 2E 97 2F 5E 5C - C......x.e.../^\
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 1ff0 8E 02 40
ED A7 B4 9A 29 69 B9 D9 00 00 00 00 00 - ..@....)i.......
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (1049): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1399): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug] ws_write::mod_jk.c
(452): written 8184 out of 8184
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1525): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (938): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): received from
ajp13 pos=0 len=2 max=8192
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 0000 05 01 00
00 00 00 00 00 00 00 00 00 00 00 00 00 - ................
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (1049): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1399): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_process_callback::jk_ajp_common.c (1506): AJP13 protocol: Reuse is
OK
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1514): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_get_reply::jk_ajp_common.c (1651): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_service::jk_ajp_common.c (1832): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_done::jk_ajp_common.c (2242): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_done::jk_ajp_common.c (2286): recycling connection pool slot=0 for
worker ajp13
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_done::jk_ajp_common.c (2289): exit
[Fri Jun 01 16:20:38 2007] ajp13 server.mydomain.com 1.908274
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug] jk_handler::mod_jk.c
(2238): Service finished with status=200 for worker=ajp13
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace] jk_handler::mod_jk.c
(2241): exit
--
Best regards,
Ketut Mahaindra (Ito)
R&D Project Manager - T&I Tools and Applications Lab
"The race for perfection has no finish line"
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Friday, June 01, 2007 4:38 PM
To: Tomcat Users List
Subject: Re: Problem with mod_jk / tomcat on file streaming
Try to reproduce on a test system. If you can do that, use JkLogLevel
trace and post the final parts, where you expect the problem to happen.
MAHAINDRA Ketut wrote:
> Hello,
>
> This is what I have inside my mod_jk.conf for Apache
> ---
> LoadModule jk_module modules/mod_jk.so
> <IfModule mod_jk.c>
> JkWorkersFile /etc/httpd/conf.d/workers.properties
> JkLogFile /etc/httpd/logs/mod_jk.log
> JkLogLevel info
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> JkOptions +ForwardKeySize +ForwardURICompatUnparsed +FlushHeader
> JkRequestLogFormat "%w %V %T"
> JkShmFile /var/run/mod_jk.shm
> # mount points
> JKMount /products/*.jsp ajp13
> JKMount /products/* ajp13
> </IfModule>
> ---
>
> This is the workers.properties file extract for the ajp13 worker
> ---
> worker.ajp13.port=15509
> worker.ajp13.host=localhost
> worker.ajp13.type=ajp13
> worker.ajp13.lbfactor=1
> worker.ajp13.socket_keepalive=1
> worker.ajp13.socket_timeout=0
> ---
>
> I refrain from +FlushPackets because as the guide indicates, it gives
a
> strong performance penalty to for Apache and Tomcat.
>
> As for the timeout, not sure which one to use and the default is
already
> "0" which means indefinite.
>
> Any help are appreciated.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Problem with mod_jk / tomcat on file streaming
Posted by MAHAINDRA Ketut <ke...@gemalto.com>.
Hello,
Here is the log after changing the JkLogLevel to "trace"
( most of the beginning of the log were removed as it indicates the data
receives from the stream )
You see below the log when the stream is cut prematurely after sequence
"1ff0"
...
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 1fe0 43 0B F9
D0 EF F9 D8 78 A1 65 88 2E 97 2F 5E 5C - C......x.e.../^\
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 1ff0 8E 02 40
ED A7 B4 9A 29 69 B9 D9 00 00 00 00 00 - ..@....)i.......
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (1049): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1399): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug] ws_write::mod_jk.c
(452): written 8184 out of 8184
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1525): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (938): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): received from
ajp13 pos=0 len=2 max=8192
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1043): 0000 05 01 00
00 00 00 00 00 00 00 00 00 00 00 00 00 - ................
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_connection_tcp_get_message::jk_ajp_common.c (1049): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1399): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_process_callback::jk_ajp_common.c (1506): AJP13 protocol: Reuse is
OK
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_process_callback::jk_ajp_common.c (1514): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_get_reply::jk_ajp_common.c (1651): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_service::jk_ajp_common.c (1832): exit
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_done::jk_ajp_common.c (2242): enter
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug]
ajp_done::jk_ajp_common.c (2286): recycling connection pool slot=0 for
worker ajp13
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace]
ajp_done::jk_ajp_common.c (2289): exit
[Fri Jun 01 16:20:38 2007] ajp13 server.mydomain.com 1.908274
[Fri Jun 01 16:20:38 2007] [18003:1744] [debug] jk_handler::mod_jk.c
(2238): Service finished with status=200 for worker=ajp13
[Fri Jun 01 16:20:38 2007] [18003:1744] [trace] jk_handler::mod_jk.c
(2241): exit
--
Best regards,
Ketut Mahaindra (Ito)
R&D Project Manager - T&I Tools and Applications Lab
"The race for perfection has no finish line"
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Friday, June 01, 2007 4:38 PM
To: Tomcat Users List
Subject: Re: Problem with mod_jk / tomcat on file streaming
Try to reproduce on a test system. If you can do that, use JkLogLevel
trace and post the final parts, where you expect the problem to happen.
MAHAINDRA Ketut wrote:
> Hello,
>
> This is what I have inside my mod_jk.conf for Apache
> ---
> LoadModule jk_module modules/mod_jk.so
> <IfModule mod_jk.c>
> JkWorkersFile /etc/httpd/conf.d/workers.properties
> JkLogFile /etc/httpd/logs/mod_jk.log
> JkLogLevel info
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> JkOptions +ForwardKeySize +ForwardURICompatUnparsed +FlushHeader
> JkRequestLogFormat "%w %V %T"
> JkShmFile /var/run/mod_jk.shm
> # mount points
> JKMount /products/*.jsp ajp13
> JKMount /products/* ajp13
> </IfModule>
> ---
>
> This is the workers.properties file extract for the ajp13 worker
> ---
> worker.ajp13.port=15509
> worker.ajp13.host=localhost
> worker.ajp13.type=ajp13
> worker.ajp13.lbfactor=1
> worker.ajp13.socket_keepalive=1
> worker.ajp13.socket_timeout=0
> ---
>
> I refrain from +FlushPackets because as the guide indicates, it gives
a
> strong performance penalty to for Apache and Tomcat.
>
> As for the timeout, not sure which one to use and the default is
already
> "0" which means indefinite.
>
> Any help are appreciated.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with mod_jk / tomcat on file streaming
Posted by Rainer Jung <ra...@kippdata.de>.
Try to reproduce on a test system. If you can do that, use JkLogLevel
trace and post the final parts, where you expect the problem to happen.
MAHAINDRA Ketut wrote:
> Hello,
>
> This is what I have inside my mod_jk.conf for Apache
> ---
> LoadModule jk_module modules/mod_jk.so
> <IfModule mod_jk.c>
> JkWorkersFile /etc/httpd/conf.d/workers.properties
> JkLogFile /etc/httpd/logs/mod_jk.log
> JkLogLevel info
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> JkOptions +ForwardKeySize +ForwardURICompatUnparsed +FlushHeader
> JkRequestLogFormat "%w %V %T"
> JkShmFile /var/run/mod_jk.shm
> # mount points
> JKMount /products/*.jsp ajp13
> JKMount /products/* ajp13
> </IfModule>
> ---
>
> This is the workers.properties file extract for the ajp13 worker
> ---
> worker.ajp13.port=15509
> worker.ajp13.host=localhost
> worker.ajp13.type=ajp13
> worker.ajp13.lbfactor=1
> worker.ajp13.socket_keepalive=1
> worker.ajp13.socket_timeout=0
> ---
>
> I refrain from +FlushPackets because as the guide indicates, it gives a
> strong performance penalty to for Apache and Tomcat.
>
> As for the timeout, not sure which one to use and the default is already
> "0" which means indefinite.
>
> Any help are appreciated.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Problem with mod_jk / tomcat on file streaming
Posted by MAHAINDRA Ketut <ke...@gemalto.com>.
Hello,
This is what I have inside my mod_jk.conf for Apache
---
LoadModule jk_module modules/mod_jk.so
<IfModule mod_jk.c>
JkWorkersFile /etc/httpd/conf.d/workers.properties
JkLogFile /etc/httpd/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompatUnparsed +FlushHeader
JkRequestLogFormat "%w %V %T"
JkShmFile /var/run/mod_jk.shm
# mount points
JKMount /products/*.jsp ajp13
JKMount /products/* ajp13
</IfModule>
---
This is the workers.properties file extract for the ajp13 worker
---
worker.ajp13.port=15509
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
worker.ajp13.socket_keepalive=1
worker.ajp13.socket_timeout=0
---
I refrain from +FlushPackets because as the guide indicates, it gives a
strong performance penalty to for Apache and Tomcat.
As for the timeout, not sure which one to use and the default is already
"0" which means indefinite.
Any help are appreciated.
--
Best regards,
Ketut Mahaindra (Ito)
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Friday, June 01, 2007 4:04 PM
To: Tomcat Users List
Subject: Re: Problem with mod_jk / tomcat on file streaming
Have a look at the flush options on
http://tomcat.apache.org/connectors-doc/reference/apache.html
and maybe at the various timeouts at
http://tomcat.apache.org/connectors-doc/reference/workers.html
There is also a Timeout directive for Apache httpd.
If you can't find it out, post your config and more details: in case you
can reproduce, you can set JkLogLevel to trace and we'll most likely
see, why mod_jk closes the connection to Tomcat (if so). Packet dumps
are also helpful.
There is no known issue, apart from the need of correct flush settings
for streaming.
Regards,
Rainer
MAHAINDRA Ketut wrote:
> Hello all,
>
>
>
> I have a problem when using Tomcat 5.5.23 and apache/mod_jk 1.2.23.
>
> I have a piece of code that will stream a file when a download request
> is made by a user.
>
>
>
> ...
>
> response.setContentType("application/octet-stream");
>
> response.setContentLength((int)fDownload.length());
>
> response.setHeader("Content-Disposition", "attachment; filename=\"" +
> fromFileName + "\"");
>
>
>
> // read the fromFile and write to output stream
>
> FileInputStream fis = new FileInputStream(location + "/" +
> fromFileName); //$NON-NLS-1$
>
> BufferedOutputStream bos = new
> BufferedOutputStream(response.getOutputStream());
>
> int iLen =0;
>
> byte[] buffer = new byte[4096];
>
> while ((iLen = fis.read(buffer)) != -1) {
>
> bos.write(buffer,0,iLen);
>
> }
>
> fis.close();
>
> bos.close();
>
> ...
>
>
>
> When the application is accessed directly through Tomcat on port 8080,
> there is no problem.
>
> But when we put apache / mod_jk to provide connection to tomcat, the
> stream is disconnected prematurely at around 450K with the following
> exceptions logged in catalina.out.
>
>
>
> ClientAbortException: java.io.IOException
>
> at
>
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
> ava:366)
>
> at
> org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
>
> at
> org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:347)
>
> at
>
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:
> 392)
>
> at
>
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
>
> at
>
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStrea
> m.java:89)
>
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
>
> at
> java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
>
> at
>
com.gemalto.tools.lkms.actions.ManageVersionAction.downloadFile(Unknown
> Source)
>
> at
> com.gemalto.tools.lkms.actions.ManageVersionAction.execute(Unknown
> Source)
>
> at
>
org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAc
> tion.java:58)
>
> at
>
org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractE
> xecuteAction.java:67)
>
> at
>
org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommand
> Base.java:51)
>
> at
> org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
>
> at
>
org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.jav
> a:304)
>
> at
> org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
>
> at
>
org.apache.struts.chain.ComposableRequestProcessor.process(ComposableReq
> uestProcessor.java:283)
>
> at
>
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
>
> at
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
>
> at
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>
> at
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:269)
>
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:188)
>
> at
>
com.gemalto.tools.lkms.util.SetCharacterEncodingFilter.doFilter(Unknown
> Source)
>
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:215)
>
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:188)
>
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:210)
>
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:174)
>
> at
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :127)
>
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :117)
>
> at
>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542
> )
>
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:108)
>
> at
>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
> 51)
>
> at
>
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
>
> at
>
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
> Protocol.java:472)
>
> at
>
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
>
> at java.lang.Thread.run(Thread.java:595)
>
> Caused by: java.io.IOException
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.flush(AjpAprProcessor.java:1197)
>
> at
>
org.apache.coyote.ajp.AjpAprProcessor$SocketOutputBuffer.doWrite(AjpAprP
> rocessor.java:1282)
>
> at org.apache.coyote.Response.doWrite(Response.java:560)
>
> at
>
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
> ava:361)
>
> ... 36 more
>
>
>
>
>
> Is there any issue on the code ?
>
> Or is it a known mod_jk issue ? Or is it perhaps a configuration issue
> on my side ?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with mod_jk / tomcat on file streaming
Posted by Rainer Jung <ra...@kippdata.de>.
Have a look at the flush options on
http://tomcat.apache.org/connectors-doc/reference/apache.html
and maybe at the various timeouts at
http://tomcat.apache.org/connectors-doc/reference/workers.html
There is also a Timeout directive for Apache httpd.
If you can't find it out, post your config and more details: in case you
can reproduce, you can set JkLogLevel to trace and we'll most likely
see, why mod_jk closes the connection to Tomcat (if so). Packet dumps
are also helpful.
There is no known issue, apart from the need of correct flush settings
for streaming.
Regards,
Rainer
MAHAINDRA Ketut wrote:
> Hello all,
>
>
>
> I have a problem when using Tomcat 5.5.23 and apache/mod_jk 1.2.23.
>
> I have a piece of code that will stream a file when a download request
> is made by a user.
>
>
>
> ...
>
> response.setContentType("application/octet-stream");
>
> response.setContentLength((int)fDownload.length());
>
> response.setHeader("Content-Disposition", "attachment; filename=\"" +
> fromFileName + "\"");
>
>
>
> // read the fromFile and write to output stream
>
> FileInputStream fis = new FileInputStream(location + "/" +
> fromFileName); //$NON-NLS-1$
>
> BufferedOutputStream bos = new
> BufferedOutputStream(response.getOutputStream());
>
> int iLen =0;
>
> byte[] buffer = new byte[4096];
>
> while ((iLen = fis.read(buffer)) != -1) {
>
> bos.write(buffer,0,iLen);
>
> }
>
> fis.close();
>
> bos.close();
>
> ...
>
>
>
> When the application is accessed directly through Tomcat on port 8080,
> there is no problem.
>
> But when we put apache / mod_jk to provide connection to tomcat, the
> stream is disconnected prematurely at around 450K with the following
> exceptions logged in catalina.out.
>
>
>
> ClientAbortException: java.io.IOException
>
> at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
> ava:366)
>
> at
> org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
>
> at
> org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:347)
>
> at
> org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:
> 392)
>
> at
> org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
>
> at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStrea
> m.java:89)
>
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
>
> at
> java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
>
> at
> com.gemalto.tools.lkms.actions.ManageVersionAction.downloadFile(Unknown
> Source)
>
> at
> com.gemalto.tools.lkms.actions.ManageVersionAction.execute(Unknown
> Source)
>
> at
> org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAc
> tion.java:58)
>
> at
> org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractE
> xecuteAction.java:67)
>
> at
> org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommand
> Base.java:51)
>
> at
> org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
>
> at
> org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.jav
> a:304)
>
> at
> org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
>
> at
> org.apache.struts.chain.ComposableRequestProcessor.process(ComposableReq
> uestProcessor.java:283)
>
> at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
>
> at
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:269)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:188)
>
> at
> com.gemalto.tools.lkms.util.SetCharacterEncodingFilter.doFilter(Unknown
> Source)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:215)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:188)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:210)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:174)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :127)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :117)
>
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542
> )
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:108)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
> 51)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
>
> at
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
> Protocol.java:472)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
>
> at java.lang.Thread.run(Thread.java:595)
>
> Caused by: java.io.IOException
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.flush(AjpAprProcessor.java:1197)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor$SocketOutputBuffer.doWrite(AjpAprP
> rocessor.java:1282)
>
> at org.apache.coyote.Response.doWrite(Response.java:560)
>
> at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
> ava:361)
>
> ... 36 more
>
>
>
>
>
> Is there any issue on the code ?
>
> Or is it a known mod_jk issue ? Or is it perhaps a configuration issue
> on my side ?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
SOLVED: Problem with mod_jk / tomcat on file streaming
Posted by MAHAINDRA Ketut <ke...@gemalto.com>.
Hi all,
I managed to solve the problem.
The problem was identified as a problem in tomcat-native 1.1.7 and
below.
The corresponding bug report is:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41124
After deploying the latest tomcat-native (1.1.10) at the time of writing
this mail, the problem disappears.
Thanks to Haroon Rafique for pointing this out.
--
Best regards,
Ketut Mahaindra (Ito)
-----Original Message-----
From: MAHAINDRA Ketut [mailto:ketut.mahaindra@gemalto.com]
Sent: Friday, June 01, 2007 3:42 PM
To: users@tomcat.apache.org
Subject: Problem with mod_jk / tomcat on file streaming
Hello all,
I have a problem when using Tomcat 5.5.23 and apache/mod_jk 1.2.23.
I have a piece of code that will stream a file when a download request
is made by a user.
...
response.setContentType("application/octet-stream");
response.setContentLength((int)fDownload.length());
response.setHeader("Content-Disposition", "attachment; filename=\"" +
fromFileName + "\"");
// read the fromFile and write to output stream
FileInputStream fis = new FileInputStream(location + "/" +
fromFileName); //$NON-NLS-1$
BufferedOutputStream bos = new
BufferedOutputStream(response.getOutputStream());
int iLen =0;
byte[] buffer = new byte[4096];
while ((iLen = fis.read(buffer)) != -1) {
bos.write(buffer,0,iLen);
}
fis.close();
bos.close();
...
When the application is accessed directly through Tomcat on port 8080,
there is no problem.
But when we put apache / mod_jk to provide connection to tomcat, the
stream is disconnected prematurely at around 450K with the following
exceptions logged in catalina.out.
ClientAbortException: java.io.IOException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
ava:366)
at
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
at
org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:347)
at
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:
392)
at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStrea
m.java:89)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at
java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at
com.gemalto.tools.lkms.actions.ManageVersionAction.downloadFile(Unknown
Source)
at
com.gemalto.tools.lkms.actions.ManageVersionAction.execute(Unknown
Source)
at
org.apache.struts.chain.commands.servlet.ExecuteAction.execute(ExecuteAc
tion.java:58)
at
org.apache.struts.chain.commands.AbstractExecuteAction.execute(AbstractE
xecuteAction.java:67)
at
org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommand
Base.java:51)
at
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at
org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.jav
a:304)
at
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at
org.apache.struts.chain.ComposableRequestProcessor.process(ComposableReq
uestProcessor.java:283)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
com.gemalto.tools.lkms.util.SetCharacterEncodingFilter.doFilter(Unknown
Source)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:117)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:542
)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
51)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
at
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpApr
Protocol.java:472)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException
at
org.apache.coyote.ajp.AjpAprProcessor.flush(AjpAprProcessor.java:1197)
at
org.apache.coyote.ajp.AjpAprProcessor$SocketOutputBuffer.doWrite(AjpAprP
rocessor.java:1282)
at org.apache.coyote.Response.doWrite(Response.java:560)
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.j
ava:361)
... 36 more
Is there any issue on the code ?
Or is it a known mod_jk issue ? Or is it perhaps a configuration issue
on my side ?
--
Best regards,
Ketut Mahaindra (Ito)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org