Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-05-24 Thread Martin Grigorov
There is an open ticket in our Jira about this problem -
https://issues.apache.org/jira/browse/WICKET-3869.
It has a quickstart too.
You may try to debug it if it reproduces with your setup.


On Fri, May 24, 2013 at 11:29 AM, Martin Grigorov wrote:

> Hi,
>
>
> On Fri, May 24, 2013 at 10:47 AM, Mikko Pukki  > wrote:
>
>> Hi,
>>
>> I'm having same errors in IE10 and Opera. Chrome and Firefox don't do this
>> (neither does IE always, but almost always it does). Wicket versions are
>> 1.5.8 and 6.7.0
>>
>> My case is a modal window that contains a panel with Image
>> (org.apache.wicket.markup.html.image.Image)
>> When modal window opens, first request to image's URL is aborted,
>> request's duration <0ms, nothing is
>> transferred to the browser. Second request to the same URL gives status
>> code 200 and browser seems
>> to be happy.  does
>> not seem to have any effect
>> and looking from developer tool's console the page mode does not change
>> while rendering.
>>
>> I have not yet had time to make a quick start on this, but only problem
>> I'm facing is that
>> error log level. If the browser aborts any request, what could wicket do
>> about that? Nothing I guess.
>>
>
> Yes. The server lost its client, the connection is closed, so there is
> nothing to be done.
>
>
>> Should this be debug level? I would like to see "real" errors but these
>> are filling the logs.
>>
>
> I think it is an error. Without this log we cannot even know there is some
> problem with ModalWindow in IE.
> The problem is that so far we were not able to identify the problem with
> IE.
> Maybe Opera will give better explanation what is the reason for the
> failure.
>
>
>>
>> -Mikko
>>
>>
>> -Original Message-
>> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>> Sent: 16. huhtikuuta 2013 14:34
>> To: users@wicket.apache.org; Martin Dietze
>> Subject: Re: After upgrade to Wicket 6: lots of 'java.io.IOException:
>> Connection reset by peer' in my logs
>>
>> Hi,
>>
>> Does these errors happen in any browser or only in IE ?
>> I remember such problem in IE - the browser renders the page in modeX and
>> during download of the resources switches to modeY, so it closes the opened
>> connections and downloads the resource again.
>> Either modeX or modeY is QuirksMode.
>>
>> The simple solution/workaround is to add > http-equiv="X-UA-Compatible"
>> content="IE=edge"> to your pages.
>>
>>
>> On Tue, Apr 16, 2013 at 2:27 PM, Martin Dietze  wrote:
>>
>> > After upgrading to Wicket 6, I am getting too many of exceptions like
>> > the ones below. They 'happen' either when delivering static contents,
>> > like Javascript files (via resource references) or even media contents
>> > like images or movies which are written into the response. I've
>> > appended two stacktraces, one for each of these two categories. The
>> > errors don't seem to occur on ordinary Wicket pages. The application
>> > is running in a glassfish container.
>> >
>> > Having searched google I've found a number of issues, but none of them
>> > seemed to match exactly. Thus, does the stuff below look familiar to
>> > anyone? Maybe there's a known issue that I'm not yet aware of?
>> >
>> > In any case I badly need some kind of workaround, since we really
>> > cannot roll back the system at this time.
>> >
>> > Cheers,
>> >
>> > m.
>> >
>> > == snip, here's a stacktrace for delivering a Javascript resource
>> > =
>> >
>> > ERROR 2013-04-15T10:45:00 [http-thread-pool-443-(31)]
>> > my.company.app.ui.pages.error.ErrorPage [-]
>> > [/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/j
>> > query/jquery.min-ver-E1288116312E4728F98923C79B034B67.js]
>> > >>>> An internal server error occured
>> > org.apache.wicket.protocol.http.servlet.ResponseIOException:
>> > org.apache.catalina.connector.ClientAbortException: java.io.IOException:
>> > Connection reset by peer
>> > at
>> > org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(Servl
>> > etWebResponse.java:292)
>> > ~[wicket-core-6.6.0.jar:6.6.0]
>> > at
>> > org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(Heade
>> > 

Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-05-24 Thread Martin Grigorov
Hi,


On Fri, May 24, 2013 at 10:47 AM, Mikko Pukki
wrote:

> Hi,
>
> I'm having same errors in IE10 and Opera. Chrome and Firefox don't do this
> (neither does IE always, but almost always it does). Wicket versions are
> 1.5.8 and 6.7.0
>
> My case is a modal window that contains a panel with Image
> (org.apache.wicket.markup.html.image.Image)
> When modal window opens, first request to image's URL is aborted,
> request's duration <0ms, nothing is
> transferred to the browser. Second request to the same URL gives status
> code 200 and browser seems
> to be happy.  does
> not seem to have any effect
> and looking from developer tool's console the page mode does not change
> while rendering.
>
> I have not yet had time to make a quick start on this, but only problem
> I'm facing is that
> error log level. If the browser aborts any request, what could wicket do
> about that? Nothing I guess.
>

Yes. The server lost its client, the connection is closed, so there is
nothing to be done.


> Should this be debug level? I would like to see "real" errors but these
> are filling the logs.
>

I think it is an error. Without this log we cannot even know there is some
problem with ModalWindow in IE.
The problem is that so far we were not able to identify the problem with IE.
Maybe Opera will give better explanation what is the reason for the failure.


>
> -Mikko
>
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: 16. huhtikuuta 2013 14:34
> To: users@wicket.apache.org; Martin Dietze
> Subject: Re: After upgrade to Wicket 6: lots of 'java.io.IOException:
> Connection reset by peer' in my logs
>
> Hi,
>
> Does these errors happen in any browser or only in IE ?
> I remember such problem in IE - the browser renders the page in modeX and
> during download of the resources switches to modeY, so it closes the opened
> connections and downloads the resource again.
> Either modeX or modeY is QuirksMode.
>
> The simple solution/workaround is to add  content="IE=edge"> to your pages.
>
>
> On Tue, Apr 16, 2013 at 2:27 PM, Martin Dietze  wrote:
>
> > After upgrading to Wicket 6, I am getting too many of exceptions like
> > the ones below. They 'happen' either when delivering static contents,
> > like Javascript files (via resource references) or even media contents
> > like images or movies which are written into the response. I've
> > appended two stacktraces, one for each of these two categories. The
> > errors don't seem to occur on ordinary Wicket pages. The application
> > is running in a glassfish container.
> >
> > Having searched google I've found a number of issues, but none of them
> > seemed to match exactly. Thus, does the stuff below look familiar to
> > anyone? Maybe there's a known issue that I'm not yet aware of?
> >
> > In any case I badly need some kind of workaround, since we really
> > cannot roll back the system at this time.
> >
> > Cheers,
> >
> > m.
> >
> > == snip, here's a stacktrace for delivering a Javascript resource
> > =
> >
> > ERROR 2013-04-15T10:45:00 [http-thread-pool-443-(31)]
> > my.company.app.ui.pages.error.ErrorPage [-]
> > [/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/j
> > query/jquery.min-ver-E1288116312E4728F98923C79B034B67.js]
> > >>>> An internal server error occured
> > org.apache.wicket.protocol.http.servlet.ResponseIOException:
> > org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> > Connection reset by peer
> > at
> > org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(Servl
> > etWebResponse.java:292)
> > ~[wicket-core-6.6.0.jar:6.6.0]
> > at
> > org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(Heade
> > rBufferingWebResponse.java:99)
> > ~[wicket-core-6.6.0.jar:6.6.0]
> > at
> > org.apache.wicket.request.resource.AbstractResource.flushResponseAfter
> > Headers(AbstractResource.java:676)
> > ~[wicket-core-6.6.0.jar:6.6.0]
> > at
> > org.apache.wicket.request.resource.AbstractResource.setResponseHeaders
> > (AbstractResource.java:662)
> > ~[wicket-core-6.6.0.jar:6.6.0]
> > at
> > org.apache.wicket.request.resource.AbstractResource.respond(AbstractRe
> > source.java:513)
> > ~[wicket-core-6.6.0.jar:6.6.0]
> > at
> > org.apache.wicket.request.handler.resource.ResourceRequestHandler.resp
> > ond(ResourceRequestHandler.java:75)
>

RE: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-05-24 Thread Mikko Pukki
Hi,

I'm having same errors in IE10 and Opera. Chrome and Firefox don't do this
(neither does IE always, but almost always it does). Wicket versions are 1.5.8 
and 6.7.0

My case is a modal window that contains a panel with Image 
(org.apache.wicket.markup.html.image.Image)
When modal window opens, first request to image's URL is aborted, request's 
duration <0ms, nothing is
transferred to the browser. Second request to the same URL gives status code 
200 and browser seems
to be happy.  does not 
seem to have any effect
and looking from developer tool's console the page mode does not change while 
rendering.

I have not yet had time to make a quick start on this, but only problem I'm 
facing is that
error log level. If the browser aborts any request, what could wicket do about 
that? Nothing I guess.
Should this be debug level? I would like to see "real" errors but these are 
filling the logs.

-Mikko


-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: 16. huhtikuuta 2013 14:34
To: users@wicket.apache.org; Martin Dietze
Subject: Re: After upgrade to Wicket 6: lots of 'java.io.IOException: 
Connection reset by peer' in my logs

Hi,

Does these errors happen in any browser or only in IE ?
I remember such problem in IE - the browser renders the page in modeX and 
during download of the resources switches to modeY, so it closes the opened 
connections and downloads the resource again.
Either modeX or modeY is QuirksMode.

The simple solution/workaround is to add  to your pages.


On Tue, Apr 16, 2013 at 2:27 PM, Martin Dietze  wrote:

> After upgrading to Wicket 6, I am getting too many of exceptions like
> the ones below. They 'happen' either when delivering static contents,
> like Javascript files (via resource references) or even media contents
> like images or movies which are written into the response. I've
> appended two stacktraces, one for each of these two categories. The
> errors don't seem to occur on ordinary Wicket pages. The application
> is running in a glassfish container.
>
> Having searched google I've found a number of issues, but none of them
> seemed to match exactly. Thus, does the stuff below look familiar to
> anyone? Maybe there's a known issue that I'm not yet aware of?
>
> In any case I badly need some kind of workaround, since we really
> cannot roll back the system at this time.
>
> Cheers,
>
> m.
>
> == snip, here's a stacktrace for delivering a Javascript resource
> =
>
> ERROR 2013-04-15T10:45:00 [http-thread-pool-443-(31)]
> my.company.app.ui.pages.error.ErrorPage [-]
> [/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/j
> query/jquery.min-ver-E1288116312E4728F98923C79B034B67.js]
> >>>> An internal server error occured
> org.apache.wicket.protocol.http.servlet.ResponseIOException:
> org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> Connection reset by peer
> at
> org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(Servl
> etWebResponse.java:292)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(Heade
> rBufferingWebResponse.java:99)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.flushResponseAfter
> Headers(AbstractResource.java:676)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.setResponseHeaders
> (AbstractResource.java:662)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.respond(AbstractRe
> source.java:513)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.handler.resource.ResourceRequestHandler.resp
> ond(ResourceRequestHandler.java:75)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.handler.resource.ResourceReferenceRequestHan
> dler.respond(ResourceReferenceRequestHandler.java:108)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(R
> equestCycle.java:840)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerSt
> ack.java:64)
> ~[wicket-request-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java
> :254)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCyc
> le.java:211)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(R
> e

Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-04-16 Thread Martin Dietze
On Tue, April 16, 2013, Martin Grigorov wrote:

> I'm not sure what redirect you mean.

I was referring to the fact that the error page was called here:

| ERROR 2013-04-15T12:29:35 [http-thread-pool-443-(36)] 
my.company.app.ui.pages.error.ErrorPage [USER.8619] 
[/attachment/ARTICLE/540214/5/KN_120831_APP_015.JPG]  An internal server 
error occured
| org.apache.wicket.protocol.http.servlet.ResponseIOException: 
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken 
pipe
| at 
org.apache.wicket.protocol.http.servlet.ServletWebResponse.write(ServletWebResponse.java:126)
 ~[wicket-core-6.6.0.jar:6.6.0]
| [...]

> If the error is the same as the one I'm talking about then you can safely
> ignore these errors. Your users do not see any problems at client side.

Is there any reliable way to detect these 'ignorable' errors? If
yes, I'd like to suppress the calls to ErrorPage here.

> P.S. Educate your users that they will have better experience by using
> modern browsers.

How I would like to! Unfortunately 90% of my users access the
pages from their respective workplaces, and unfortunately IE is
still company policy there :(

Cheers,

M'bert

-- 
--- / http://herbert.the-little-red-haired-girl.org / -
=+= 
Ya dyshu - i znachit, ya lyublyu!
Ya lyublyu - i znachit, ya zhivu!  -- Vladimir Vysozkij

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-04-16 Thread Martin Grigorov
On Tue, Apr 16, 2013 at 2:56 PM, Martin Dietze  wrote:

> On Tue, April 16, 2013, Martin Grigorov wrote:
>
> > Does these errors happen in any browser or only in IE ?
> > I remember such problem in IE - the browser renders the page in modeX and
> > during download of the resources switches to modeY, so it closes the
> opened
> > connections and downloads the resource again.
> > Either modeX or modeY is QuirksMode.
>
> I can't tell exactly. However I know that 70% of our users use IE,
> thus the probability is rather high. I'm not even sure if users would
> get to see the error page here, would they?
>
> If not, would it not suffice to just suppress redirecting to the
> error page here?
>
> > The simple solution/workaround is to add  http-equiv="X-UA-Compatible"
> > content="IE=edge"> to your pages.
>
> I must admit I don't have the guts to do this. We have a rather
> complex design and had so many compatibility isssues with the
> different IE versions that I'm pretty sure we would mess up
> things with this.
>
> If you agree that suppressing the redirect here would make
> sense, any idea where to do this?
>

I'm not sure what redirect you mean.
If the error is the same as the one I'm talking about then you can safely
ignore these errors. Your users do not see any problems at client side.

P.S. Educate your users that they will have better experience by using
modern browsers.


>
> Cheers,
>
> M'bert
>
> --
> --- / http://herbert.the-little-red-haired-girl.org /
> -
> =+=
> This parrot is no more.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-04-16 Thread Martin Dietze
On Tue, April 16, 2013, Martin Grigorov wrote:

> Does these errors happen in any browser or only in IE ?
> I remember such problem in IE - the browser renders the page in modeX and
> during download of the resources switches to modeY, so it closes the opened
> connections and downloads the resource again.
> Either modeX or modeY is QuirksMode.

I can't tell exactly. However I know that 70% of our users use IE,
thus the probability is rather high. I'm not even sure if users would
get to see the error page here, would they?

If not, would it not suffice to just suppress redirecting to the
error page here?

> The simple solution/workaround is to add  content="IE=edge"> to your pages.

I must admit I don't have the guts to do this. We have a rather
complex design and had so many compatibility isssues with the
different IE versions that I'm pretty sure we would mess up
things with this. 

If you agree that suppressing the redirect here would make
sense, any idea where to do this?

Cheers,

M'bert

-- 
--- / http://herbert.the-little-red-haired-girl.org / -
=+= 
This parrot is no more.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-04-16 Thread Martin Grigorov
Hi,

Does these errors happen in any browser or only in IE ?
I remember such problem in IE - the browser renders the page in modeX and
during download of the resources switches to modeY, so it closes the opened
connections and downloads the resource again.
Either modeX or modeY is QuirksMode.

The simple solution/workaround is to add  to your pages.


On Tue, Apr 16, 2013 at 2:27 PM, Martin Dietze  wrote:

> After upgrading to Wicket 6, I am getting too many of exceptions
> like the ones below. They 'happen' either when delivering static
> contents, like Javascript files (via resource references) or even
> media contents like images or movies which are written into the
> response. I've appended two stacktraces, one for each of these
> two categories. The errors don't seem to occur on ordinary
> Wicket pages. The application is running in a glassfish container.
>
> Having searched google I've found a number of issues, but none
> of them seemed to match exactly. Thus, does the stuff below look
> familiar to anyone? Maybe there's a known issue that I'm not
> yet aware of?
>
> In any case I badly need some kind of workaround, since we
> really cannot roll back the system at this time.
>
> Cheers,
>
> m.
>
> == snip, here's a stacktrace for delivering a Javascript resource =
>
> ERROR 2013-04-15T10:45:00 [http-thread-pool-443-(31)]
> my.company.app.ui.pages.error.ErrorPage [-]
> [/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery.min-ver-E1288116312E4728F98923C79B034B67.js]
>  An internal server error occured
> org.apache.wicket.protocol.http.servlet.ResponseIOException:
> org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> Connection reset by peer
> at
> org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:292)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:99)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.flushResponseAfterHeaders(AbstractResource.java:676)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:662)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:513)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:75)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:108)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:840)
> ~[wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> ~[wicket-request-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:254)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:267)
> [wicket-core-6.6.0.jar:6.6.0]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
> [web-core.jar:3.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
> [web-core.jar:3.0.1]
> at my.company.commons.my.MyFilter.doFilter(MyFilter.java:799)
> [mc-commons-my-1.7.1.jar:$Rev: 17908 $]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
> [web-core.jar:3.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
> [web-core.jar:3.0.1]
> at
> ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:51)
> [logback-classic-0.9.21.jar:na]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
> [web-core.jar:3.0.1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
> [web-core.jar:3.0.1]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)

After upgrade to Wicket 6: lots of 'java.io.IOException: Connection reset by peer' in my logs

2013-04-16 Thread Martin Dietze
After upgrading to Wicket 6, I am getting too many of exceptions
like the ones below. They 'happen' either when delivering static
contents, like Javascript files (via resource references) or even
media contents like images or movies which are written into the
response. I've appended two stacktraces, one for each of these 
two categories. The errors don't seem to occur on ordinary 
Wicket pages. The application is running in a glassfish container.

Having searched google I've found a number of issues, but none 
of them seemed to match exactly. Thus, does the stuff below look
familiar to anyone? Maybe there's a known issue that I'm not 
yet aware of? 

In any case I badly need some kind of workaround, since we 
really cannot roll back the system at this time.

Cheers,

m.

== snip, here's a stacktrace for delivering a Javascript resource =

ERROR 2013-04-15T10:45:00 [http-thread-pool-443-(31)] 
my.company.app.ui.pages.error.ErrorPage [-] 
[/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery.min-ver-E1288116312E4728F98923C79B034B67.js]
  An internal server error occured
org.apache.wicket.protocol.http.servlet.ResponseIOException: 
org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
Connection reset by peer
at 
org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:292)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:99)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.resource.AbstractResource.flushResponseAfterHeaders(AbstractResource.java:676)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:662)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:513)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:75)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:108)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:840)
 ~[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
 ~[wicket-request-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:254) 
[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211)
 [wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282)
 [wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244)
 [wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
 [wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:267) 
[wicket-core-6.6.0.jar:6.6.0]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
 [web-core.jar:3.0.1]
at my.company.commons.my.MyFilter.doFilter(MyFilter.java:799) 
[mc-commons-my-1.7.1.jar:$Rev: 17908 $]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
 [web-core.jar:3.0.1]
at 
ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:51)
 [logback-classic-0.9.21.jar:na]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
 [web-core.jar:3.0.1]
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641) 
[web-core.jar:3.0.1]
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97) 
[web-glue.jar:3.0.1]
at 
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
 [web-glue.jar:3.0.1]
at 
org.apache.catalina.core.StandardHostValve.invo