Wonderful! Thank you so much both for the fixed version and for the
improvements to my sample code. With just the CometAsyncfilter
enabled, the sample code now works exactly as expected.
I did get permission to share the sample. Let me know if you want an
updated version that is a bit more complete and clean and I'd be happy
to pass that along when I have it.
I am still having one issue, though, when I re-add
com.igorminar.grizzlysendfile.SendfileFilter.
I am still seeing my response body content twice every time I hit the
index of the webapp. The response written from the uploade servlet
and CometHandler does not get double, though, when I have the comet
filter first in the list of async filter.
This issue is the only one remaining that prevents us from moving
forward with the very capable comet support. I've been talking it up
around here and there is interest in using it for a couple of other
future features in our software.
Thanks!
Thomas
On Wed, May 6, 2009 at 2:25 PM, Jeanfrancois Arcand
<Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> OK I've fixed the issue in Grizzly 1.0.28 (uploading now)
>
> https://maven-repository.dev.java.net/nonav/repository/grizzly/jars/
>
> Add it to your classpatth prefix in domain.xml
>
> I've filled issue:
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=580
>
> Mainly, when you suspend the connection, if the client starts sending bytes
> then if you don't register your CometHandler to receive asynchronous read
> events:
>
> https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/comet/CometContext.html#registerAsyncRead(com.sun.grizzly.comet.CometHandler)
>
> Grizzly Comet thinks that the connection has been closed by the remote
> client, and automatically resume the connection by invoking under the hood
> the resumeCometHandler method.
>
> What I did is I added a new default value called
> CometEngine.DISABLE_CLIENT_DISCONNECTION_DETECTION
>
> you just need to set it to:
>
> CometContext.setExpirationDelay(...)
>
> That will fixes the issue. I'm attaching the code I was using, as I did some
> improvement. BTW, would agree to gives this to the community? I think a lot
> of peoples will like to use this async upload implementation.
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
> Jeanfrancois Arcand wrote:
>>
>> Salut,
>>
>> the issue is related to common-upload. What happens is when you suspend
>> the connection, the browser sent:
>>
>>> Host: 192.168.0.101:8080
>>>
>>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
>>> rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
>>>
>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>
>>> Accept-Language: en-us,en;q=0.5
>>>
>>> Accept-Encoding: gzip,deflate
>>>
>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>>
>>> Keep-Alive: 300
>>>
>>> Connection: keep-alive
>>>
>>> Referer: http://192.168.0.101:8080/upload/
>>>
>>> Cookie: JSESSIONID=6d49c695e18b005bf7108df7eff2
>>
>> Grizzly Comet suspend the connection (since you are calling
>> addComethandler()) and send back:
>>
>>> X-Powered-By: Servlet/2.5
>>>
>>> Server: Sun Java System Application Server 9.1.1
>>>
>>> Content-Type: text/html; charset=iso-8859-1
>>>
>>> Content-Length: 33
>>>
>>> Date: Wed, 06 May 2009 16:52:13 GMT
>>
>> Then the client automatically close the connection, which internally is
>> detected by Grizzly Comet, which automatically resume your CometHandler as
>> the Request/Response becomes invalid. Any operation made by your spawned
>> Thread will produces all kind of strange issue as you are working on a
>> invalid request/response set.
>>
>> Now why sometimes the browser isn't closing the connection is puzzling.
>> I'm looking at it now, but I suspect it's because of the:
>>
>> >
>> > Accept-Encoding: gzip,deflate
>>
>> which doesn't allow Grizzly to send back a chunked response, but instead
>> send back a
>>
>> > Content-Type: text/html; charset=iso-8859-1
>> >
>> > Content-Length: 33
>>
>> so the browser automatically close the connection.
>>
>> More to come :-)
>>
>> A+
>>
>> --Jeanfrancois
>>
>>
>> Jeanfrancois Arcand wrote:
>>>
>>> Salut,
>>>
>>> Thomas Gideon wrote:
>>>>
>>>> On Tue, May 5, 2009 at 1:52 PM, Jeanfrancois Arcand
>>>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>>
>>>>> Salut,
>>>>>
>>>>> Thomas Gideon wrote:
>>>>>>
>>>>>> I am still working on JFA's suggestion of how to use Grizzly's Comet
>>>>>> support to move file uploads to their own threads. Our application is
>>>>>> often used by an entire classroom at the same time and in a lab
>>>>>> exercise all of the students may attempt to upload larger multimedia
>>>>>> files over a slow link. We've definitely seen this consume our
>>>>>> available request processing threads in Glassfish.
>>>>>>
>>>>>> I have mostly plumbed together the necessary pieces but am having
>>>>>> trouble making my code work reliably under Glassfish 2.1. Sometimes
>>>>>> it works perfectly, other times it encounters errors in the Coyote
>>>>>> request classes.
>>>>>
>>>>> Do you have the exact error?
>>>>
>>>> Yes, the most common error is:
>>>>
>>>>
>>>> [#|2009-05-05T14:18:26.745-0400|SEVERE|sun-appserver2.1|com.learningobjects.tgideon.upload.UploadPro
>>>>
>>>> cessor|_ThreadID=19;_ThreadName=Thread-66;_RequestID=77375e21-72f9-42cd-9a4e-a10f829eb101;|java.lang
>>>> .NullPointerException
>>>> at
>>>> com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest.getFormHintFieldEncoding(PwcCoyo
>>>> teRequest.java:238)
>>>> at
>>>> com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest.setRequestEncodingFromSunWebXml(
>>>> PwcCoyoteRequest.java:204)
>>>> at
>>>> com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest.getCharacterEncoding(PwcCoyoteRe
>>>> quest.java:124)
>>>> at
>>>> org.apache.coyote.tomcat5.CoyoteRequestFacade.getCharacterEncoding(CoyoteRequestFacade.ja
>>>> va:372)
>>>> at
>>>> org.apache.commons.fileupload.servlet.ServletRequestContext.getCharacterEncoding(ServletR
>>>> equestContext.java:64)
>>>> at
>>>> org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.j
>>>> ava:809)
>>>> at
>>>> org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:323)
>>>> at
>>>> org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(ServletFileUpload.java:148)
>>>> at
>>>> com.learningobjects.tgideon.upload.UploadProcessor.run(UploadProcessor.java:95)
>>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> Thanks. I'm able to reproduce the issue as well. Mainly, the Response
>>> object is being resumed and then re-used, which cause that issue. I'm
>>> looking at the code right now to see if this is an application error or a
>>> Grizzly Comet issue.
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>> |#]
>>>>
>>>>
>>>> Thomas
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>