Salut,
Thomas Gideon wrote:
> 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.
Great. Mainly, you just need to fa (or scan) the following file:
https://glassfish.dev.java.net/public/GovernancePolicy.html
If you scan it, send it to me and I will process it internally.
>
> 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.
OK I need to take a close look at what's happening. To clarify, I just
need to install both extension, e.g. CometAsyncFilter and
SendfileFilter, right?
Thanks!
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>