Thanks, I will test this out as soon as I can. If the code was for a
personal project, then yes, I'd be more than happy to share it. Some
of the code in the sample app is adapted from real code from my
employer's codebase. Let me ask their permission and get back to the
list.
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
>