Wicket
  1. Wicket
  2. WICKET-3869

ResponseIOException when ajax response contains resource reference

    Details

      Description

      When ajax response (show modal window) contains shared image response, server log reports ResponseIOException.

      See attached example application. Using maven, type mvn package jetty:run. Open http://localhost/8080/iwicket/ in Internet Explorer, click the link, watch server log (may need to open/close modal window a few times, but usually appears on first attempt).

      1. iwicket.zip
        18 kB
        Sodasmile
      2. iwicket-no-image.tgz
        16 kB
        Martin Grigorov
      3. lazyloaderror.zip
        13 kB
        Andre L
      4. internetexplorer-requests.png
        90 kB
        Andre L
      5. Eofproject.7z
        109 kB
        Ras Poutine

        Issue Links

          Activity

          Hide
          Rakesh A added a comment -

          We are using Wicket 6.12.0, and overriding "AbstractResource#flushResponseAfterHeaders(WebResponse)" and not calling super implementation to avoid flushing headers didn't solve the issue. We observed that it is more frequent in IE8 in our case.

          Show
          Rakesh A added a comment - We are using Wicket 6.12.0, and overriding "AbstractResource#flushResponseAfterHeaders(WebResponse)" and not calling super implementation to avoid flushing headers didn't solve the issue. We observed that it is more frequent in IE8 in our case.
          Hide
          Martin Grigorov added a comment -

          There is a possibility that this problem has been fixed with WICKET-5392 in master branch (7.x).
          If your application reproduces the problem then override AbstractResource#flushResponseAfterHeaders(WebResponse) to do nothing and tell us whether it helped you.

          Show
          Martin Grigorov added a comment - There is a possibility that this problem has been fixed with WICKET-5392 in master branch (7.x). If your application reproduces the problem then override AbstractResource#flushResponseAfterHeaders(WebResponse) to do nothing and tell us whether it helped you.
          Hide
          Marius van Wyk added a comment -

          I will be out of the office today - back on Wednesday 19 June. In case of emergency please contact Vincent Dupuis <VDupuis@temenos.com> else I will respond to your email tomorrow.

          Thanks

          Marius

          The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use or disclosure of the contents of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of TEMENOS. We recommend that you check this e-mail and any attachments against viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus transmitted by this e-mail.

          Show
          Marius van Wyk added a comment - I will be out of the office today - back on Wednesday 19 June. In case of emergency please contact Vincent Dupuis <VDupuis@temenos.com> else I will respond to your email tomorrow. Thanks Marius The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use or disclosure of the contents of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of TEMENOS. We recommend that you check this e-mail and any attachments against viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus transmitted by this e-mail.
          Hide
          Johan Isaksson added a comment -

          @Christian Thanks, worked fine for me to. The meta tag did not affect this issue for me either.

          Show
          Johan Isaksson added a comment - @Christian Thanks, worked fine for me to. The meta tag did not affect this issue for me either.
          Hide
          Neil added a comment -

          Yeah doesn't seem to make any difference to me. The only workaround I found to work was to make a custom ServletWebResponse as above.

          Show
          Neil added a comment - Yeah doesn't seem to make any difference to me. The only workaround I found to work was to make a custom ServletWebResponse as above.
          Hide
          Christian Rudh added a comment -

          We have had that meta tag for a long time and it doesn't affect this issue for us at least.

          Show
          Christian Rudh added a comment - We have had that meta tag for a long time and it doesn't affect this issue for us at least.
          Hide
          Martin Grigorov added a comment -

          Users on the mailing lists reported that they workaround such error with:
          <meta http-equiv="X-UA-Compatible" content="IE=edge"/>

          See http://markmail.org/thread/at7mhctll27akzj4 and http://markmail.org/thread/5sbhcqbjxxb7arwy

          Show
          Martin Grigorov added a comment - Users on the mailing lists reported that they workaround such error with: <meta http-equiv="X-UA-Compatible" content="IE=edge"/> See http://markmail.org/thread/at7mhctll27akzj4 and http://markmail.org/thread/5sbhcqbjxxb7arwy
          Hide
          Neil added a comment -

          Great, seems to work. I had to change the instanceof evaluation to ClientAbortException but once I'd done that it stopped the errors.

          Thanks for your help.

          Show
          Neil added a comment - Great, seems to work. I had to change the instanceof evaluation to ClientAbortException but once I'd done that it stopped the errors. Thanks for your help.
          Hide
          Christian Rudh added a comment -

          @Neil: Try this to supress the errors, it's an extension to the example by Jonathan that seems to work fine for me:

          public class MyWebResponse extends ServletWebResponse {

          public MyWebResponse(ServletWebRequest webRequest, HttpServletResponse httpServletResponse)

          { super(webRequest, httpServletResponse); }

          @Override
          public void write(CharSequence sequence) {
          try

          { super.write(sequence); }

          catch (ResponseIOException e) {
          if (e.getCause() != null && e.getCause() instanceof SocketException)

          { // Ignore } else { throw e; }
          }
          }

          @Override
          public void write(byte[] array) {
          try { super.write(array); } catch (ResponseIOException e) {
          if (e.getCause() != null && e.getCause() instanceof SocketException) { // Ignore }

          else

          { throw e; }
          }
          }

          @Override
          public void flush() {
          try { super.flush(); } catch (ResponseIOException e) {
          if (e.getCause() != null && e.getCause() instanceof SocketException) { // Ignore } else { throw e; }

          }
          }
          }

          Show
          Christian Rudh added a comment - @Neil: Try this to supress the errors, it's an extension to the example by Jonathan that seems to work fine for me: public class MyWebResponse extends ServletWebResponse { public MyWebResponse(ServletWebRequest webRequest, HttpServletResponse httpServletResponse) { super(webRequest, httpServletResponse); } @Override public void write(CharSequence sequence) { try { super.write(sequence); } catch (ResponseIOException e) { if (e.getCause() != null && e.getCause() instanceof SocketException) { // Ignore } else { throw e; } } } @Override public void write(byte[] array) { try { super.write(array); } catch (ResponseIOException e) { if (e.getCause() != null && e.getCause() instanceof SocketException) { // Ignore } else { throw e; } } } @Override public void flush() { try { super.flush(); } catch (ResponseIOException e) { if (e.getCause() != null && e.getCause() instanceof SocketException) { // Ignore } else { throw e; } } } }
          Hide
          Neil added a comment -

          This problem still seems to exist in 6.4. I'm using images generated from byte arrays and have to use a non-caching image (otherwise on refresh the images change to ones used on another page). This gives the following error (and I can see the abort in IE dev tools):

          2013-01-08 10:59:56 DefaultExceptionMapper [ERROR] Connection lost, give up responding.
          org.apache.wicket.protocol.http.servlet.ResponseIOException: ClientAbortException: java.io.IOException

          I have tried the workaround suggested by Jonathan Crabtree to supress the errors but I just get other errors instead:

          2013-01-08 11:02:57 DefaultExceptionMapper [ERROR] unexpected exception when handling another exception: Header was already written to response!
          java.lang.IllegalStateException: Header was already written to response!

          This problem only exists with Internet Explorer and doesn't appear to affect the functionality of the application however I need to find a way to at least supress the errors if there is no fix.

          Cheers

          Show
          Neil added a comment - This problem still seems to exist in 6.4. I'm using images generated from byte arrays and have to use a non-caching image (otherwise on refresh the images change to ones used on another page). This gives the following error (and I can see the abort in IE dev tools): 2013-01-08 10:59:56 DefaultExceptionMapper [ERROR] Connection lost, give up responding. org.apache.wicket.protocol.http.servlet.ResponseIOException: ClientAbortException: java.io.IOException I have tried the workaround suggested by Jonathan Crabtree to supress the errors but I just get other errors instead: 2013-01-08 11:02:57 DefaultExceptionMapper [ERROR] unexpected exception when handling another exception: Header was already written to response! java.lang.IllegalStateException: Header was already written to response! This problem only exists with Internet Explorer and doesn't appear to affect the functionality of the application however I need to find a way to at least supress the errors if there is no fix. Cheers
          Hide
          Jonathan Crabtree added a comment -

          A work-around for this problem, that I've implemented in our applications and works. Is to create a custom ServletWebResponse which extends the org.apache.wicket.protocol.http.servlet.ServletWebResponse. In your custom version override the flush method to do the flush and catch any exceptions, and ignore Socket Exceptions.

          for example..
          <code>
          @Override
          public void flush() {
          try

          { getContainerResponse().flushBuffer(); }

          catch (SocketException e)

          { LOGGER.debug("Socket exception encountered, ignoring", e); }

          catch (IOException e) {
          // Socket Exception can be wrapped by a container specific exception.
          // So we check the cause of the container exception
          Throwable rootCause = null != getRootCause(e) ? getRootCause(e) : e;
          if (rootCause instanceof SocketException)

          { LOGGER.debug("Socket exception encountered, ignoring.", rootCause); return; }

          throw new ResponseIOException(e);
          }
          }
          </code>
          ( getRootCause() come from apache ExceptionUtils )

          Then to use this you need to override the newWebResponse method in your WebApplication to return an instance of you custom WebResponse.

          Hope this is useful for anyone who wants to avoid spurious exceptions in thier logs.

          Show
          Jonathan Crabtree added a comment - A work-around for this problem, that I've implemented in our applications and works. Is to create a custom ServletWebResponse which extends the org.apache.wicket.protocol.http.servlet.ServletWebResponse. In your custom version override the flush method to do the flush and catch any exceptions, and ignore Socket Exceptions. for example.. <code> @Override public void flush() { try { getContainerResponse().flushBuffer(); } catch (SocketException e) { LOGGER.debug("Socket exception encountered, ignoring", e); } catch (IOException e) { // Socket Exception can be wrapped by a container specific exception. // So we check the cause of the container exception Throwable rootCause = null != getRootCause(e) ? getRootCause(e) : e; if (rootCause instanceof SocketException) { LOGGER.debug("Socket exception encountered, ignoring.", rootCause); return; } throw new ResponseIOException(e); } } </code> ( getRootCause() come from apache ExceptionUtils ) Then to use this you need to override the newWebResponse method in your WebApplication to return an instance of you custom WebResponse. Hope this is useful for anyone who wants to avoid spurious exceptions in thier logs.
          Hide
          Martin Grigorov added a comment -

          @Sean,

          Any help here is highly appreciated!
          If it is easy to reproduce it then try to debug it and let us know what causes the problem.

          Show
          Martin Grigorov added a comment - @Sean, Any help here is highly appreciated! If it is easy to reproduce it then try to debug it and let us know what causes the problem.
          Hide
          Sean Kendall added a comment -

          I see no one has commented on this since December. Has this issue been fixed? I am seeing this error in 1.5.6

          Show
          Sean Kendall added a comment - I see no one has commented on this since December. Has this issue been fixed? I am seeing this error in 1.5.6
          Hide
          Martin Grigorov added a comment -

          With Wicket 6.0 I cannot reproduce the problems with Andre's quickstart too...

          Show
          Martin Grigorov added a comment - With Wicket 6.0 I cannot reproduce the problems with Andre's quickstart too...
          Hide
          Martin Grigorov added a comment -

          @Ras Poutine: I cannot reproduce the problem with your quickstart at all.

          Show
          Martin Grigorov added a comment - @Ras Poutine: I cannot reproduce the problem with your quickstart at all.
          Hide
          Masaya Seko added a comment -

          This problem does not occur that seem to set the Proxy in IE.
          I do not know why.

          For analysis using burpsuite. Then does not reproduce the problem.

          Show
          Masaya Seko added a comment - This problem does not occur that seem to set the Proxy in IE. I do not know why. For analysis using burpsuite. Then does not reproduce the problem.
          Hide
          Masaya Seko added a comment -

          I encountered an trouble likely involved.
          I using wicket 1.5.3.

          When using a modal window(org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow)
          with IE, I'm having trouble socket write error.
          is called when AbstractResource#setResponseHeaders, with high probability to cause trouble.

          When rendering modal window, sometimes not called AbstractResource#setResponseHeaders.
          if so, socket write error does not occur.

          The root problem is unknown.

          I want to know how to prevent a socket write error.

          The following stack trace:
          org.apache.wicket.protocol.http.servlet.ResponseIOException: ClientAbortException: java.net.SocketException:
          Connection reset by peer: socket write error
          at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:255)
          at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92)
          at org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:611)
          at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:485)
          at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77)
          at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:105)
          at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
          at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
          at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
          at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
          at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
          at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
          at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
          Snip

          Show
          Masaya Seko added a comment - I encountered an trouble likely involved. I using wicket 1.5.3. When using a modal window(org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow) with IE, I'm having trouble socket write error. is called when AbstractResource#setResponseHeaders, with high probability to cause trouble. When rendering modal window, sometimes not called AbstractResource#setResponseHeaders. if so, socket write error does not occur. The root problem is unknown. I want to know how to prevent a socket write error. The following stack trace: org.apache.wicket.protocol.http.servlet.ResponseIOException: ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:255) at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92) at org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:611) at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:485) at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77) at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:105) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) Snip
          Hide
          俞宏伟 added a comment - - edited

          I also encountered a similar problem in my application only when IE9 compatibility mode. IE9, Firefox9, Chrome 16 will not occur.

          when click ajaxlink to show modalwindow(without any image resource), IE display 404 page, and server side throws "ClientAbortException: java.io.IOException"

          Wicket 1.5.1,1.5.2,1.5.3
          Tomcat 7
          JDK1.6

          Same code, there is no problem in wicket1.4.x or wicket 1.5.0 versions

          Show
          俞宏伟 added a comment - - edited I also encountered a similar problem in my application only when IE9 compatibility mode. IE9, Firefox9, Chrome 16 will not occur. when click ajaxlink to show modalwindow(without any image resource), IE display 404 page, and server side throws "ClientAbortException: java.io.IOException" Wicket 1.5.1,1.5.2,1.5.3 Tomcat 7 JDK1.6 Same code, there is no problem in wicket1.4.x or wicket 1.5.0 versions
          Hide
          Andre L added a comment -

          Martin,

          I've done some more testing and it seems that overriding shouldAddAntiCacheParameter() to always return false don't fix the problem. Even without the antiCache parameter I get the ResponseIOException on the serverside the first time the page loads and dont get a cache hit on the image (resulting in the aborted request). Clearing the browser cache and opening the page again in a new tab/browser window usually results in the serverside error, but Im unable to consistently reproduce it.

          Show
          Andre L added a comment - Martin, I've done some more testing and it seems that overriding shouldAddAntiCacheParameter() to always return false don't fix the problem. Even without the antiCache parameter I get the ResponseIOException on the serverside the first time the page loads and dont get a cache hit on the image (resulting in the aborted request). Clearing the browser cache and opening the page again in a new tab/browser window usually results in the serverside error, but Im unable to consistently reproduce it.
          Hide
          Ras Poutine added a comment -

          If it can helps, my quickstart reproduce logs every time

          Show
          Ras Poutine added a comment - If it can helps, my quickstart reproduce logs every time
          Hide
          Martin Grigorov added a comment -

          The reason is the antiCache parameter as we can see. Both me and Andre verified that without it all is fine.
          But for now I cannot say why IE doesn't like the random parameter.

          Show
          Martin Grigorov added a comment - The reason is the antiCache parameter as we can see. Both me and Andre verified that without it all is fine. But for now I cannot say why IE doesn't like the random parameter.
          Hide
          Igor Vaynberg added a comment -

          we should figure out why it aborts. maybe we are not sending the correct content type? maybe the abort is actually from that resource loader you put in place for css files?

          Show
          Igor Vaynberg added a comment - we should figure out why it aborts. maybe we are not sending the correct content type? maybe the abort is actually from that resource loader you put in place for css files?
          Hide
          Martin Grigorov added a comment -

          IE makes a request to load the <img .../> that came from the Ajax response and then for some reason decides to abort the request and do a new one. The abort causes "Socket closed" exception at the server side, i.e. the client closed the connection earlier for some reason.
          This happens on IE and not always. I can see the abort in IE9 Dev tools > Network tab but I don't see ResponseIOException in the server logs. Andre sees the ResponseIOException.

          Show
          Martin Grigorov added a comment - IE makes a request to load the <img .../> that came from the Ajax response and then for some reason decides to abort the request and do a new one. The abort causes "Socket closed" exception at the server side, i.e. the client closed the connection earlier for some reason. This happens on IE and not always. I can see the abort in IE9 Dev tools > Network tab but I don't see ResponseIOException in the server logs. Andre sees the ResponseIOException.
          Hide
          Igor Vaynberg added a comment -

          but why does the io exception happen?

          Show
          Igor Vaynberg added a comment - but why does the io exception happen?
          Hide
          Martin Grigorov added a comment -

          The other solution is to leave it as it is now and explain users once in a while what could be the reason of ResponseIOException.

          Show
          Martin Grigorov added a comment - The other solution is to leave it as it is now and explain users once in a while what could be the reason of ResponseIOException.
          Hide
          Igor Vaynberg added a comment -

          if we dont add it by default we will have 10000 emails asking why images dont update

          Show
          Igor Vaynberg added a comment - if we dont add it by default we will have 10000 emails asking why images dont update
          Hide
          Martin Grigorov added a comment -

          Thanks Andre!

          Then maybe we should not add this antiCache parameter by default even in Ajax request.
          IE is such a lame browser ...

          Show
          Martin Grigorov added a comment - Thanks Andre! Then maybe we should not add this antiCache parameter by default even in Ajax request. IE is such a lame browser ...
          Hide
          Andre L added a comment -

          Tried with 1.5-SNAPSHOT (wicket-core-1.5-20111103.110737-1071, wicket-request-1.5-20111103.110552-1629, wicket-util-1.5-20111103.110535-1639 and wicket-extensions-1.5-20111103.110833-1551) and I still get the same error in the log for both IE 8 and 9 mode.

          Show
          Andre L added a comment - Tried with 1.5-SNAPSHOT (wicket-core-1.5-20111103.110737-1071, wicket-request-1.5-20111103.110552-1629, wicket-util-1.5-20111103.110535-1639 and wicket-extensions-1.5-20111103.110833-1551) and I still get the same error in the log for both IE 8 and 9 mode.
          Hide
          Andre L added a comment -

          Overriding the shouldAddAntiCacheParameter to always return false seems to resolve the issue when running in IE 8.

          Show
          Andre L added a comment - Overriding the shouldAddAntiCacheParameter to always return false seems to resolve the issue when running in IE 8.
          Hide
          Martin Grigorov added a comment -

          With 1.5.2 and with:

          LazyLoadPanel.java:
          @Override
          protected void onInitialize() {
          super.onInitialize();

          add(new Image("image", new PackageResourceReference(LazyLoadedPanel.class, "logo.png")) {

          @Override
          protected boolean shouldAddAntiCacheParameter()

          { return false; // THIS IS IMPORTANT }


          });
          }

          there is no aborted load of the image.
          With 1.5-SNAPSHOT there is no need to override this method but I also don't know of any change in Wicket that "fixes" this problem.

          Show
          Martin Grigorov added a comment - With 1.5.2 and with: LazyLoadPanel.java: @Override protected void onInitialize() { super.onInitialize(); add(new Image("image", new PackageResourceReference(LazyLoadedPanel.class, "logo.png")) { @Override protected boolean shouldAddAntiCacheParameter() { return false; // THIS IS IMPORTANT } }); } there is no aborted load of the image. With 1.5-SNAPSHOT there is no need to override this method but I also don't know of any change in Wicket that "fixes" this problem.
          Hide
          Martin Grigorov added a comment -

          Also please try with 1.5-SNAPSHOT from https://repository.apache.org/content/repositories/snapshots/
          I just tried with 1.5.2 and there is indeed one aborted load of the image but still I don't have any ResponseIOException logged. Unfortunatelly IE9 doesn't explain why it is aborted.
          With 1.5-SNAPSHOT there is no aborted load of the image.

          Show
          Martin Grigorov added a comment - Also please try with 1.5-SNAPSHOT from https://repository.apache.org/content/repositories/snapshots/ I just tried with 1.5.2 and there is indeed one aborted load of the image but still I don't have any ResponseIOException logged. Unfortunatelly IE9 doesn't explain why it is aborted. With 1.5-SNAPSHOT there is no aborted load of the image.
          Hide
          Martin Grigorov added a comment -

          I see that in all quickstarts mentioned in this ticket an Image updated in Ajax request is made.
          Since I cannot reproduce the problem locally I'd like to ask you to override Image#shouldAddAntiCacheParameter() and always return 'false'.

          Let's see whether this will solve the problem for you.

          Show
          Martin Grigorov added a comment - I see that in all quickstarts mentioned in this ticket an Image updated in Ajax request is made. Since I cannot reproduce the problem locally I'd like to ask you to override Image#shouldAddAntiCacheParameter() and always return 'false'. Let's see whether this will solve the problem for you.
          Hide
          Martin Grigorov added a comment -

          The attached lazyloaderror.zip works without any problems here on IE9 with all possible browser modes and compatibility modes.

          Show
          Martin Grigorov added a comment - The attached lazyloaderror.zip works without any problems here on IE9 with all possible browser modes and compatibility modes.
          Hide
          Sodasmile added a comment -

          This issue should be reopened, it is not fixed. However I cannot figure out how to do that in this tool.

          Show
          Sodasmile added a comment - This issue should be reopened, it is not fixed. However I cannot figure out how to do that in this tool.
          Hide
          Andre L added a comment -

          Just checked this with the quickstart application in lazyloaderror.zip using wicket 1.5.2 and it's still broken (IE8).

          Show
          Andre L added a comment - Just checked this with the quickstart application in lazyloaderror.zip using wicket 1.5.2 and it's still broken (IE8).
          Hide
          Ras Poutine added a comment -

          I have the same error in 1.5.1 and internet explorer 8 when i run this code :

          public void onClick(AjaxRequestTarget target)

          { replacePanel(target, new ImagePanel("panel", item.getModelObject().getName()); }

          private void replacePanel(AjaxRequestTarget target, Panel newPanel)

          { this.dynamicPanel.replaceWith(newPanel); this.dynamicPanel = newPanel; target.add(this.dynamicPanel); }

          public class ImagePanel extends Panel {

          public ImagePanel(String id, String path) {
          super(id);
          setOutputMarkupId(true);
          final ResourceReference ref = getPicResource(new File(path));
          Image image = new Image("image", ref) {
          @Override
          protected void onComponentTag(final ComponentTag tag)

          { CharSequence url = RequestCycle.get().urlFor(ref, new PageParameters()); checkComponentTag(tag, "img"); tag.put("src", url); tag.put("alt", ""); }

          };
          add(image);
          }
          }

          public ResourceReference getPicResource(final File pic) {

          return new ResourceReference(pic.getName()) {

          @Override
          public AbstractResource getResource() {
          final BufferedDynamicImageResource resource = new BufferedDynamicImageResource();
          BufferedImage bi = null;
          try

          { bi = ImageIO.read(im); }

          catch (IOException e)

          { e.printStackTrace(); }

          resource.setImage(bi);
          return resource;
          }
          };
          }

          Show
          Ras Poutine added a comment - I have the same error in 1.5.1 and internet explorer 8 when i run this code : public void onClick(AjaxRequestTarget target) { replacePanel(target, new ImagePanel("panel", item.getModelObject().getName()); } private void replacePanel(AjaxRequestTarget target, Panel newPanel) { this.dynamicPanel.replaceWith(newPanel); this.dynamicPanel = newPanel; target.add(this.dynamicPanel); } public class ImagePanel extends Panel { public ImagePanel(String id, String path) { super(id); setOutputMarkupId(true); final ResourceReference ref = getPicResource(new File(path)); Image image = new Image("image", ref) { @Override protected void onComponentTag(final ComponentTag tag) { CharSequence url = RequestCycle.get().urlFor(ref, new PageParameters()); checkComponentTag(tag, "img"); tag.put("src", url); tag.put("alt", ""); } }; add(image); } } public ResourceReference getPicResource(final File pic) { return new ResourceReference(pic.getName()) { @Override public AbstractResource getResource() { final BufferedDynamicImageResource resource = new BufferedDynamicImageResource(); BufferedImage bi = null; try { bi = ImageIO.read(im); } catch (IOException e) { e.printStackTrace(); } resource.setImage(bi); return resource; } }; }
          Hide
          Andre L added a comment -

          Is this fixed in 1.5.0? Changing the version in the attached quickstart application still give a ResponseIOException on the serverside when using Internet Explorer.

          Show
          Andre L added a comment - Is this fixed in 1.5.0? Changing the version in the attached quickstart application still give a ResponseIOException on the serverside when using Internet Explorer.
          Hide
          Martin Grigorov added a comment -

          Fixed it.

          It was the usage of ':' in wicket:antiCache parameter.
          This character is not allowed in parameter names.
          Now the parameter is just 'antiCache'.

          Show
          Martin Grigorov added a comment - Fixed it. It was the usage of ':' in wicket:antiCache parameter. This character is not allowed in parameter names. Now the parameter is just 'antiCache'.
          Hide
          Andre L added a comment -

          Internet Explorer 9 debugbar showing all requests made when accessing the context of the example application (lazyloadpanel.zip).

          Show
          Andre L added a comment - Internet Explorer 9 debugbar showing all requests made when accessing the context of the example application (lazyloadpanel.zip).
          Hide
          Andre L added a comment -

          Example application that uses a image in a lazy loaded panel.

          Show
          Andre L added a comment - Example application that uses a image in a lazy loaded panel.
          Hide
          Martin Grigorov added a comment -

          Here are the requests being made to the server during opening of the modal:
          GET /wicket/page?0-3.IBehaviorListener.0-showModalWindow&random=0.2886669956730594 HTTP/1.1
          GET /wicket/resource/iwicket.ImageWicketModalPanel/mtn-ver-1311247057000.jpg?wicket:antiCache=1311247826026 HTTP/1.1
          GET /wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/transparent2.png HTTP/1.1

          I.e. there is no request to the same resource (mtn.jpg) twice.

          Show
          Martin Grigorov added a comment - Here are the requests being made to the server during opening of the modal: GET /wicket/page?0-3.IBehaviorListener.0-showModalWindow&random=0.2886669956730594 HTTP/1.1 GET /wicket/resource/iwicket.ImageWicketModalPanel/mtn-ver-1311247057000.jpg?wicket:antiCache=1311247826026 HTTP/1.1 GET /wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow/res/transparent2.png HTTP/1.1 I.e. there is no request to the same resource (mtn.jpg) twice.
          Hide
          Andre L added a comment -

          Im not a javascript expert, but there seems to be an error in the javascript function Wicket.replaceOuterHtmlIE in wicket-ajax.js. There seems to be some special handling code for getting <script> tags inside the response that generate the first (aborted) request for the image resource.

          // this is not exactly nice, but we need to get invalid markup inside innerHTML,
          // because otherwise IE just swallows the <script> tags (sometimes)
          tempDiv.innerHTML = '<table style="display:none">' + markIframe(text) + '</table>';

          ..

          // now use regular div so that we won't mess the DOM
          tempDiv.innerHTML = '<div style="display:none">' + text + '</div>';

          The second call to tempDiv.innerHTML happens after the browser has requested the image resource evaluated between the (invalid) <table></table> markup but before any server response is made, hence it cancels the request and make a new one.

          Delaying the execution just before "tempDiv.innerHTML = '<div style="display:none">' + text + '</div>'" until the first request for the image gets a server response removed the second call to the image and the resulting error on the serverside.

          Show
          Andre L added a comment - Im not a javascript expert, but there seems to be an error in the javascript function Wicket.replaceOuterHtmlIE in wicket-ajax.js. There seems to be some special handling code for getting <script> tags inside the response that generate the first (aborted) request for the image resource. // this is not exactly nice, but we need to get invalid markup inside innerHTML, // because otherwise IE just swallows the <script> tags (sometimes) tempDiv.innerHTML = '<table style="display:none">' + markIframe(text) + '</table>'; .. // now use regular div so that we won't mess the DOM tempDiv.innerHTML = '<div style="display:none">' + text + '</div>'; The second call to tempDiv.innerHTML happens after the browser has requested the image resource evaluated between the (invalid) <table></table> markup but before any server response is made, hence it cancels the request and make a new one. Delaying the execution just before "tempDiv.innerHTML = '<div style="display:none">' + text + '</div>'" until the first request for the image gets a server response removed the second call to the image and the resulting error on the serverside.
          Hide
          Andre L added a comment -

          The problem is not only related to modal windows. Loading a image resource as part of a component added to a AjaxRequestTarget seems to result in this error in Internet Explorer. This can easily be reproduced by changing the use of a ModalWindow in the example application with a LazyLoadPanel:

          AjaxLazyLoadPanel lazyLoadPanel = new AjaxLazyLoadPanel("modalWindow") {

          @Override
          public Component getLazyLoadComponent(final String id)

          { return new ImageWicketModalPanel(id); }

          };
          add(lazyLoadPanel);

          IE starts to process the request for the image but then decides to cancel the operation (just after sending the request to the server). There are several reasons why IE might decide to abort the request, for example if it finds out that the resource was allready cached or that a javascript do not wait for the server response.

          Disabling the Image anticaching seems to prevent the ResponseIOException on the server, but IE still tries to load the image resource two times (aborting the first operation).

          Show
          Andre L added a comment - The problem is not only related to modal windows. Loading a image resource as part of a component added to a AjaxRequestTarget seems to result in this error in Internet Explorer. This can easily be reproduced by changing the use of a ModalWindow in the example application with a LazyLoadPanel: AjaxLazyLoadPanel lazyLoadPanel = new AjaxLazyLoadPanel("modalWindow") { @Override public Component getLazyLoadComponent(final String id) { return new ImageWicketModalPanel(id); } }; add(lazyLoadPanel); IE starts to process the request for the image but then decides to cancel the operation (just after sending the request to the server). There are several reasons why IE might decide to abort the request, for example if it finds out that the resource was allready cached or that a javascript do not wait for the server response. Disabling the Image anticaching seems to prevent the ResponseIOException on the server, but IE still tries to load the image resource two times (aborting the first operation).
          Hide
          Martin Grigorov added a comment -

          Attaching the simplified version without usage of image.

          Show
          Martin Grigorov added a comment - Attaching the simplified version without usage of image.
          Hide
          Martin Grigorov added a comment -

          It seems this is a general problem with ModalWindow + IE.

          I removed the image and image resource completely and it still fails in IE with this exception.

          Show
          Martin Grigorov added a comment - It seems this is a general problem with ModalWindow + IE. I removed the image and image resource completely and it still fails in IE with this exception.
          Hide
          Sodasmile added a comment -

          Ok, I see, I'll remember that. But I changed the image reference from ImageWicketModalPanel in the example application to

          private static final ResourceReference IMAGE_REFERENCE = new PackageResourceReference(ImageWicketModalPanel.class, "mtn.jpg");

          and I still get the same above mentioned stacktrace in the log.

          Show
          Sodasmile added a comment - Ok, I see, I'll remember that. But I changed the image reference from ImageWicketModalPanel in the example application to private static final ResourceReference IMAGE_REFERENCE = new PackageResourceReference(ImageWicketModalPanel.class, "mtn.jpg"); and I still get the same above mentioned stacktrace in the log.
          Hide
          Martin Grigorov added a comment -

          Your usage of SharedResourceReference is wrong.
          In your case you need PackageResourceReference.

          SharedResourceReference should be used with org.apache.wicket.Application.getSharedResources().add().

          I'll investigate further.

          Show
          Martin Grigorov added a comment - Your usage of SharedResourceReference is wrong. In your case you need PackageResourceReference. SharedResourceReference should be used with org.apache.wicket.Application.getSharedResources().add(). I'll investigate further.
          Hide
          Sodasmile added a comment -

          It appears from the Internet Explorer F12 developer tools, network inspector that the image references from the ajax response may be resolved twice? It first makes a request for the image URL, initiated by an <img> element, the request takes < 1ms to complete, with result "(Aborted)", it then makes another request for the very same image URL, and this time the request completes with 200 OK, and the image is downloaded as expected.

          Can it be the case that the ajax response is transferred back to the browser and the html is evaluated in a different way than earlier, so that Internet Explorer first tries to resolve the images, then gets interrupted, then tries another time when the html is properly attached to the DOM tree??

          We did not see anything like this when the application was running on 1.4

          Show
          Sodasmile added a comment - It appears from the Internet Explorer F12 developer tools, network inspector that the image references from the ajax response may be resolved twice? It first makes a request for the image URL, initiated by an <img> element, the request takes < 1ms to complete, with result "(Aborted)", it then makes another request for the very same image URL, and this time the request completes with 200 OK, and the image is downloaded as expected. Can it be the case that the ajax response is transferred back to the browser and the html is evaluated in a different way than earlier, so that Internet Explorer first tries to resolve the images, then gets interrupted, then tries another time when the html is properly attached to the DOM tree?? We did not see anything like this when the application was running on 1.4
          Hide
          Sodasmile added a comment -

          Stacktrace:

          ERROR - DefaultExceptionMapper - Connection lost, give up responding.
          org.apache.wicket.protocol.http.servlet.ResponseIOException: org.mortbay.jetty.EofException
          at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:271)
          at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92)
          at org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:528)
          at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:436)
          at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77)
          at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:92)
          at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:717)
          at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:63)
          at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
          at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:253)
          at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:160)
          at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:216)
          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
          at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
          at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
          at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
          at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
          at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
          at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
          at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
          at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
          at org.mortbay.jetty.Server.handle(Server.java:326)
          at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
          at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
          at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
          at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
          at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
          at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
          at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          Caused by: org.mortbay.jetty.EofException
          at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:791)
          at org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:693)
          at org.mortbay.jetty.Response.flushBuffer(Response.java:958)
          at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:267)
          ... 28 more
          Caused by: java.io.IOException: Broken pipe
          at sun.nio.ch.FileDispatcher.write0(Native Method)
          at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
          at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:72)
          at sun.nio.ch.IOUtil.write(IOUtil.java:43)
          at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
          at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:170)
          at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221)
          at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:720)
          ... 31 more

          Show
          Sodasmile added a comment - Stacktrace: ERROR - DefaultExceptionMapper - Connection lost, give up responding. org.apache.wicket.protocol.http.servlet.ResponseIOException: org.mortbay.jetty.EofException at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:271) at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92) at org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:528) at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:436) at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77) at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:92) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:717) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:63) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:253) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:160) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:216) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:791) at org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:693) at org.mortbay.jetty.Response.flushBuffer(Response.java:958) at org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:267) ... 28 more Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:72) at sun.nio.ch.IOUtil.write(IOUtil.java:43) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:170) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:720) ... 31 more
          Hide
          Sodasmile added a comment -

          Example application

          Show
          Sodasmile added a comment - Example application

            People

            • Assignee:
              Unassigned
              Reporter:
              Sodasmile
            • Votes:
              15 Vote for this issue
              Watchers:
              25 Start watching this issue

              Dates

              • Created:
                Updated:

                Development