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