Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
On Aug 22, 2012, at 11:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 8/21/12 10:24 AM, Miguel Gonzalez wrote: I installed tomcat 7.0.29 from the Apache website. I had issues downloading PDFs from IE, but not from Firefox or Chrome. I googled a little bit and some people suggested to downgrade to 7.0.26. But still having issues with it under IE while it works under Firefox and Chrome. Any ideas? http://www.catb.org/esr/faqs/smart-questions.html Your question is I had an app that was working and then I upgraded and it doesn't work. What might be the problem?. Well, the problem might be that the power isn't connected to your server. But you haven't provided any information that suggests what had issues downloading PDFs from IE means. What issues? What did you try? What happened when you did that? What have you attempted to do so far to fix the issue and what have you discovered? We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. Thank you, -Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
Re: Tomcat 7.x and Internet Explorer Adobe Reader plugin
On Aug 22, 2012, at 3:55 PM, Stefan Mayr wrote: Am 22.08.2012 22:31, schrieb Miguel González Castaños: We are having what sounds like a similar problem (although 7.0.26 works for us) and can provide our details. We are using Solaris 10, Tomcat 7.0.26, Apache/2.2.16, mod_jk/1.2.35 and Java(TM) SE Runtime Environment (build 1.6.0_30-b12) in our production environment. We are using the same except for the latest Tomcat 7.0.29 in our test environment. Recently one of our testers found that when using IE8 against our test environment she could not download PDFs (available as links on web pages) and would instead see the error A network error occurred while accessing this document on the Internet but it worked fine on the older Tomcat in production. Indeed if I roll our testing environment back to Tomcat 7.0.26, this problem does not occur. It also doesn't occur in any other browser we tried (IE9, FireFox 14.0.1 and Safari 5.1.7). I had remembered that something similar had been discussed on this list, but the archived thread looks like it went stale when it couldn't be reproduced: PDF Download problem tomcat = 7.0.27 (http://mail-archives.apache.org/mod_mbox/tomcat-users/201207.mbox/%3CCAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zq+hc8bgnn1...@mail.gmail.com%3E) A good portion of our visitors use IE8 with the 9.5.1 Adobe Reader and we have a number of PDF documents available for download so I'm hoping perhaps our different configuration to the ones previously reported might eventually lead to a fix. As I have answered to Chris, it came down that the downgrade to 7.0.26 fixed it. Only a person reports problems that with a particular PDF file so we have assumed it's an issue with his setup. I couldn't reproduce the issue as I did with 7.0.29, so it seems there is something wrong with that version. Is your setup using tcnative? Version 7.0.27 introduced an update Changelog: Update the native component of the Tomcat APR/native connector to 1.1.23 and take advantage of the simplified distribution. (mturk) Maybe you could change your HTTP connector from protocol=http (has some autodetection for apr) to protocol=org.apache.coyote.http11.Http11Protocol and retest with 7.0.29. Bye, Stefan No, we are using the AJP connector. Connector port=8009 protocol=AJP/1.3 connectionTimeout=1 maxParameterCount=1 maxThre ads=400 redirectPort=8443 / _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
JMX JVM bug workaround question
We are using Tomcat 7.0.23 with jdk1.6.0_30 on Solaris 10, mod_ajp 1.3 and Apache 2.2.21. I'm using the following code to retrieve memory information from our JMX server: ObjectName contextObjectName = new ObjectName(java.lang:type=Memory); CompositeData memoryUsage = (CompositeData)server.getAttribute(contextObjectName, HeapMemoryUsage); This works really well most of the time but we occasionally we get this exception when trying to retrieve HeapMemoryUsage: javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: committed = 1607688192 should be max = 1607270400 After some digging, I found that it is a bug in the JVM (It occurs in 1.7, too): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7100266 My questions for the list then are has anyone else come across this and, if so, how did you get around it? Is there an alternative way for retrieving used and committed memory from a JMX MBean? Thank you, -Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
Re: JMX JVM bug workaround question
On Mar 7, 2012, at 11:49 AM, Jess Holle wrote: How can this be a low priority JVM bug!?! I know. My other motive in posting this was to draw attention to it and maybe get some other folks to vote for it. :-) On 3/7/2012 11:21 AM, Konstantin Kolinko wrote: 2012/3/7 Kari Scottkari.sc...@cdw.commailto:kari.sc...@cdw.com: We are using Tomcat 7.0.23 with jdk1.6.0_30 on Solaris 10, mod_ajp 1.3 and Apache 2.2.21. I'm using the following code to retrieve memory information from our JMX server: ObjectName contextObjectName = new ObjectName(java.lang:type=Memory); CompositeData memoryUsage = (CompositeData)server.getAttribute(contextObjectName, HeapMemoryUsage); This works really well most of the time but we occasionally we get this exception when trying to retrieve HeapMemoryUsage: javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: committed = 1607688192 should be max = 1607270400 After some digging, I found that it is a bug in the JVM (It occurs in 1.7, too): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7100266 My questions for the list then are has anyone else come across this and, if so, how did you get around it? Is there an alternative way for retrieving used and committed memory from a JMX MBean? The issue seems like some threading issue when max and committed memory settings are calculated independently at different moments and fail to pass a consistency check between them. I think I would wait a while and retry, but only once. Do you check what Runtime.freeMemory(), Runtime.totalMemory() return at the same time? Maybe there is so little free memory that it is worth to worry. Just to have our bases covered, I've added code to print free/total runtime memory when the error occurs. I'll let you know if this reveals anything juicy. _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
log date formatting
We are using Tomcat 7.0.23 with jdk1.6.0_27 on Solaris 10, mod_ajp 1.3 and Apache 2.2.21 and have a logging.properties file configured with the catalina.org.apache.juli.FileHandler set to the java.util.logging.SimpleFormatter for logging. This works fine, but to appease some old scripts I need to change the format of the timestamp from this: Feb 28, 2012 2:30:30 PM org.apache.catalina.core.StandardWrapperValve invoke ... To this: 02/28 14:30:30 org.apache.catalina.core.StandardWrapperValve invoke ... Before I go nuts and create a custom formatter, I thought I would check to see if there was a way simpler way to make this change directly in the logging.properties file, like a way to configure the SimpleFormatter (a la SimpleDateFormat.format) or if there is a canned formatter out there that I could use instead. Thank you, -Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
capturing total number of active sessions
We are in the process of migrating a number of servers to Tomcat 7.0.23 and we're looking for the best way to write the total number of active sessions to a text file. Can someone point me to the documentation or sample code that explains/can do this? As a side note, is the manager safe to run in a production environment? Thank you, -Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
Re: AJP connection timeout setting/Tomcat 6 vs. 7 questions
On Dec 6, 2011, at 2:25 PM, André Warnier wrote: Kari Scott wrote: We are running Tomcat 6. 0.32 with jdk1.6.0_26 on Solaris 10, mod_ajp 1.3 and Apache 2.2.21 on all but one production server which is the same except for it's running Tomcat 7.0.21. I have some questions regarding connection timeout settings. Occasionally, when the site is busier we see jumps in the number of connections to 8009 and then that number stays high for about 30 minutes before settling back down into our average range. A thread dump shows that these connections correspond to these socket threads: TP-Processor222 daemon prio=3 tid=0x00c76400 nid=0x5669 runnable [0x8cf7f000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked 0xcb2a0eb0 (a java.io.BufferedInputStream) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:628) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:566) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:693) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:662) The problem isn't so much that they stick around, but when these first start increasing, there is a noticeable hit in performance and evidence that threads are waiting for resources. Oddly, the one trial Tomcat 7 server with the same connector, load and code never experiences this problem. We currently don't have a connectionTimeout specified for our connector so my plan is to try the following: Connector port=8009 protocol=AJP/1.3 connectionTimeout=2 redirectPort=8443 / Here are my questions: *Do I also need to set the connection_pool_timeout in the worker? Or is that the one I should be changing instead of connectionTimeout? *Is there a different time out setting I should be looking at? *Is there an easy explanation as to why Tomcat 7 never experiences this issue? I'm just wondering (o.k. hoping) that there is some magic Tomcat 7 default setting some place that we can add to our Tomcat 6 environments that can help us out until we've upgraded everything. Just a question, to add to your excellent summary above : in your front-end server configuration, what are the settings related to keep-alive ? All the servers have the following Apache settings: KeepAlive On MaxKeepAliveRequests 200 KeepAliveTimeout 15 And maybe, can you provide an example of the server.xml (comments and sensitive info removed) for both a server which experiences the issue, and for the 7.0 server which doesn't ? (paste them inside the message, the list strips most attachments). I sure can. I also removed some of the entries that were exactly the same so it's easier to see the differences: * Tomcat 7 server.xml: Server port=8005 shutdown=SHUTDOWN Service name=Catalina Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Host name=localhost appBase=webapps unpackWARs=false autoDeploy=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b resolveHosts=false/ /Host /Engine /Service /Server Tomcat 6 server.xml: Server port=8005 shutdown=SHUTDOWN Service name=Catalina Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Engine name=Catalina defaultHost=localhost Valve className=com.jamonapi.http.JAMonTomcatValve/ Host name=localhost appBase=webapps unpackWARs=false autoDeploy=false xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service /Server * So the big difference is the presence of the JaMON Valve we're using on Tomcat 6 and but accidentally forgot to put on Tomcat 7. Maybe this was a fortuitous mistake. I'll try removing it from one of our Tomcat 6 servers to see if that's the culprit. We don't need that access logging valve enabled on Tomcat 7 either, so this was a really good exercise to go through. Thanks! -kari _ Kari Scott Senior Programmer kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
AJP connection timeout setting/Tomcat 6 vs. 7 questions
We are running Tomcat 6. 0.32 with jdk1.6.0_26 on Solaris 10, mod_ajp 1.3 and Apache 2.2.21 on all but one production server which is the same except for it's running Tomcat 7.0.21. I have some questions regarding connection timeout settings. Occasionally, when the site is busier we see jumps in the number of connections to 8009 and then that number stays high for about 30 minutes before settling back down into our average range. A thread dump shows that these connections correspond to these socket threads: TP-Processor222 daemon prio=3 tid=0x00c76400 nid=0x5669 runnable [0x8cf7f000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked 0xcb2a0eb0 (a java.io.BufferedInputStream) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:628) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:566) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:693) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:662) The problem isn't so much that they stick around, but when these first start increasing, there is a noticeable hit in performance and evidence that threads are waiting for resources. Oddly, the one trial Tomcat 7 server with the same connector, load and code never experiences this problem. We currently don't have a connectionTimeout specified for our connector so my plan is to try the following: Connector port=8009 protocol=AJP/1.3 connectionTimeout=2 redirectPort=8443 / Here are my questions: *Do I also need to set the connection_pool_timeout in the worker? Or is that the one I should be changing instead of connectionTimeout? *Is there a different time out setting I should be looking at? *Is there an easy explanation as to why Tomcat 7 never experiences this issue? I'm just wondering (o.k. hoping) that there is some magic Tomcat 7 default setting some place that we can add to our Tomcat 6 environments that can help us out until we've upgraded everything. Thank you, Kari _ Kari Scott Senior Programmer kari.sc...@cdw.commailto:kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007
IllegalStateException using CompressionFilter with Tomcat 7.0.21/22
Hi,
We are running Tomcat 6. 0.32 with jdk1.6.0_26 on Solaris 10, mod_ajp and
Apache 2.2.21 in our production environment and are looking to upgrade to
Tomcat 7 but have run into a problem with the CompressionFilter (an older
version of the Amy Roh one) causing this exception:
SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw
exception [java.lang.IllegalStateException: getWriter() has already been called
for this response] with root cause
java.lang.IllegalStateException: getWriter() has already been called for this
response
at
org.apache.catalina.connector.Response.getOutputStream(Response.java:594)
at
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:199)
at
com.tirerack.filters.CompressionResponseStream.init(CompressionResponseStream.java:47)
at
com.tirerack.filters.CompressionServletResponseWrapper.createOutputStream(CompressionServletResponseWrapper.java:172)
at
com.tirerack.filters.CompressionServletResponseWrapper.getWriter(CompressionServletResponseWrapper.java:250)
at
org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:125)
at
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:118)
at
org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190)
at
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:123)
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80)
at
org.apache.jsp.upgrade_005fgarage.SetCurrentVehicle_jsp._jspService(SetCurrentVehicle_jsp.java:278)
These appear to occur when the response.sendRedirect(/page.jsp) is used on
a JSP. The error is caught and handled so the customer doesn't notice it and is
still redirected, but it sure generates a ton of log entries and I'd like to
get it fixed before proceeding with our upgrade.
I saw that another user had trouble (copied post snippet below for reference)
with the new flushBuffer() call that was added to the Response.java for
sendRedirect() in 7.0.21 and I'm guessing that's the issue here, too, but I'm
not sure how to get around it.
From what I've read, you can only use a getWriter or a getOutputStream on a
single response object, not both, and I think this error is happening because
the flushBuffer() method that was added is invoking the getWriter on line 118
(http://www.docjar.com/html/api/org/apache/jasper/runtime/JspWriterImpl.java.html)
when an output stream was already being used:
111 protected final void flushBuffer() throws IOException {
112 if (bufferSize == 0)
113 return;
114 flushed = true;
115 ensureOpen();
116 if (nextChar == 0)
117 return;
-- 118 initOut();
119 out.write(cb, 0, nextChar);
120 nextChar = 0;
121 }
122
123 private void initOut() throws IOException {
124 if (out == null) {
--125 out = response.getWriter();
126 }
127 }
We have several other filters in place and the error goes away by removing just
the CompressionFilter, so the issue is definitely in that one filter.
Since this is a pretty common filter, I'm hoping someone else has run into this
and has found a fix. Anyone?
-Kari
Begin forwarded message:
From: Jacob Champlin jac...@rentec.commailto:jac...@rentec.com
Date: September 27, 2011 1:55:39 PM CDT
To: users@tomcat.apache.orgmailto:users@tomcat.apache.org
Subject: Re: 7.0.21 Redirects failing randomly
Reply-To: Tomcat Users List
users@tomcat.apache.orgmailto:users@tomcat.apache.org
Konstantin,
Ok, so I see now why you added the flushBuffer() from spec:
http://java.sun.com/javaee/6/docs/api/javax/servlet/http/HttpServletResponse.html#sendRedirect%28java.lang.String%29
Sends a temporary redirect response to the client using the specified redirect
location URL and clears the buffer.
Its just we have been running Tomcat, for 5 years and we have lots of code that
relied on the fact that sendRedirect did not flush the buffer.
I will drop it, but going to be a while before we can go to 7.0.21.
Jacob
On 09/27/2011 02:32 PM, Jacob Champlin wrote:
Konstantin,
I believe the new flushBuffer() call you added to Response.java
sendRedirect() line #1340. Is breaking all ServletFilters but sending
buy flushing the response before filters have a chance to modify the
response.
Jacob
_
Kari Scott
Senior Programmer
kari.sc...@cdw.commailto:kari.sc...@cdw.com
CDW
5520 Research Park Drive
Madison, WI 53711
Office: 608 298 1223
Fax: 608 288 3007
Re: Issue with outofMemory in Tomcat 6.0.32
We just fixed that very same error by adding -XX:MaxPermSize=128m to our java arguments. -kari On Sep 15, 2011, at 10:07 AM, dasari@wipro.com wrote: Hi, We have tomat 6.0.32 running with three different applications and oracle 11g as database with hibernate as the persistence layer. We are facing with the following error very frequently. Any idea what could be reasons for this error. Sep 13, 2011 10:28:31 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet AxisServlet java.lang.OutOfMemoryError: PermGen space at java.lang.Throwable.getStackTraceElement(Native Method) at java.lang.Throwable.getOurStackTrace(Throwable.java:591) at java.lang.Throwable.printStackTrace(Throwable.java:510) at java.util.logging.SimpleFormatter.format(Unknown Source) at org.apache.juli.FileHandler.publish(FileHandler.java:158) at java.util.logging.Logger.log(Unknown Source) at java.util.logging.Logger.doLog(Unknown Source) at java.util.logging.Logger.logp(Unknown Source) at org.apache.juli.logging.DirectJDKLog.log(D Regards Dayakar Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _ Kari Scott Senior Programmer kari.sc...@cdw.com CDW 5520 Research Park Drive Madison, WI 53711 Office: 608 298 1223 Fax: 608 288 3007 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
