Project

General

Profile

Actions

Support #1836

open

IOException on WebResponse.flush() when using animations

Added by Jan Goyvaerts almost 11 years ago. Updated over 10 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/12/2013
Due date:
% Done:

0%

Estimated time:

Description

I'm getting the mentioned exception when adding a widget with an animation. The debugger shows the call to animateShow() succeeds nonetheless.

It works when calling show(). But then of course without the animation.

Better not just gobble the error in WebResponse.flush() because there's no way to know - hence to report - an error condition. Why not just let it bubble up to WApplication.notify() ?

The behavior is consistent in both Chrome 26 and FF 20. Running the JWt 3.3.0.

=

Code sample

final WContainerWidget widget = new WContainerWidget();

widget.setPositionScheme(PositionScheme.Fixed);

widget.addWidget(....);

widget.clicked().addListener(widget, new Signal.Listener() {

@Override

public void trigger() {

widget.remove();

}

});

widget.hide();

getRoot().addWidget(widget);

widget.animateShow(new WAnimation(WAnimation.AnimationEffect.SlideInFromTop)); <== works when doing widget.show()

=

Stack trace

ClientAbortException: java.net.SocketException: Broken pipe

at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:346)

at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:306)

at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:101)

at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:278)

at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)

at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)

at eu.webtoolkit.jwt.servlet.WebResponse.flush(WebResponse.java:143)

at eu.webtoolkit.jwt.WebSession.serveResponse(WebSession.java:1773)

at eu.webtoolkit.jwt.WebSession.render(WebSession.java:1736)

at eu.webtoolkit.jwt.WebSession.notify(WebSession.java:204)

at eu.webtoolkit.jwt.WApplication.notify(WApplication.java:2790)

at com.noesis.optimus.web.Optimus.notify(Optimus.java:158)

at eu.webtoolkit.jwt.WebSession.handleRequest(WebSession.java:1540)

at eu.webtoolkit.jwt.WtServlet.doHandleRequest(WtServlet.java:351)

at eu.webtoolkit.jwt.ServletApi.handleRequest(ServletApi.java:27)

at eu.webtoolkit.jwt.ServletApi3.doHandleRequest(ServletApi3.java:98)

at eu.webtoolkit.jwt.WtServlet.handleRequest(WtServlet.java:245)

at eu.webtoolkit.jwt.WtServlet.doPost(WtServlet.java:261)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)

at com.noesis.optimus.web.Main.service(Main.java:56)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:186)

at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)

at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)

at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)

at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:123)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

at org.apache.catalina.core.StandardHostValve.__invoke(StandardHostValve.java:171)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:931)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)

at java.lang.Thread.run(Thread.java:662)

Caused by: java.net.SocketException: Broken pipe

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)

at java.net.SocketOutputStream.write(SocketOutputStream.java:136)

at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215)

at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462)

at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:119)

at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:790)

at org.apache.coyote.Response.action(Response.java:173)

at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:341)

... 44 more

Actions #1

Updated by Jan Goyvaerts almost 11 years ago

Any news guys ?

Actions #2

Updated by Koen Deforche almost 11 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche
  • Target version changed from 3.3.0 to 3.3.1

Hey Jan,

I propose to log only a single line for this exception instead of the full stack trace; I am not yet sure it is never important.

Just to be sure: in this case there is no functional problem ?

Regards,

koen

Actions #3

Updated by Jan Goyvaerts almost 11 years ago

At first sight, no problem in functionality. It's just that when no animations are used, there's no stack trace either.

If it is important, I'd say the exception should be propagated. If it isn't - implying the origin is known - I think it can safely be suppressed. No ?

Actions #4

Updated by Koen Deforche over 10 years ago

  • Status changed from InProgress to Feedback
  • Target version deleted (3.3.1)

Hey Jan,

I'm reluctant to suppress this since we do not understand exactly if it never indicates a real problem.

You can always suppress it yourself in WApplication.notify()

Regards,

koen

Actions

Also available in: Atom PDF