Jumping to the thread late since I only now noticed that it was
grizzly-sendfile related.
I'm surprised to hear that grizzly-sendfile is conflicting with comet
and causing the double responses. I can't think of anything within
grizzly-sendfile that would be causing this.
grizzly-sendfile intercepts requests only after they are processed by
the adapter (e.g. servlet container) and only if the response contains
the X-Sendfile header.
grizzly's api suggests that you can add multiple filters and all of
them will be invoked at the right time, so if this causes problems
then my feeling is that it is a grizzly bug.
The second issue when grizzly-sendfile caused comet to be disable even
thought it was enabled via the domain.xml file is again something that
could be improved in grizzly. Instead of -Dcom.sun.enterprise.web.connector.grizzly.asyncFilters
=, there could be an option like -Dcom.sun.enterprise.web.connector.grizzly.appendAsyncFilter
=, which would cause the specified filter to be appended to the filter
chain rather than result in replacement of the existing chain with the
new definition.
If you have a simple app that manifests the double response problem
then post it somewhere and I'll have a look at it over the weekend -
no promises that I'll be able to fix it if the problem is a nontrivial
grizzly bug though.
cheers,
Igor
On May 4, 2009, at 2:29 PM, Thomas Gideon wrote:
> On Mon, May 4, 2009 at 5:00 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com> wrote:
>> Salut,
>>
>> Thomas Gideon wrote:
>>>
>>> Any thoughts on my double response problem?
>>
>> You means enabling sendfile and comet support at the same time? I
>> don't
>> think 2.1 supports that but I will take a look. Mainly the send-file
>> AsyncFilter is conflicting with CometAsyncFilter.
>
> Yes, enabling both filters at the same time and the resulting doubling
> of response content.
>
> If it comes to it, we could create another listener on another port,
> yes? So our existing one, handling 8080, could have just
> grizzly-sendfile enabled. The other one could have CometAsyncFilter
> enabled and then they would not interfere? This is not ideal but it
> should work, right?
>
>>> In the meantime, I was able to integrate code to use the commons
>>> fileupload utility and it works a treat. I am seeing the my upload
>>> code executing a separate thread and the comet events flowing as
>>> expected. The only problem I am encountering is for my test JSP,
>>> its
>>> response body is being sent to the browser twice.
>
> Turns out that Commons FileUpload runs into problems when run in a new
> thread but I'll post another message about that later after I've
> exhausted searches and experimenting with my own code. It is totally
> unrelated to comet support in grizzly, just some low level reliance on
> the original request thread in Coyote.
>
>>> View source shows something like, "<html>...</html><html>...</
>>> html>".
>>> If I remove the grizzly-sendfile async filter from my JVM properties
>>> for GF 2.1, then it works perfectly. If I have both comet and
>>> grizzly-sendfile enabled, I get this odd doubling behavior. I'd
>>> like
>>> to use both if at all possible since they so nicely complement each
>>> other for this slow transfer of large files problem I original
>>> described.
>>
>> Yes this is exactly what I was thinking. Can you try something? In
>> domain.xml, put the CometAsyncFilter before the send-file Filter:
>>
>> -
>> Dcom
>> .sun
>> .enterprise
>> .web
>> .connector
>> .grizzly
>> .asyncFilters
>> =CometAsyncFilter,com.igorminar.grizzlysendfile.SendfileFilter
>
> I did that and while it improved the response from my upload servlet,
> the initial JSP I hit that has the form with the file input still
> shows this odd behavior of doubling.
>
>> I suspect it may works as CometAsyncFilter will tell the
>> AsyncHandler to
>> invoke the next one when a request is not "comet enabled".
>
> Why would the JSP behave different than the servlet, though? If this
> were true, wouldn't changing the order of the filters fix both?
>
>
> Thanks,
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>