Re: Tomcat 8.0.17 output buffer issues
On 22/01/2015 11:48, Mark Thomas wrote: > On 21/01/2015 22:40, Shaun Morton wrote: >> We will be creating a .jsp and putting it in a .war for you. Should be >> tomorrow. > > The issue is confirmed. We are working on the fix and a new 8.0.x > release now. The 8.0.18 release candidate has been made available for testing and voting. This is NOT the official release at this point. Details on where to get the release candidate and the VOTE thread for the release can be found on the dev list. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 22:40, Shaun Morton wrote:
> We will be creating a .jsp and putting it in a .war for you. Should be
> tomorrow.
The issue is confirmed. We are working on the fix and a new 8.0.x
release now.
Mark
>
> Shaun Morton
> Legal Files Software
> 217-726-6000 Ext. 341
> sh...@legalfiles.com
> www.legalfiles.com
>
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, January 21, 2015 4:00 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 8.0.17 output buffer issues
>
> On 21/01/2015 21:51, Shaun Morton wrote:
>> Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
>>
>> The 8080 connector is the default out of the installation. I try to stick
>> to defaults for trouble shooting purposes.
>
> I must confess I suspected the two were related as well when I read your
> mail. Since you are being far more responsive that the OP that filed that
> bug, my current plan is to fix the issue you are seeing and then evaluate BZ
> 57476 in light of what we discover the root cause of this issue is.
>
> I will say that 8.0.18 is likely to appear fairly soon after we track this
> one down.
>
> So, my question to you is this. With a clean 8.0.17 install, that is the
> easiest way to reproduce this bug? Ideally, if you could provide the simplest
> possible JSP that triggers this that would be great. (Since we are assuming
> the reports are linked, just attach it to that BZ report.)
>
> Cheers,
>
> Mark
>
>>
>> Shaun Morton
>> Legal Files Software
>> 217-726-6000 Ext. 341
>> sh...@legalfiles.com
>> www.legalfiles.com
>>
>> -----Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Wednesday, January 21, 2015 3:45 PM
>> To: Tomcat Users List
>> Subject: Re: Tomcat 8.0.17 output buffer issues
>>
>> Shaun,
>>
>> On 1/21/15 4:23 PM, Shaun Morton wrote:
>>> After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
>>> was not loading completely in the end users web browser. The server
>>> side was processing everything but never fully getting to end user.
>>> We see that the response is not complete via Developer mode in IE.
>>
>> Does it look at all like this:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
>>
>> -chris
>>
>>> After much research through the Tomcat 8.0.17/8.016 Change Log we
>>> could not find anything specific on this nor anything on the web.
>>
>>> After some trial and error we came up with a solution, but not an
>>> acceptable solution for all our customers.
>>
>>> If I add the following to either our web.xml or Tomcats default
>>> web.xml for the
>>> org.apache.catalina.servlets.DefaultServlet>> l
>>> ass>
>>> we are working again:
>>
>>> output
>>> 64000
>>
>>> Basically we are looking for why we have to increase the output
>>> buffer for 8.0.17 and if there is something else we can do to not
>>> specify the output buffer size. Why the default output buffer size
>>> is no longer working with Tomcat 8.0.17. This is the first time we
>>> have ran into this issue with Tomcat.
>>
>>> 80% of our customers use Tomcat and it is what we recommend from a
>>> business standpoint.
>>
>>> We also think but can't be 100% that this is causing the issue when
>>> the .java is getting complied: } catch (java.lang.Throwable t) { if
>>> (!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
>>> _jspx_out; if (out != null && out.getBufferSize() != 0) try { if
>>> (response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
>>> } catch (java.io.IOException e) {} if (_jspx_page_context != null)
>>> _jspx_page_context.handlePageException(t); else throw new
>>> ServletException(t); } } finally {
>>> _jspxFactory.releasePageContext(_jspx_page_context); } } }
>>
>>> If we add this to our .jsp it fixes it: out.flush();
>>
>>> OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
>>> 64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
>>> IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
>>> completely uninstalled and directory deleted before install of
>>> 8.0.17)
>>
>>> I apologize up front as I am new to this support email group.
>>
>>> Shaun Morton
>>
>>> --
Re: Tomcat 8.0.17 output buffer issues
2015-01-22 0:23 GMT+03:00 Shaun Morton : > After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software was not > loading completely in the end users web browser. The server side was > processing everything but never fully getting to end user. We see that the > response is not complete via Developer mode in IE. > > After much research through the Tomcat 8.0.17/8.016 Change Log we could not > find anything specific on this nor anything on the web. > > After some trial and error we came up with a solution, but not an acceptable > solution for all our customers. > > If I add the following to either our web.xml or Tomcats default web.xml for > the > org.apache.catalina.servlets.DefaultServlet we > are working again: > > > output > 64000 > > > Basically we are looking for why we have to increase the output buffer for > 8.0.17 and if there is something else we can do to not specify the output > buffer size. Why the default output buffer size is no longer working with > Tomcat 8.0.17. > This is the first time we have ran into this issue with Tomcat. > [...] A simple test for delivery of files with DefaultServlet - I see no issues. My test: 1) Remove all files from ROOT webapp and put the following into ROOT/WEB-INF/web.xml to enable listings in DefaultServlet: [[[ http://xmlns.jcp.org/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"; version="3.1" metadata-complete="true"> Welcome to Tomcat Welcome to Tomcat default org.apache.catalina.servlets.DefaultServlet debug 0 listings true 1 ]]] 2) Copy Tomcat v8.0.17 files into the ROOT webapp to use them as payload for the test. (It was an svn checkout of v8.0.17 directory from dist.a.o) 3) Configure connectors in conf/server.xml Uncomment HTTPS connector, create server certificate with Java. Set protocol attribute on Connectors to select their implementations. I had to add the following attribute to HTTPS connecor: sslEnabledProtocols="TLSv1,SSLv2Hello" My wget version is old and won't connect unless SSLv2Hello is enabled. 4) wget -r --no-parent -e robots=off --level inf http://localhost:8080/ wget -r --no-parent -e robots=off --level inf --no-check-certificate https://localhost:8443/ 5) Check *.md5 checksums for downloaded files. Result: all downloads are OK. I am using 32-bit JDK 7u72 on Windows 7. I tested HTTP+(BIO,NIO,APR), HTTPS+(BIO,NIO). I have not tested HTTPS+APR and AJP+anything. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
Both have the same problem. Shaun Morton > On Jan 21, 2015, at 5:09 PM, Christopher Schultz > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Shaun, > >> On 1/21/15 6:04 PM, Shaun Morton wrote: >> Chris, >> >> I apologize, I thought I had to specify the other classes. I do not >> have the Tomcat native library installed and it looks to be >> http-nio, here are the log entries: >> >> 21-Jan-2015 15:44:17.118 INFO [main] >> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >> ["http-nio-8080"] 21-Jan-2015 15:44:17.118 INFO [main] >> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >> ["http-bio-8443"] 21-Jan-2015 15:44:17.118 INFO [main] >> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >> ["ajp-nio-8009"] 21-Jan-2015 15:44:17.118 INFO [main] >> org.apache.catalina.startup.Catalina.start Server startup in 2547 >> ms > > Okay, and HTTP versus HTTPS doesn't matter? Both are exhibiting this > problem? > > - -chris > >> -----Original Message- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, >> 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 >> output buffer issues >> >> Shaun, >> >>> On 1/21/15 5:27 PM, Shaun Morton wrote: >>> Just so you know we are only using class Http11Protocol not >>> Http11NioProtocol or Http11AprProtocol. >> >>> This is our connector port which is also the default: >> port="8080" protocol="HTTP/1.1" connectionTimeout="2" >>> redirectPort="8443" /> >> >> This will auto-select between the NIO and APR connectors. If you >> have the Tomcat native library available to Tomcat, then it will >> default to using the APR connector. If not, the default is the NIO >> connector. >> >> Can you tell us which one you are using? You can confirm this by >> looking at the startup log messages. For instance, when I start my >> Tomcat, I get messages about the connectors like this: >> >> Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start >> INFO: Starting ProtocolHandler ["ajp-nio-8215"] Jan 12, 2015 >> 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting >> ProtocolHandler ["http-nio-127.0.0.1-8217"] >> >> That indicates that I'm running one AJP-NIO connector and one >> HTTP-NIO handler. Your startup logs will tell you which is being >> effectively auto-selected. >> >> Thanks, -chris >> >>> -Original Message- From: Christopher Schultz >>> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January >>> 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 >>> output buffer issues >> >>> Mark, >> >>>> On 1/21/15 4:59 PM, Mark Thomas wrote: >>>>> On 21/01/2015 21:51, Shaun Morton wrote: >>>>> Sorry no, it happens on both connectors, 8080(HTTP) and >>>>> 8443(HTTPS). >>>>> >>>>> The 8080 connector is the default out of the installation. I >>>>> try to stick to defaults for trouble shooting purposes. >> >>>> I must confess I suspected the two were related as well when I >>>> read your mail. Since you are being far more responsive that >>>> the OP that filed that bug, my current plan is to fix the issue >>>> you are seeing and then evaluate BZ 57476 in light of what we >>>> discover the root cause of this issue is. >> >>>> I will say that 8.0.18 is likely to appear fairly soon after we >>>> track this one down. >> >>>> So, my question to you is this. With a clean 8.0.17 install, >>>> that is the easiest way to reproduce this bug? Ideally, if you >>>> could provide the simplest possible JSP that triggers this that >>>> would be great. (Since we are assuming the reports are linked, >>>> just attach it to that BZ report.) >> >>> FWIW, I'm using 8.0.17 in development with no ill effects. >> >>> Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release >>> candidate, identical to released version) Debian Linux 7.0, >>> 2.6.32 kernel Connector configuration: >> >>> >> protocol="org.apache.coyote.ajp.AjpNioProtocol" >>> URIEncoding="UTF-8" executo
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 6:04 PM, Shaun Morton wrote: > Chris, > > I apologize, I thought I had to specify the other classes. I do not > have the Tomcat native library installed and it looks to be > http-nio, here are the log entries: > > 21-Jan-2015 15:44:17.118 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["http-nio-8080"] 21-Jan-2015 15:44:17.118 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["http-bio-8443"] 21-Jan-2015 15:44:17.118 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["ajp-nio-8009"] 21-Jan-2015 15:44:17.118 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 2547 > ms Okay, and HTTP versus HTTPS doesn't matter? Both are exhibiting this problem? - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, > 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 > output buffer issues > > Shaun, > > On 1/21/15 5:27 PM, Shaun Morton wrote: >> Just so you know we are only using class Http11Protocol not >> Http11NioProtocol or Http11AprProtocol. > >> This is our connector port which is also the default: > port="8080" protocol="HTTP/1.1" connectionTimeout="2" >> redirectPort="8443" /> > > This will auto-select between the NIO and APR connectors. If you > have the Tomcat native library available to Tomcat, then it will > default to using the APR connector. If not, the default is the NIO > connector. > > Can you tell us which one you are using? You can confirm this by > looking at the startup log messages. For instance, when I start my > Tomcat, I get messages about the connectors like this: > > Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["ajp-nio-8215"] Jan 12, 2015 > 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting > ProtocolHandler ["http-nio-127.0.0.1-8217"] > > That indicates that I'm running one AJP-NIO connector and one > HTTP-NIO handler. Your startup logs will tell you which is being > effectively auto-selected. > > Thanks, -chris > >> -Original Message- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January >> 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 >> output buffer issues > >> Mark, > >> On 1/21/15 4:59 PM, Mark Thomas wrote: >>> On 21/01/2015 21:51, Shaun Morton wrote: >>>> Sorry no, it happens on both connectors, 8080(HTTP) and >>>> 8443(HTTPS). >>>> >>>> The 8080 connector is the default out of the installation. I >>>> try to stick to defaults for trouble shooting purposes. > >>> I must confess I suspected the two were related as well when I >>> read your mail. Since you are being far more responsive that >>> the OP that filed that bug, my current plan is to fix the issue >>> you are seeing and then evaluate BZ 57476 in light of what we >>> discover the root cause of this issue is. > >>> I will say that 8.0.18 is likely to appear fairly soon after we >>> track this one down. > >>> So, my question to you is this. With a clean 8.0.17 install, >>> that is the easiest way to reproduce this bug? Ideally, if you >>> could provide the simplest possible JSP that triggers this that >>> would be great. (Since we are assuming the reports are linked, >>> just attach it to that BZ report.) > >> FWIW, I'm using 8.0.17 in development with no ill effects. > >> Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release >> candidate, identical to released version) Debian Linux 7.0, >> 2.6.32 kernel Connector configuration: > >> > protocol="org.apache.coyote.ajp.AjpNioProtocol" >> URIEncoding="UTF-8" executor="tomcatThreadPool" /> > >> > protocol="org.apache.coyote.http11.Http11NioProtocol" >> address="127.0.0.1" secure="false" URIEncoding="UTF-8" >> executor="tomcatThreadPool" /> > >> The AJP connector is the one getting primary use through Apache >> httpd and mod_jk. The HTTP connector is used for loopback >> requests from another service also running under a similar >> configuration. > >> We are using almost no JSP resources at all. I quickly tested one >> of our JSPs and it seems to
RE: Tomcat 8.0.17 output buffer issues
Chris, I apologize, I thought I had to specify the other classes. I do not have the Tomcat native library installed and it looks to be http-nio, here are the log entries: 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-bio-8443"] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"] 21-Jan-2015 15:44:17.118 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 2547 ms Shaun Morton Legal Files Software 217-726-6000 Ext. 341 sh...@legalfiles.com www.legalfiles.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:54 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: > Just so you know we are only using class Http11Protocol not > Http11NioProtocol or Http11AprProtocol. > > This is our connector port which is also the default: port="8080" protocol="HTTP/1.1" connectionTimeout="2" > redirectPort="8443" /> This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-nio-8215"] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-8217"] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, > 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output > buffer issues > > Mark, > > On 1/21/15 4:59 PM, Mark Thomas wrote: >> On 21/01/2015 21:51, Shaun Morton wrote: >>> Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). >>> >>> The 8080 connector is the default out of the installation. I try to >>> stick to defaults for trouble shooting purposes. > >> I must confess I suspected the two were related as well when I read >> your mail. Since you are being far more responsive that the OP that >> filed that bug, my current plan is to fix the issue you are seeing >> and then evaluate BZ 57476 in light of what we discover the root >> cause of this issue is. > >> I will say that 8.0.18 is likely to appear fairly soon after we track >> this one down. > >> So, my question to you is this. With a clean 8.0.17 install, that is >> the easiest way to reproduce this bug? Ideally, if you could provide >> the simplest possible JSP that triggers this that would be great. >> (Since we are assuming the reports are linked, just attach it to that >> BZ report.) > > FWIW, I'm using 8.0.17 in development with no ill effects. > > Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, > identical to released version) Debian Linux 7.0, 2.6.32 kernel > Connector configuration: > > protocol="org.apache.coyote.ajp.AjpNioProtocol" > URIEncoding="UTF-8" executor="tomcatThreadPool" /> > > protocol="org.apache.coyote.http11.Http11NioProtocol" > address="127.0.0.1" secure="false" URIEncoding="UTF-8" > executor="tomcatThreadPool" /> > > The AJP connector is the one getting primary use through Apache httpd > and mod_jk. The HTTP connector is used for loopback requests from > another service also running under a similar configuration. > > We are using almost no JSP resources at all. I quickly tested one of > our JSPs and it seems to work file. The response size is 39,777 bytes, > content type is application/xhtml+xml, and there is no explicit buffer > size set in the .jsp source. > > -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.a
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shaun, On 1/21/15 5:27 PM, Shaun Morton wrote: > Just so you know we are only using class Http11Protocol not > Http11NioProtocol or Http11AprProtocol. > > This is our connector port which is also the default: port="8080" protocol="HTTP/1.1" connectionTimeout="2" > redirectPort="8443" /> This will auto-select between the NIO and APR connectors. If you have the Tomcat native library available to Tomcat, then it will default to using the APR connector. If not, the default is the NIO connector. Can you tell us which one you are using? You can confirm this by looking at the startup log messages. For instance, when I start my Tomcat, I get messages about the connectors like this: Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-nio-8215"] Jan 12, 2015 3:52:08 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-8217"] That indicates that I'm running one AJP-NIO connector and one HTTP-NIO handler. Your startup logs will tell you which is being effectively auto-selected. Thanks, - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, > 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 > output buffer issues > > Mark, > > On 1/21/15 4:59 PM, Mark Thomas wrote: >> On 21/01/2015 21:51, Shaun Morton wrote: >>> Sorry no, it happens on both connectors, 8080(HTTP) and >>> 8443(HTTPS). >>> >>> The 8080 connector is the default out of the installation. I >>> try to stick to defaults for trouble shooting purposes. > >> I must confess I suspected the two were related as well when I >> read your mail. Since you are being far more responsive that the >> OP that filed that bug, my current plan is to fix the issue you >> are seeing and then evaluate BZ 57476 in light of what we >> discover the root cause of this issue is. > >> I will say that 8.0.18 is likely to appear fairly soon after we >> track this one down. > >> So, my question to you is this. With a clean 8.0.17 install, that >> is the easiest way to reproduce this bug? Ideally, if you could >> provide the simplest possible JSP that triggers this that would >> be great. (Since we are assuming the reports are linked, just >> attach it to that BZ report.) > > FWIW, I'm using 8.0.17 in development with no ill effects. > > Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, > identical to released version) Debian Linux 7.0, 2.6.32 kernel > Connector configuration: > > protocol="org.apache.coyote.ajp.AjpNioProtocol" > URIEncoding="UTF-8" executor="tomcatThreadPool" /> > > protocol="org.apache.coyote.http11.Http11NioProtocol" > address="127.0.0.1" secure="false" URIEncoding="UTF-8" > executor="tomcatThreadPool" /> > > The AJP connector is the one getting primary use through Apache > httpd and mod_jk. The HTTP connector is used for loopback requests > from another service also running under a similar configuration. > > We are using almost no JSP resources at all. I quickly tested one > of our JSPs and it seems to work file. The response size is 39,777 > bytes, content type is application/xhtml+xml, and there is no > explicit buffer size set in the .jsp source. > > -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwC4DAAoJEBzwKT+lPKRYOv4P/jeUTWEvRL70rVbTY+1THsnI EpUxc3zO+EiHzqlDUuyy/2MwK6bndgecMZHsVSHq/Zd9bC8xfpbsy4m7EzgP8wTT KSCCfm2jIGBBF62e67qGkKddejEqUZ6oDXDP0XBz7ERfsYcneDcUEYTAjIC8fCOi 19/n2uyjRlmnK62SHBLC0U6AqYt0joAv/LR/YK4qHh2caGh+Y8geNIq7oBjfrMJe LgiZm+I+ZvLn9Hsdv5tRywajDFWKR8PWNgiye/tXjhdidlW+nTPrac4JIWTgU4AQ pKals71fJZh5Z3oCtVFoHY/Yz9RtWNwaJSNkv/ZEaByykgq9aHI3SzP1udShz+Be qxXzM8jWl9rd3lC8c/uSivTRtgv6/wRc6zia353Hl3ZSNqa8sO4qYnwVbZOtx1Q9 VKXmSzJbWmeNEl67ber2zeGr9zyoeajyQiO/laQeEv4JGciR2ysmKI+W8GbQ3zpv YMpqHzl8SvcKwpZons72MmjQZOSKtB3uPopzY7XYr6y5GCebUaNhXF0EtXoM8CDk tGjHTq5i/H+Oq35ZArsmGQx6oVPmATW0xCu0uUj54UlbB655YaHuQGZaRwgfpHOk VjH4qpJI/lpmnrVb3Ey0rLXGsgHFzWG7qEnotYlbeew788JgmcdVCecF39q+fBkG ijV29Rmofivmxib3vBE4 =iuNt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
We will be creating a .jsp and putting it in a .war for you. Should be
tomorrow.
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, January 21, 2015 4:00 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 21:51, Shaun Morton wrote:
> Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
>
> The 8080 connector is the default out of the installation. I try to stick to
> defaults for trouble shooting purposes.
I must confess I suspected the two were related as well when I read your mail.
Since you are being far more responsive that the OP that filed that bug, my
current plan is to fix the issue you are seeing and then evaluate BZ 57476 in
light of what we discover the root cause of this issue is.
I will say that 8.0.18 is likely to appear fairly soon after we track this one
down.
So, my question to you is this. With a clean 8.0.17 install, that is the
easiest way to reproduce this bug? Ideally, if you could provide the simplest
possible JSP that triggers this that would be great. (Since we are assuming the
reports are linked, just attach it to that BZ report.)
Cheers,
Mark
>
> Shaun Morton
> Legal Files Software
> 217-726-6000 Ext. 341
> sh...@legalfiles.com
> www.legalfiles.com
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, January 21, 2015 3:45 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 8.0.17 output buffer issues
>
> Shaun,
>
> On 1/21/15 4:23 PM, Shaun Morton wrote:
>> After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
>> was not loading completely in the end users web browser. The server
>> side was processing everything but never fully getting to end user.
>> We see that the response is not complete via Developer mode in IE.
>
> Does it look at all like this:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
>
> -chris
>
>> After much research through the Tomcat 8.0.17/8.016 Change Log we
>> could not find anything specific on this nor anything on the web.
>
>> After some trial and error we came up with a solution, but not an
>> acceptable solution for all our customers.
>
>> If I add the following to either our web.xml or Tomcats default
>> web.xml for the
>> org.apache.catalina.servlets.DefaultServlet> l
>> ass>
>> we are working again:
>
>> output
>> 64000
>
>> Basically we are looking for why we have to increase the output
>> buffer for 8.0.17 and if there is something else we can do to not
>> specify the output buffer size. Why the default output buffer size
>> is no longer working with Tomcat 8.0.17. This is the first time we
>> have ran into this issue with Tomcat.
>
>> 80% of our customers use Tomcat and it is what we recommend from a
>> business standpoint.
>
>> We also think but can't be 100% that this is causing the issue when
>> the .java is getting complied: } catch (java.lang.Throwable t) { if
>> (!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
>> _jspx_out; if (out != null && out.getBufferSize() != 0) try { if
>> (response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
>> } catch (java.io.IOException e) {} if (_jspx_page_context != null)
>> _jspx_page_context.handlePageException(t); else throw new
>> ServletException(t); } } finally {
>> _jspxFactory.releasePageContext(_jspx_page_context); } } }
>
>> If we add this to our .jsp it fixes it: out.flush();
>
>> OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
>> 64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
>> IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
>> completely uninstalled and directory deleted before install of
>> 8.0.17)
>
>> I apologize up front as I am new to this support email group.
>
>> Shaun Morton
>
>> -
>
>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
Just so you know we are only using class Http11Protocol not Http11NioProtocol or Http11AprProtocol. This is our connector port which is also the default: Shaun Morton Legal Files Software 217-726-6000 Ext. 341 sh...@legalfiles.com www.legalfiles.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 21, 2015 4:11 PM To: Tomcat Users List Subject: Re: Tomcat 8.0.17 output buffer issues -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: > On 21/01/2015 21:51, Shaun Morton wrote: >> Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS). >> >> The 8080 connector is the default out of the installation. I try to >> stick to defaults for trouble shooting purposes. > > I must confess I suspected the two were related as well when I read > your mail. Since you are being far more responsive that the OP that > filed that bug, my current plan is to fix the issue you are seeing and > then evaluate BZ 57476 in light of what we discover the root cause of > this issue is. > > I will say that 8.0.18 is likely to appear fairly soon after we track > this one down. > > So, my question to you is this. With a clean 8.0.17 install, that is > the easiest way to reproduce this bug? Ideally, if you could provide > the simplest possible JSP that triggers this that would be great. > (Since we are assuming the reports are linked, just attach it to that > BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwCPbAAoJEBzwKT+lPKRYTi0P/3sNB10wkEg4tNhMCQpDPnGK 3lDgFZUpNDkSVWv3Y+RUkpeez3KIlFaztbLfpUxDJrLyQ5xrzmZUIR0h8RanAlhh ZrAgqCCbeeloZO0OoLt5QyOD5AFXG2qrAN6f6Ia3nfZT6aLCWg146kHEggHL0c4f 4KoO6J5qgD/dX8N1XcXoxOjzrMF3oI4tgqWRpXF+TQzO7w4RBl+4cU6IC9TTEa6b 6TyrctEdVG8Mzbx/N43j95efd9eb7ByqBBaonMEMoCMZXIzNibX1e918DDOrAmnl jWmxiygCnsTa+Lim3HKBOcB7EMgfOtk1tTEx7eXYvWPIvvfWfAqnw14nU9nmjdZ5 dhbUYk0Qhny5R6urH54oMYw8vKekt5dLz4k5XVp+jMJWkPgXGORpQJrOMmLtRzoA +No5BcjkRwdDswH5ShIa0S8RJ+yyshP0T3vFiHfhlDBjAhZgqCU0EfLRpSigg4r7 9RoStJvS1hFemX2o+Rm+2kjXgSR5lyeKAUtBWyFY4a+pqGnek0P9E0HSCnmBgFZv 7wwulvjjsbCxBYp6wELFyAgfPwS8gLxcusQy4AaatMxnYsU14ohXdoMz2m86u9Fi iR27ETVR5MJ84qG1sbVylt6Xo3msVzSTtSZkAnE+ZruMZlHNfcHNqzDVLKvfDF9e bTacKbRkPEDtfoUs4b+y =jDSl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/21/15 4:59 PM, Mark Thomas wrote: > On 21/01/2015 21:51, Shaun Morton wrote: >> Sorry no, it happens on both connectors, 8080(HTTP) and >> 8443(HTTPS). >> >> The 8080 connector is the default out of the installation. I try >> to stick to defaults for trouble shooting purposes. > > I must confess I suspected the two were related as well when I read > your mail. Since you are being far more responsive that the OP that > filed that bug, my current plan is to fix the issue you are seeing > and then evaluate BZ 57476 in light of what we discover the root > cause of this issue is. > > I will say that 8.0.18 is likely to appear fairly soon after we > track this one down. > > So, my question to you is this. With a clean 8.0.17 install, that > is the easiest way to reproduce this bug? Ideally, if you could > provide the simplest possible JSP that triggers this that would be > great. (Since we are assuming the reports are linked, just attach > it to that BZ report.) FWIW, I'm using 8.0.17 in development with no ill effects. Environment: Oracle Java 1.7.0_67 Tomcat 8.0.17 (release candidate, identical to released version) Debian Linux 7.0, 2.6.32 kernel Connector configuration: The AJP connector is the one getting primary use through Apache httpd and mod_jk. The HTTP connector is used for loopback requests from another service also running under a similar configuration. We are using almost no JSP resources at all. I quickly tested one of our JSPs and it seems to work file. The response size is 39,777 bytes, content type is application/xhtml+xml, and there is no explicit buffer size set in the .jsp source. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwCPbAAoJEBzwKT+lPKRYTi0P/3sNB10wkEg4tNhMCQpDPnGK 3lDgFZUpNDkSVWv3Y+RUkpeez3KIlFaztbLfpUxDJrLyQ5xrzmZUIR0h8RanAlhh ZrAgqCCbeeloZO0OoLt5QyOD5AFXG2qrAN6f6Ia3nfZT6aLCWg146kHEggHL0c4f 4KoO6J5qgD/dX8N1XcXoxOjzrMF3oI4tgqWRpXF+TQzO7w4RBl+4cU6IC9TTEa6b 6TyrctEdVG8Mzbx/N43j95efd9eb7ByqBBaonMEMoCMZXIzNibX1e918DDOrAmnl jWmxiygCnsTa+Lim3HKBOcB7EMgfOtk1tTEx7eXYvWPIvvfWfAqnw14nU9nmjdZ5 dhbUYk0Qhny5R6urH54oMYw8vKekt5dLz4k5XVp+jMJWkPgXGORpQJrOMmLtRzoA +No5BcjkRwdDswH5ShIa0S8RJ+yyshP0T3vFiHfhlDBjAhZgqCU0EfLRpSigg4r7 9RoStJvS1hFemX2o+Rm+2kjXgSR5lyeKAUtBWyFY4a+pqGnek0P9E0HSCnmBgFZv 7wwulvjjsbCxBYp6wELFyAgfPwS8gLxcusQy4AaatMxnYsU14ohXdoMz2m86u9Fi iR27ETVR5MJ84qG1sbVylt6Xo3msVzSTtSZkAnE+ZruMZlHNfcHNqzDVLKvfDF9e bTacKbRkPEDtfoUs4b+y =jDSl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 21:51, Shaun Morton wrote:
> Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
>
> The 8080 connector is the default out of the installation. I try to stick to
> defaults for trouble shooting purposes.
I must confess I suspected the two were related as well when I read your
mail. Since you are being far more responsive that the OP that filed
that bug, my current plan is to fix the issue you are seeing and then
evaluate BZ 57476 in light of what we discover the root cause of this
issue is.
I will say that 8.0.18 is likely to appear fairly soon after we track
this one down.
So, my question to you is this. With a clean 8.0.17 install, that is the
easiest way to reproduce this bug? Ideally, if you could provide the
simplest possible JSP that triggers this that would be great. (Since we
are assuming the reports are linked, just attach it to that BZ report.)
Cheers,
Mark
>
> Shaun Morton
> Legal Files Software
> 217-726-6000 Ext. 341
> sh...@legalfiles.com
> www.legalfiles.com
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, January 21, 2015 3:45 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 8.0.17 output buffer issues
>
> Shaun,
>
> On 1/21/15 4:23 PM, Shaun Morton wrote:
>> After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
>> was not loading completely in the end users web browser. The server
>> side was processing everything but never fully getting to end user.
>> We see that the response is not complete via Developer mode in IE.
>
> Does it look at all like this:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
>
> -chris
>
>> After much research through the Tomcat 8.0.17/8.016 Change Log we
>> could not find anything specific on this nor anything on the web.
>
>> After some trial and error we came up with a solution, but not an
>> acceptable solution for all our customers.
>
>> If I add the following to either our web.xml or Tomcats default
>> web.xml for the
>> org.apache.catalina.servlets.DefaultServlet> ass>
>> we are working again:
>
>> output
>> 64000
>
>> Basically we are looking for why we have to increase the output buffer
>> for 8.0.17 and if there is something else we can do to not specify the
>> output buffer size. Why the default output buffer size is no longer
>> working with Tomcat 8.0.17. This is the first time we have ran into
>> this issue with Tomcat.
>
>> 80% of our customers use Tomcat and it is what we recommend from a
>> business standpoint.
>
>> We also think but can't be 100% that this is causing the issue when
>> the .java is getting complied: } catch (java.lang.Throwable t) { if
>> (!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
>> _jspx_out; if (out != null && out.getBufferSize() != 0) try { if
>> (response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
>> } catch (java.io.IOException e) {} if (_jspx_page_context != null)
>> _jspx_page_context.handlePageException(t); else throw new
>> ServletException(t); } } finally {
>> _jspxFactory.releasePageContext(_jspx_page_context); } } }
>
>> If we add this to our .jsp it fixes it: out.flush();
>
>> OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
>> 64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
>> IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
>> completely uninstalled and directory deleted before install of
>> 8.0.17)
>
>> I apologize up front as I am new to this support email group.
>
>> Shaun Morton
>
>> -
>
>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.0.17 output buffer issues
Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
The 8080 connector is the default out of the installation. I try to stick to
defaults for trouble shooting purposes.
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 21, 2015 3:45 PM
To: Tomcat Users List
Subject: Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
> After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
> was not loading completely in the end users web browser. The server
> side was processing everything but never fully getting to end user.
> We see that the response is not complete via Developer mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
- -chris
> After much research through the Tomcat 8.0.17/8.016 Change Log we
> could not find anything specific on this nor anything on the web.
>
> After some trial and error we came up with a solution, but not an
> acceptable solution for all our customers.
>
> If I add the following to either our web.xml or Tomcats default
> web.xml for the
> org.apache.catalina.servlets.DefaultServlet ass>
> we are working again:
>
> output
> 64000
>
> Basically we are looking for why we have to increase the output buffer
> for 8.0.17 and if there is something else we can do to not specify the
> output buffer size. Why the default output buffer size is no longer
> working with Tomcat 8.0.17. This is the first time we have ran into
> this issue with Tomcat.
>
> 80% of our customers use Tomcat and it is what we recommend from a
> business standpoint.
>
> We also think but can't be 100% that this is causing the issue when
> the .java is getting complied: } catch (java.lang.Throwable t) { if
> (!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
> _jspx_out; if (out != null && out.getBufferSize() != 0) try { if
> (response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
> } catch (java.io.IOException e) {} if (_jspx_page_context != null)
> _jspx_page_context.handlePageException(t); else throw new
> ServletException(t); } } finally {
> _jspxFactory.releasePageContext(_jspx_page_context); } } }
>
> If we add this to our .jsp it fixes it: out.flush();
>
> OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
> 64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
> IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
> completely uninstalled and directory deleted before install of
> 8.0.17)
>
> I apologize up front as I am new to this support email group.
>
> Shaun Morton
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUwB3EAAoJEBzwKT+lPKRYDZIQAJsAI/xCbrppKazK3ixEYjJG
YuaTrH5K2nwe/85t3L27PSAEfBsSSi9E2CobCfAwvLIYVTV82RNS8yYvaHGSz6Ej
cwzo2qWEHJNTCwcRSNS3TldRTQf9NDto5hf+It1e4qImNNqL8HaW/viU2SCsXMLc
racJkLFsVSh6Zo8BrJ8xv1x3D/IkkIgZVvV8zamGSst6X2Nz003BJm7yy9pb3imy
fJloTDtWfC43vF562RT/k3VpG2JX5Qvx4JjD2m41nwUFqHZUGGseOILePY0u7sNw
UsXFUcY87OyXBtvYtTcNLm9QGZqRtip4SMMZV7WaE/fs8B5RviAsmSgu1OiJeaKB
yN74nIC+BZQQsjmJifDLELn06pBqFtUe5kbMY8haOkpRG0tpu5x4GoD8ZIUtFB+T
CB1HF37YqwXVDmprlj9uPZQ1ZvG1PeqhZNOCTxLmnFTZzn53tEyV460xv3TCHwqG
M6NR4eRFHIBcP8ehusab8zV72aqTg6+v3erHJcpJ0JDXhNcDcu5w7cAhNec4uJHS
A3+6L0/f4S6vVigOXMKlluhJXECuapXsKcfAvF/sngN0Ww/PJ+X2xQ4zcD3JZMuM
aHf6NzSkfQzYyDTio3xAYwRHtIHB4vykrcxJEvZvW/rurkVw/9x9lClZ3sbDMiCI
wf/mWzCCGV6rhVKGRhME
=3wE/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
> After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
> was not loading completely in the end users web browser. The
> server side was processing everything but never fully getting to
> end user. We see that the response is not complete via Developer
> mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
- -chris
> After much research through the Tomcat 8.0.17/8.016 Change Log we
> could not find anything specific on this nor anything on the web.
>
> After some trial and error we came up with a solution, but not an
> acceptable solution for all our customers.
>
> If I add the following to either our web.xml or Tomcats default
> web.xml for the
> org.apache.catalina.servlets.DefaultServlet
> we are working again:
>
> output
> 64000
>
> Basically we are looking for why we have to increase the output
> buffer for 8.0.17 and if there is something else we can do to not
> specify the output buffer size. Why the default output buffer size
> is no longer working with Tomcat 8.0.17. This is the first time we
> have ran into this issue with Tomcat.
>
> 80% of our customers use Tomcat and it is what we recommend from a
> business standpoint.
>
> We also think but can't be 100% that this is causing the issue when
> the .java is getting complied: } catch (java.lang.Throwable t) { if
> (!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
> _jspx_out; if (out != null && out.getBufferSize() != 0) try { if
> (response.isCommitted()) { out.flush(); } else {
> out.clearBuffer(); } } catch (java.io.IOException e) {} if
> (_jspx_page_context != null)
> _jspx_page_context.handlePageException(t); else throw new
> ServletException(t); } } finally {
> _jspxFactory.releasePageContext(_jspx_page_context); } } }
>
> If we add this to our .jsp it fixes it: out.flush();
>
> OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
> 64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10
> and IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15
> was completely uninstalled and directory deleted before install of
> 8.0.17)
>
> I apologize up front as I am new to this support email group.
>
> Shaun Morton
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUwB3EAAoJEBzwKT+lPKRYDZIQAJsAI/xCbrppKazK3ixEYjJG
YuaTrH5K2nwe/85t3L27PSAEfBsSSi9E2CobCfAwvLIYVTV82RNS8yYvaHGSz6Ej
cwzo2qWEHJNTCwcRSNS3TldRTQf9NDto5hf+It1e4qImNNqL8HaW/viU2SCsXMLc
racJkLFsVSh6Zo8BrJ8xv1x3D/IkkIgZVvV8zamGSst6X2Nz003BJm7yy9pb3imy
fJloTDtWfC43vF562RT/k3VpG2JX5Qvx4JjD2m41nwUFqHZUGGseOILePY0u7sNw
UsXFUcY87OyXBtvYtTcNLm9QGZqRtip4SMMZV7WaE/fs8B5RviAsmSgu1OiJeaKB
yN74nIC+BZQQsjmJifDLELn06pBqFtUe5kbMY8haOkpRG0tpu5x4GoD8ZIUtFB+T
CB1HF37YqwXVDmprlj9uPZQ1ZvG1PeqhZNOCTxLmnFTZzn53tEyV460xv3TCHwqG
M6NR4eRFHIBcP8ehusab8zV72aqTg6+v3erHJcpJ0JDXhNcDcu5w7cAhNec4uJHS
A3+6L0/f4S6vVigOXMKlluhJXECuapXsKcfAvF/sngN0Ww/PJ+X2xQ4zcD3JZMuM
aHf6NzSkfQzYyDTio3xAYwRHtIHB4vykrcxJEvZvW/rurkVw/9x9lClZ3sbDMiCI
wf/mWzCCGV6rhVKGRhME
=3wE/
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
