You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by AR...@bca-group.com on 2011/03/21 16:28:50 UTC
Tomcat 6.0.32, Http11NioProtocol and log poll
Hi,
I am using Tomcat 6.0.32 with the Http11NioProtocol connector to implement
long polling.
My comet processor is holding the HttpSevletResponse (After receiving a
CometEvent.BEGIN) on a queue until an event is ready to send back. When it
sends back the event, it is writing a binary stream to an applet, so I use
response.getOutputStream().write() to send data back. When writing to the
stream it is synchronized.
I close the OutputStream when finished
try {
response.setHeader("messageId", messageId);
//wrapper for the OutputStream.
auctionObjectOutput = new
AuctionObjectOutput(response.getOutputStream());
// write to OutputStream
auctionObjectOutput.writeObject(event);
} finally {
try {
//internally calls out.flush() and out.close()
auctionObjectOutput.close();
} catch (IOException ex) {
LogHandler.issueCritical(ex);
}
}
This works and I can continually long poll for new data from the Applet.
Problem:
Occasionally (like 0.1% of the time), when another web page in a second
frame reloads (Independent JSP generated from SpringController in same
container) the page loads with what appears to be the byte stream for the
applet and I get the following stack trace.
It seems from the logs that the when the framed page reloads it is somehow
retrieving a stale response object (ie. not recycled properly by the
connector). Could this happen and it this likely to be an issue?
java.lang.IllegalStateException: getOutputStream() has already been called
for this response
at
org.apache.catalina.connector.Response.getWriter(Response.java:611)
at
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:198)
at
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:112)
at
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:112)
at
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:112)
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.JspWriterImpl.write(JspWriterImpl.java:326)
at
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342)
at
org.apache.jsp.WEB_002dINF.jsp.lot_jsp._jspx_meth_c_005fforEach_005f0(lot_jsp.java:476)
at
org.apache.jsp.WEB_002dINF.jsp.lot_jsp._jspx_meth_c_005fwhen_005f0(lot_jsp.java:429)
at
org.apache.jsp.WEB_002dINF.jsp.lot_jsp._jspx_meth_c_005fchoose_005f0(lot_jsp.java:384)
at
org.apache.jsp.WEB_002dINF.jsp.lot_jsp._jspService(lot_jsp.java:116)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:386)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:229)
at
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
at
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1031)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:815)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:717)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
at
org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
at
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
at
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:406)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:343)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:97)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:100)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:78)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:35)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:187)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.session.ConcurrentSessionFilter.doFilter(ConcurrentSessionFilter.java:109)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:732)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2262)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Thanks
This email and any attachments to it may contain confidential information intended
for the addressee only. If you are not the intended addressee, you are strictly
prohibited from disclosing, copying, distributing or using this email in any way.
Unauthorised use of the information contained in this email is unlawful. If you have
received this email in error please notify us on enquiries@bca-group.com and delete
the email from your system.
Information contained in this email can not be disclosed, copied, distributed or used
in any way without the prior consent of the sender. Any opinions, advice or facts
given in this email are given without warranty or the intention to enter into an
agreement unless specifically stated and confirmed by agreement, letter or such other
documentation signed by an authorised signatory of BCA Holdings Limited or any of its
subsidiary companies.
Any personal information contained in this email is strictly the view of the sender
and is in no way authorised or attributable to BCA Holdings Limited or any of its
subsidiary companies in any way. All emails through the company gateway are subject
to monitoring. The company cannot be held liable for any errors or viruses contained
in this message.
BCA (438886) Headway House, Crosby Way, Farnham, Surrey GU9 7XG, England
VAT registration number: GB 188 1552 38
#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared
by NetIQ MailMarshal
#####################################################################################
Re: Tomcat 6.0.32, Http11NioProtocol and log poll
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
On 3/21/2011 10:55 AM, AReid@bca-group.com wrote:
> I don't think I do this but I'm double-checking. Thanks.
>
> After writing to the OutputStream, should I just close the OutputStream
> which seems to generate a CometEvent.CLOSE or explicitly call
> event.close() after closing the stream?
yes, explicitly call event.close
Filip
> Thanks, Adam
>
>
>
>
> "Caldarale, Charles R"<Ch...@unisys.com>
> 21/03/2011 15:47
> Please respond to
> "Tomcat Users List"<us...@tomcat.apache.org>
>
>
> To
> Tomcat Users List<us...@tomcat.apache.org>
> cc
>
> Subject
> RE: Tomcat 6.0.32, Http11NioProtocol and log poll
>
>
>
>
>
>
>> From: AReid@bca-group.com [mailto:AReid@bca-group.com]
>> Subject: Tomcat 6.0.32, Http11NioProtocol and log poll
>> Occasionally (like 0.1% of the time), when another web page
>> in a second frame reloads (Independent JSP generated from
>> SpringController in same container) the page loads with what
>> appears to be the byte stream for the applet
> This is pretty much always caused by an application coding error: keeping
> request information at the wrong scoping level. For example, if you save
> anything about a specific request as a session attribute, other requests
> may accidentally use it or overwrite it, causing this kind of confusing.
> Keeping request-specific information in static fields is another typical
> example.
>
> Nothing absolutely rules out a Tomcat bug, but the odds are against it.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> This email and any attachments to it may contain confidential information intended
> for the addressee only. If you are not the intended addressee, you are strictly
> prohibited from disclosing, copying, distributing or using this email in any way.
> Unauthorised use of the information contained in this email is unlawful. If you have
> received this email in error please notify us on enquiries@bca-group.com and delete
> the email from your system.
>
> Information contained in this email can not be disclosed, copied, distributed or used
> in any way without the prior consent of the sender. Any opinions, advice or facts
> given in this email are given without warranty or the intention to enter into an
> agreement unless specifically stated and confirmed by agreement, letter or such other
> documentation signed by an authorised signatory of BCA Holdings Limited or any of its
> subsidiary companies.
>
> Any personal information contained in this email is strictly the view of the sender
> and is in no way authorised or attributable to BCA Holdings Limited or any of its
> subsidiary companies in any way. All emails through the company gateway are subject
> to monitoring. The company cannot be held liable for any errors or viruses contained
> in this message.
>
> BCA (438886) Headway House, Crosby Way, Farnham, Surrey GU9 7XG, England
> VAT registration number: GB 188 1552 38
>
> #####################################################################################
> This e-mail message has been scanned for Viruses and Content and cleared
> by NetIQ MailMarshal
> #####################################################################################
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3520 - Release Date: 03/21/11
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6.0.32, Http11NioProtocol and log poll
Posted by AR...@bca-group.com.
I don't think I do this but I'm double-checking. Thanks.
After writing to the OutputStream, should I just close the OutputStream
which seems to generate a CometEvent.CLOSE or explicitly call
event.close() after closing the stream?
Thanks, Adam
"Caldarale, Charles R" <Ch...@unisys.com>
21/03/2011 15:47
Please respond to
"Tomcat Users List" <us...@tomcat.apache.org>
To
Tomcat Users List <us...@tomcat.apache.org>
cc
Subject
RE: Tomcat 6.0.32, Http11NioProtocol and log poll
> From: AReid@bca-group.com [mailto:AReid@bca-group.com]
> Subject: Tomcat 6.0.32, Http11NioProtocol and log poll
> Occasionally (like 0.1% of the time), when another web page
> in a second frame reloads (Independent JSP generated from
> SpringController in same container) the page loads with what
> appears to be the byte stream for the applet
This is pretty much always caused by an application coding error: keeping
request information at the wrong scoping level. For example, if you save
anything about a specific request as a session attribute, other requests
may accidentally use it or overwrite it, causing this kind of confusing.
Keeping request-specific information in static fields is another typical
example.
Nothing absolutely rules out a Tomcat bug, but the odds are against it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
This email and any attachments to it may contain confidential information intended
for the addressee only. If you are not the intended addressee, you are strictly
prohibited from disclosing, copying, distributing or using this email in any way.
Unauthorised use of the information contained in this email is unlawful. If you have
received this email in error please notify us on enquiries@bca-group.com and delete
the email from your system.
Information contained in this email can not be disclosed, copied, distributed or used
in any way without the prior consent of the sender. Any opinions, advice or facts
given in this email are given without warranty or the intention to enter into an
agreement unless specifically stated and confirmed by agreement, letter or such other
documentation signed by an authorised signatory of BCA Holdings Limited or any of its
subsidiary companies.
Any personal information contained in this email is strictly the view of the sender
and is in no way authorised or attributable to BCA Holdings Limited or any of its
subsidiary companies in any way. All emails through the company gateway are subject
to monitoring. The company cannot be held liable for any errors or viruses contained
in this message.
BCA (438886) Headway House, Crosby Way, Farnham, Surrey GU9 7XG, England
VAT registration number: GB 188 1552 38
#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared
by NetIQ MailMarshal
#####################################################################################
RE: Tomcat 6.0.32, Http11NioProtocol and log poll
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: AReid@bca-group.com [mailto:AReid@bca-group.com]
> Subject: Tomcat 6.0.32, Http11NioProtocol and log poll
> Occasionally (like 0.1% of the time), when another web page
> in a second frame reloads (Independent JSP generated from
> SpringController in same container) the page loads with what
> appears to be the byte stream for the applet
This is pretty much always caused by an application coding error: keeping request information at the wrong scoping level. For example, if you save anything about a specific request as a session attribute, other requests may accidentally use it or overwrite it, causing this kind of confusing. Keeping request-specific information in static fields is another typical example.
Nothing absolutely rules out a Tomcat bug, but the odds are against it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org