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
>>>
>>
>