Re: Tomcat Concurrency
Hi,
-Original-Nachricht-
Von: Mark Haroldson markharold...@msn.com
An: users@tomcat.apache.org
Example:
Given the following servlet;
Servlet()
{
Output(Start thread);
Thread.sleep(2);
Output(End thread)
}
I would expect the following output
Start Thread
Start Thread
Start Thread
Start Thread
End Thread
End Thread
End Thread
End Thread
Instead I see
Start Thread
Start Thread
End Thread
End Thread
Start Thread
End Thread
Start Thread
End Thread
What are the factors that control thread concurrency in Tomcat? Has
anyone seen behavior like this before? Should I expect a high number
of concurrent threads or does java/tomcat gate access to the servlet?
Are you testing this with a Browser? If so, then I would guess the browser only
uses 1 TCP connection to send all requests. For example, Firefox and Chrome
open only one TCP connection and send the requests sequentially if I open
multiple tabs with the same URL (they wait for the 1st request to finish before
they send the second request). In this case I see an output like this:
Start Thread
End Thread
Start Thread
End Thread
Start Thread
End Thread
However, If I use IE10 on Win8, it will open multiple TCP connections and send
the requests concurrently. The output will look like this:
Start Thread
Start Thread
Start Thread
End Thread
End Thread
End Thread
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IE 8 and before refusing to download files (I hate IE)
Hi, -Original-Nachricht- Von: Jeffrey Janner jeffrey.jan...@polydyne.com An: 'Tomcat Users List' users@tomcat.apache.org Ran into an interesting problem today. It seems that IE8 and before no longer likes how we are sending BLOB files. Worked last week as far as we can tell. Works fine for IE9+ and other browsers, but IE8 is suddenly giving us an error message, as though it is ignoring the response headers. I'm not going to completely rule out the possibility it is in our code somewhere, but we haven't found it yet. We did also upgrade out app over the weekend, but the problem didn't show up in our test environment (as far as we can tell). Here is the relevant code: [...] Works great if the MimeType is text/html, but anything else generates an error. The getContent routine reads from the BLOB and copies it to the response output stream. None of this code has changed, and the access log shows a 200 response and the full number of bytes of the file. Anybody have any ideas? Server1 specs: Tomcat 6.0.33/Java 1.6.0_33/Windows 2003 SP2 Server2 specs: Tomcat 6.0.36/Java 1.6.0_34/Windows 2008 R2/SP1 can you give an example of the actual HTTP response headers that are sent to the client? I just tested that the following response works with IE8 on WinXP and IE10 using its IE8-Mode on WIndows 8: HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: application/x-zip-compressed Server: Microsoft-IIS/7.5 Content-Disposition: attachment; filename=Portal.zip Date: Mon, 03 Jun 2013 18:14:14 GMT [...] This is generated by a Servlet on Tomcat 7.0.40 that sets the Content-Type and Content-Disposition headers and then writes bytes to the respone's OutputStream (the response is served by IIS/7.5 using ISAPI Redirector). For Content-Disposition, I'm using javax.mail.internet.ContentDisposition which should automatically add necessary escaping and quoting to the filename: part. I also tested with IE10's IE7-Mode that is used when activating Compatibility View and no X-UA-Compatible header is present that tells IE to use it's highest browser mode (like X-UA-Compatible: IE=Edge). (As an aside, for my websites I don't support any IE below IE9... ;-) However, I use the X-UA-Compatible: IE=Edge header to prevent IE to use the compatibility mode, which can happen if Microsoft suddenly decides to add your site to its compatibility view list, or sometimes if IE is embedded as ActiveX control etc...) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Console when running as a service.
Hi André, -Original-Nachricht- Von: André Warnier a...@ice-sa.com An: Tomcat Users List users@tomcat.apache.org Betreff: Re: Console when running as a service. Datum: Mon, 11 Mar 2013 19:20:23 +0100 +1. Eek, I tearfully and shamefully agree. But still 90% or more of corporate internal documents are written as Word documents, and there is no open-source tool which can perfectly handle this shamefully proprietary format and convert it to some non-propietary format that one could still read in 10 year's time, so what is one to do if one wants to get some money to get one's children through computer school and pay for their iPhones, he ? I guess with proprietary format you mean the old/outdated .doc format? :) This has been superseded (since 2006/2007) by the Office Open XML format which has been standardized as ECMA-376 and ISO/IEC 29500 [1], for which a public documentation is available, so I wouldn't call this proprietary. ;-) However, you're probably right that a lot of already existing word documents are still in the old .doc format instead of .docx. Regards, Konstantin Preißer [1] http://en.wikipedia.org/wiki/Office_Open_XML - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Tomcat Linux/Windows Performance Question
Hi Christopher, -Original-Nachricht- Von: Christopher Schultz ch...@christopherschultz.net Datum: Mon, 29 Oct 2012 03:52:36 +0100 Personally, I prefer Linux based upon its friendliness to developers and administrators: it's got the tools we need and it's easy to build additional tools if necessary. Well, personally, I'm a fan of windows (i.e. I wouldn't voluntarily install any other OS than Windows on my boxes and servers ;-) ) The only performance-related items of which I am aware that sometimes give Microsoft Windows a disadvantage are: 1. Poor uptime (due to general instability and frequent required-reboot OS updates) My personal impression is that Windows (at least the current versions of it - Win7, Server2008R2) is one of the stablest OSes that I have seen. The only times when my Win7/2008 crashed was when the hardware had a defect or a faulty device driver was installed. (I remember when I played with OpenSuse linux in a VM, where I had to restart it every 5 minutes, as after working a bit with the GUI/KDE it got very instable or didn't react any more - but maybe this applies only to the GUI I used or to the OpenSuse distribution, I'm not sure). 2. Limited IP stacks on non-server versions I agree, that is what I'm also not happy with. (Currently, the upgrade version of Win8 Pro costs only 29,99 € in germany or $39,99 in the US - I guess the server versions will not be that cheap :) ) 3. Bizarre observations when using high-resolution (or even ms-res) clocks and timers... seems like you can't get more than about 0.1-sec resolution or so reliably -- or at least plausibly -- on a win32 box. Hmm, I think this applies for outdated versions of Windows like WinXP, which don't support HPET timers. I remember when I wrote a java snippet at my WinXP machine at work like this: long startTime = System.nanoTime(); // do something which doesn't take much time... long duration = System.nanoTime() - startTime; and then being surprised that duration contained a negative value... However, Windows versions = 6.0 should have HPET support to allow high precision time measurement. It seems that on my Win7 machine, using System.nanoTime() (or the StopWatch class in .Net), I can get a resolution of about 100 nanoseconds. - -chris Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Two (different) issues with Tomcat 7.0.32 AJP-APR and AJP-NIO connectors
Hi all, I'm running Tomcat 7.0.32 with Java 1.7.0_09 (64-bit) on Windows Server 2008 R2 (64-bit), behind IIS 7.5 with ISAPI Redirector 1.2.37. For the AJP connection, I used the AJP-APR connector (with Tomcat Native 1.1.24). 1) This worked perfectly fine since the initial setup of the server 3 months ago (however with lower version numbers of Tomcat and Java), but 3 days ago, suddenly the JVM crashed, with following crash report: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7160e291, pid=4028, tid=4060 # # JRE version: 7.0_09-b05 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0xae291] # # Core dump written. Default location: D:\tomcat7\bin\hs_err_pid4028.mdmp # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x00feb800): GCTaskThread [stack: 0x0481,0x0491] [id=4060] siginfo: ExceptionCode=0xc005, reading address 0x [...] Stack: [0x0481,0x0491], sp=0x0490fa70, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xae291] At a first glance this seems like a JVM bug (as the current thread is GCTaskThread), but when I googled for it, most sources say that this is mostly caused by bugs in JNI code / a library that uses JNI [1]. So maybe this is a problem with the Tomcat Native library (which is the only native library that I'm using)? Unfortunately, as this is the first JVM crash since three months, this problems seems not to be very reproducible (or e.g. a change in the recent Java versions could have triggered this). Unfortunately, for me this means that I have to consider the APR connectors on 64-bit Windows as broken (at least for the time being), and therefore I switched to the NIO/BIO ones and removed the TC native library. If I will get a JVM crash again, then this would probably mean that it was not the fault of the TC native library. ;) 2.) After I switched to the AJP-NIO connector, I got the following stacktrace in catalina.log: Okt 20, 2012 2:58:51 PM org.apache.coyote.ajp.AjpNioProcessor process SEVERE: Error processing request java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183) at org.apache.coyote.ajp.AjpNioProcessor.output(AjpNioProcessor.java:281) at org.apache.coyote.ajp.AbstractAjpProcessor$SocketOutputBuffer.doWrite(AbstractAjpProcessor.java:1122) at org.apache.coyote.Response.doWrite(Response.java:504) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:334) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:283) at org.apache.catalina.connector.Response.finishResponse(Response.java:514) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:434) at org.apache.coyote.ajp.AjpNioProcessor.process(AjpNioProcessor.java:184) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Maybe this could be related to bug 53119 [2] (the stack traces look very similar)? (However I have not yet tried if this is reproducible with the given testcase - when I tested it back then with Tomcat 7.0.27's AJP-NIO connector, I could not reproduce the error). So, currently I have switched to the AJP-BIO connector. Thanks! Regards, Konstantin Preißer [1] https://forums.oracle.com/forums/thread.jspa?threadID=1540042 [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=53119 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Q) ajp connector
Hi Alex, -Original-Nachricht- Von: Alex Samad - Yieldbroker alex.sa...@yieldbroker.com An: Tomcat Users List users@tomcat.apache.org Betreff: RE: Q) ajp connector Datum: Thu, 13 Sep 2012 05:52:55 +0200 So would that then be Client - websocket - IIS - is this still done as AJP or websocket -jboss/tomcat Is jboss tomcat ready to handle websockets ? Tomcat supports Websockets since 7.0.27, but I think it is not possible to use Websockets over AJP because of the design of the AJP protocol (it doesn't allow concurrent reading and writing). For IIS, it should support Websockets since IIS 8.0 (Win Server 2012), but I didn't have time to try it out. So you probably would need your clients to connect directly to Tomcat for using Websockets. I'm currently working on an idea of a SPDY/3 Connector for IIS (as a possible replacement over the AJP conenctor), which is written in C# (using .Net 4.0). SPDY allowes for multiple streams on one TCP connection, so you would only need one open Connection to backend, and it should also allow to tansport Websocket connections (but that connector implementation does not yet have support for it). If you want to take a look at it, you can find the thread of the dev-list here: http://markmail.org/message/q335rbpoylymr77q Note that Tomcat seems to not yet have support for SPDY/3, but only SPDY/2, so unfortunately it is currently not possible to test the connector with Tomcat - but it should work with Jetty. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Equivalent of Web Service Extension in IIS6 on XP Professional
Hi, On 7/10/12 3:29 AM, Vijaya wrote: In order to configure the ISAPI Redirector , according to the Apache documentation, I need to add a new Web Service Extension in IIS6. But the problem is that the web service extension option exists only on IIS6 on Windows 2003 server and not on XP pro. Can anyone help me on how do I add the tomcat extension from IIS6 on XP professional? According to the documentation, the step of adding the Isapi DLL to the allowed Web Extensions applies only to IIS 6.0 and above. However, XP uses IIS 5.1, and there this option is not available, as extensions are automatically allowed to run. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Re : Re: Issue with keep-alive connections, when using APR Connector on Windows and starting Processes from Servlets
Von: Laurent Petit lpe...@yseop.com Datum: Mon, 25 Jun 2012 17:46:06 +0200 Hello Jeff al, Here it is, I've created a Git repository with the sources for the webapp the test (maven projects), and instructions in the README on how to reproduce the issue. https://github.com/lpetit-yseop/apr-test Hope this will help you get started on reproducing the problem, Regards, Hello, I also could reproduce the problem on WIndows 7 64 Bit with Java 1.7.0_05 (64-bit) and Tomcat 7.0.28, using TC Native 1.1.24. I also used a small connectionTimeout=200. What I can see is, that with a normal request (that doesn't start a new process), Tomcat processes the request, and after an inactivity timeout of 200 ms, the APR connector closes the TCP connection. When the browser makes another request, it does open a new connection for that request. However, when a request goes to a servlet that starts a new process, and the timeout of 200 ms occurs, the TCP connection is not closed - but Tomcat doesn't seem to read on it any more, so further requests sent on that TCP connection will never be processed. When the new process (wordpad.exe) is closed, the TCP connection will be aborted. Then, the browser probably establishes a new TCP connection and re-sends it request there, which is processed by Tomcat. Unfortunately, don't have any knowledge of programming native (C) programms using Windows APIs, so I can only make a guess: Could it be that some handles to files/sockets are inherited to the child process (wordpad.exe) when launched by Java's ProcessBuilder, which prevent the socket from being closed? E.g., when I launch a simple C app (which calls WaitForSingleObject(-1, 99)) from the Windows explorer, I can see 7 handles in the taskmanger; whereas when it is launched by the servlet in tomcat, Task manager shows 11 handles - but as said, I don't know if that has something to do with the problem. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Re : Re: Issue with keep-alive connections, when using APR Connector on Windows and starting Processes from Servlets
Hello Jeff all, Von: Jeff MAURY jeffma...@jeffmaury.com Datum: Mon, 25 Jun 2012 18:46:02 +0200 Konstantin, your explanations are very interesting but unclear to me: what do you call the inactivity timer ? When it is started ? After the request has been processed by the servlet ? In that case, I see no difference between a servlet that launch a process and another one. It seems to me that a process that is launched does not inhererits handles from its parent process but it's possible that under Windows, it's an option so it would be interesting to watch. Jeff Sorry, I'm just a normal Tomcat user, and I don't know how exactly the APR connector and its Timeout works, so I am unable to answer that. Howewer, I did some further observations: -When I perform a request to the servlet that opens wordpad.exe, the TCP connection from Tomcat does not close after the timeout - even when I kill the Tomcat process (java.exe), the TCP connection is still open. If I kill wordpad.exe, then finally the connection is closed/aborted. -When I have 1 TCP connection open to Tomcat and the servlet starts the little C program, Task manager shows that it has 11 handles. However, when I have 5 TCP connections open to Tomcat, and do the request on one of them, Task maanger shows that the C program has 15 handles - so four more handles when there are four more connections to Tomcat. All of that 5 TCP connections don't close until I kill that process. That seems to me to be an indication that socket handles could be inherited by the child processes that are startet by ProcessBuilder from tomcat. A msdn article mentions how to create a new process using CreateProcess(); it also mentions that socket handles can be inherited: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724466.aspx However, as I don't have much knowledge about programming with WinAPIs, I don't know why those handles are inherited (the MSDN article mentions that a handle must be specified as inheritable when created, to allow a child process to inherit it). Maybe someone with more WinAPI/Tomcat Native knowledge can help here. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33
-Original-Nachricht- Von: Mladen Turk mt...@apache.org An: users@tomcat.apache.org Betreff: Re: IIS 7.0 Worker process crashes on App Pool recycling since ISAPI redirector 1.2.33 Datum: Sun, 18 Mar 2012 18:39:15 +0100 Could you please try the isapi_redirect_1.2.34_5-dev_win32.zip If this one crashes we'll have to add some override to shared memory so we can fallback to heap one and bypass memory corruption which seems to occur at IIS worker recycle. Hi Mladen, thank you, I tried isapi_redirect_1.2.34_5-dev_win32.zip and so far no crashes, and also no warnings/errors in the ISAPI log. It seems the issue is fixed now. Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Path of log files changed in Tomcat 7.0.25 when installing as Windows Service
-Original-Nachricht-
Von: Mark Thomas ma...@apache.org
An: Tomcat Users List users@tomcat.apache.org
Betreff: Re: Path of log files changed in Tomcat 7.0.25 when
installing as Windows Service
Datum: Fri, 27 Jan 2012 14:38:42 +0100
It means you messed up your install. A clean install of 7.0.25 (with
the installer) works fine for me.
Mark
Hi Mark,
ok, but please note that I was using service.bat, not the Windows Installer.
I tried to reproduce the behavior on a clean Windows XP (32 bit) virtual
machine. I did the following steps:
1. I downloaded jdk-7u2-windows-i586.exe (JDK 7u2) from Oracle and installed
it.
2. I set the JAVA_HOME environment variable to the JDK path,
C:\Programme\Java\jdk1.7.0_02.
3. I downloaded apache-tomcat-7.0.25-windows-x86.zip (the 32-bit Windows Zip
file) from tomcat.apache.org and extracted the files to C:\Tomcat7.
4. When I call startup.bat and later shutdown.bat to start Tomcat directly (not
as service), all logs are stored in C:\Tomcat7, e.g.
C:\Tomact7\logs\catalina.2012-01-27.log. After shutting down Tomact, I
deleted the logs so that the folder is clean.
5. Then, I run service install to install Tomcat as Windows service.
Following output is printed to the console:
Installing the service 'Tomcat7' ...
Using CATALINA_HOME:C:\tomcat7
Using CATALINA_BASE:C:\tomcat7
Using JAVA_HOME:C:\Programme\Java\jdk1.7.0_02
Using JRE_HOME: C:\Programme\Java\jdk1.7.0_02\jre
Using JVM: C:\Programme\Java\jdk1.7.0_02\jre\bin\server\jvm.dll
The service 'Tomcat7' has been installed.
6. I start the Apache Tomcat 7 service (short name: Tomcat7) in the Windows
Services panel.
7. Following logs are created (displayed by dir command):
C:\tomcat7dir /b /s *.log
C:\tomcat7\bin\${catalina.base}\logs\catalina.2012-01-27.log
C:\tomcat7\bin\${catalina.base}\logs\host-manager.2012-01-27.log
C:\tomcat7\bin\${catalina.base}\logs\localhost.2012-01-27.log
C:\tomcat7\bin\${catalina.base}\logs\manager.2012-01-27.log
C:\tomcat7\logs\commons-daemon.2012-01-27.log
C:\tomcat7\logs\tomcat7-stderr.2012-01-27.log
C:\tomcat7\logs\tomcat7-stdout.2012-01-27.log
So it seems the Tomcat logs are stored in
C:\tomcat7\bin\${catalina.base}\logs\, whereas the Daemon logs are stored in
C:\tomcat7\logs\.
Also, when I set CATALINA_HOME to C:\Tomcat7 before installing the service,
the logs are stored in the bin\${catalina.base}\logs folder.
When using the same steps with Tomcat 7.0.23, all the logs are stored into
C:\Tomact7\logs.
Did I something wrong in the service installation?
Thanks,
Best Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.21: BufferOverflowException in AjpAprProcessor.output()
Hi Christopher, thanks for your reply. I would like to add that the Exceptions seems to have occured when the client aborted the connection, because at the same time of the exception, in the ISAPI log was the following: [Wed Sep 14 13:55:20.645 2011] [736:7288] [error] iis_write::jk_isapi_plugin.c (1337): Vector write of chunk encoded response failed with 995 (0x03e3) However it's still a bit strange, and I didn't see this Exception in previous versions of Tomcat, when a 995 error appeared in the ISAPI log. -Original-Nachricht- Von: Christopher Schultz ch...@christopherschultz.net An: Tomcat Users List users@tomcat.apache.org Betreff: Re: Tomcat 7.0.21: BufferOverflowException in AjpAprProcessor.output() Datum: Wed, 14 Sep 2011 23:57:45 +0200 Are you using unusually large requests, possibly including chains of client certs? If you mean SSL certificates: I don't have any SSL certificate / HTTPS connection on Tomcat. I just use a normal AJP-APR connector and clients connect to IIS through HTTP. Sometimes I send large requests, but I wouldn't expect such an Exception to occur. If you have a lot of info that needs to be forwarded from the proxy to Tomcat, you can exceed the max packet size of the connector, and it's possible you could get this exception (instead of a nicer error message). The default is 8k, so if you have large amounts of requests data, you could be overflowing this packet size. Have you set packetSize on your Connector? Have you set max_packet_size on any of your workers? If so, the worker.max_packet_size and Connector packetSize=... must agree. I don't have set any of these attributes; I just use the default settings (besides the port). My Connector element is this: Connector port=8019 protocol=AJP/1.3 redirectPort=8743 URIEncoding=UTF-8 / My workers.properties from the ISAPI redirector contains this: # Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8019 Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.21: BufferOverflowException in AjpAprProcessor.output()
Hi, I'm using Tomcat 7.0.21 with Native 1.1.22 and AJP-APR connector on Windows Server 2008 (32 bit) with Java 1.7.0, using ISAPI Connector 1.2.32 for IIS 7. When I looked into the log today, I found two occurrencies of a BufferOverflowException: Sep 14, 2011 1:55:20 PM org.apache.coyote.ajp.AjpAprProcessor process Schwerwiegend: Error processing request java.nio.BufferOverflowException at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:343) at org.apache.coyote.ajp.AjpAprProcessor.output(AjpAprProcessor.java:273) at org.apache.coyote.ajp.AbstractAjpProcessor$SocketOutputBuffer.doWrite(AbstractAjpProcessor.java:1082) at org.apache.coyote.Response.doWrite(Response.java:533) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:368) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:437) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:321) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:276) at org.apache.catalina.connector.Response.finishResponse(Response.java:502) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:432) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:185) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1773) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) I've never seen those before. What do these exceptions mean? (Why would Tomcat write over the limit of an ByteBuffer?) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet 3.0 File Upload
Hi Chris, It seems dangerous to allow the client to specify the file name. All kinds of bad things can happen such as specifying special file names (does PRN still work in win32? through Java?) or overwriting files from other clients. I would highly recommend that some portion of the temporary file name be completely random, as well as using something keyed on the request to disambiguate the file as well. did you read my other reply to that thread? ;-) Of course, I don't use that filename to save that file on the server (I assumed it is completely clear that one wouldn't do this). But I want to use the filename for displaying purposes. E.g., I have a web application where the user can upload pictures, combined to a picture gallery (http://bildergalerie.pleier-it.de/ , it is a German site however, using TC 7). On uploading, the server reads the submitted filename and stores it in a field in the corresponding DB entry (without the file ending). Then it generates a filename based on the DB Row-ID (not on the filename) to actually store that image. When the user visits the site, it displays miniature icons, using the filename field of the DB entry as description. Or, if the user choses to download the file, I can append a Content-Disposition header (javax.mail.internet.ContentDisposition) and set a filename parameter, so the user's browser download dialog can display the original filename (or a new name, if he edited the entry), without the actual URL having to contain that filename. :) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple errors (regressions) on Tomcat 7.0.17
On 04/07/2011 16:56, Mark Thomas wrote: The problem has been found and fixed. I'm leaning towards stopping the 7.0.17 release and re-starting with a 7.0.18 tag. Mark Thanks a lot! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hi Tim, This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 If you can capture a TRACE level log form the Tomcat Connector (configure in isapi_redirect.properties) and attach it to the bug, I'll take a look. cheers tim Thanks! I will attach a Trace level log from the Redirector there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
No response buffering in Tomcat 7.0.6?
Good afternoon, some weeks ago, I posted a question about the ISAPI redirector using chunked encoding for 304 responses (Topic: Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status) which created invalid responses. These issues were fixed in Tomcat 7.0.6 and not yet released Tomcat Connectors 1.2.32 (thanks to the Tomcat devs, see https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 and https://issues.apache.org/bugzilla/show_bug.cgi?id=50413). However, when I tried the new Tomcat 7.0.6 these days, I got again a strange issue regarding 304 responses with ISAPI redirector. It seems that Tomcat 7.0.6 doesn't use a output buffer any more. Consider this simple jsp: %= hello! % Running the jsp in Tomcat 7.0.5, the request and response look like this: GET /simple.jsp HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=0AFC2875C06A962DF8A02DE6A780F721; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Content-Length: 6 Date: Thu, 13 Jan 2011 21:16:23 GMT hello! (note the Content-Lengh header, which indicates that the output has been buffered). However, running in Tomcat 7.0.6, the response look like this: GET /simple.jsp HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=2C176DBAC054D5BBF3D99FBE5C026915; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 13 Jan 2011 21:23:19 GMT 6 hello! 0 i.e. chunked encoding is applied to the response, although it should easily fit into the output buffer. Now, the same is used for 304 Not Modified responses when accessing static content. Normally, when the DefaultServlet returns a 304 status because the requestet resource has not modified, it writes a content-length: 0 header, but it is removed by the Tomcat HTTP connector (according to Tim Whittington's description). However the ISAPI redirector did not remove the header, and the response looked like this: HTTP/1.1 304 Not Modified ETag: W/13614-1291405552000 Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Thu, 13 Jan 2011 21:27:06 GMT Content-Length: 0 This was still a valid response. But with Tomcat 7.0.6, using the ISAPI redirector with chunked encoding support enabled, I get the following response: HTTP/1.1 304 Not Modified Transfer-Encoding: chunked ETag: W/13614-1291405552000 Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Thu, 13 Jan 2011 21:27:06 GMT 0 which is invalid. The issue is fixed for the next version of the ISAPI redirector (1.2.32), but it is not released yet, so I can't use the new version. Disabling chunked encoding would solve the invalid response symptom, but I would like to continue using use chunked encoding. Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)? Thanks, Konstantin Preisser - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
