Enabling asynchronous support in filter causes some requests for static resources to not be fulfilled?
I have a filter mapped to "/*", which is responsible for delegating all incoming requests to the appropriate servlets. Requests for static resources (images, swf files, etc) are all ".doFiltered()" to GlassFish's default servlet which normally handles them.
This setup works great for me, until I enable asynchronous support in the filter. When I do that, a good amount of requests for static resources do not ever end up getting responses. I'm having trouble understanding why simply enabling the option causes this behavior.
I'm not well-versed in container behavior, but the only thing I can think of that may cause this will be that the number of threads required to process requests when this option is enabled ends up being higher than maximum size of the thread pool for HTTP requests.
Can anyone shed some light on what's happening? Keep in mind i'm not even handling the static resource requests myself; i'm simply filtering them to the default servlet.
Asynchronous support is CRUCIAL to my app and temporarily disabling it really cripples it, so i'd really appreciate some insight on this.
Thanks.
Thanks for responding oleksiys.
It seems that after upgrading to Glassfish 3.1.1 from Glassfish 3.0, the issue resolvd itself. I'll be sure to come back here if it appears again.





Hi,
it would help if you can provide a simple application, using which we
can reproduce the issue.
Thanks.
WBR,
Alexey.
On 02/21/2012 06:15 PM, forums@java.net wrote:
> I have a filter mapped to "/*", which is responsible for delegating all
> incoming requests to the appropriate servlets. Requests for static
> resources
> (images, swf files, etc) are all ".doFiltered()" to GlassFish's default
> servlet which normally handles them.
>
> This setup works great for me, until I enable asynchronous support in the
> filter. When I do that, a good amount of requests for static resources
> do not
> ever end up getting responses. I'm having trouble understanding why
> simply
> enabling the option causes this behavior.
>
> I'm not well-versed in container behavior, but the only thing I can
> think of
> that may cause this will be that the number of threads required to
> process
> requests when this option is enabled ends up being higher than maximum
> size
> of the thread pool for HTTP requests.
>
> Can anyone shed some light on what's happening? Keep in mind i'm not even
> handling the static resource requests myself; i'm simply filtering
> them to
> the default servlet.
>
> Asynchronous support is CRUCIAL to my app and temporarily disabling it
> really
> cripples it, so i'd really appreciate some insight on this.
>
> Thanks.
>
>
> --
>
> [Message sent by forum member 'klawson88']
>
> View Post: http://forums.java.net/node/883694
>
>