Igor Minar wrote:
>
> On Nov 26, 2008, at 12:31 PM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Igor Minar wrote:
>>> On Nov 26, 2008, at 11:33 AM, Jeanfrancois Arcand wrote:
>>>> Thanks Igor for the feedback.
>>>>
>>>> BTW I've fixed:
>>>>
>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=289
>>> I saw that, thanks!
>>>> You can update GF with the 1.9.0 SNAPSHOT:
>>>>
>>>> http://weblogs.java.net/blog/jfarcand/archive/2008/11/updating_grizzl.html
>>>>
>>>>
>>>> and see if that works.
>>> I'll give it a shot. I ran into some class loading issues in GFv3,
>>> which I didn't have time to troubleshoot yet. I think that I'll need
>>> to rewrite my extension as on OSGi module in order to get it to work
>>> properly in GFv3.
>>
>> That sucks. Let me see if I can find something on my side.
>>
>>
>>> I'm currently targeting GFv2 because that's the version of the app
>>> server we use to run our application for which I developed this
>>> extension. But I'm interested in supporting GFv3 in the (near?)
>>> future as well. It really depends only on how much free time I have.
>>>> BTW would you be interested to contribute your extension (if it is
>>>> generic enough?)
>>> All the extension does is that sending (usually large) files to a
>>> client based on instructions from an app. It is very generic and
>>> reusable by any kind of app (JavaEE, Rails, Grails, ..) running on
>>> glassfish and in fact any app using grizzly (currently only the old
>>> grizzly version bundled with GFv2).
>>
>> OK, for people reading it is 1.0.22 :-)
>>
>>
>> This is basically a functionality that has been
>>> supported by apache and many other web servers for a long time, but
>>> never made it to glassfish or any other JaveEE server AFAIK.
>>> To keep it as generic as possible, I actually went as far as
>>> implementing my own extension points, so that I can write plugins for
>>> my grizzly extension.
>>
>> This is quite interesting. I know you were working in it but wasn't
>> aware it was public.
>>
>>> It is licensed as GPL and used in production at mediacast.sun.com.
>>> I'll try to set aside some time during the upcoming long weekend to
>>> write some user docs and explain all the benefits. Once that is done,
>>> I'll be sure to send out an announcement to this mailing list.
>>
>> Great thanks!
>>
>>> In the meantime, you can check out the source code at
>>> http://kenai.com/projects/grizzly-sendfile
>>> While I have you attention, there is one issue that I was not able to
>>> resolve, and thus had to resort to patching grizzly. My extension
>>> deregisters a channel from the grizzly's selector and uses it's own
>>> selector and worker thread pool (pipeline) to execute the request in
>>> order to have a better control over how the file download is being
>>> handled (I support several file sending algorithms).
>>> The problem I found is that without patching grizzly, my extension
>>> works properly only for HTTP keep-alive connections. If the
>>> connection is not keep-alive, grizzly will close the connection when
>>> I deregister the channel and my filter exists. This means that when I
>>> finally get around to start pumping the data to the client, the
>>> connection is already closed.
>>> What I did to resolve this was to patch DefaultProcessorTask to
>>> expose a new forceKeepAlive() method:
>>> http://kenai.com/projects/grizzly-sendfile/sources/605-Mercurial-Source-Code-Repository/revision/44 Pretty
>>> ugly, but with the API of grizzly 1.0.x, I don't think that there is
>>> a way around it. Is there any chance that you could give me a way to
>>> handle this via an official grizzly api (ideally something that would
>>> ship with glassfish v2.1). All I need is to prevent grizzly from
>>> closing the socketchannel when I deregister it from the main selector
>>> (and thus take over the responsibility for closing it).
>>
>>
>> Just invoke:
>>
>> selectorThread.addBannedSelectionKey(..);
>>
>> > /**
>> > * Add a <code>SelectionKey</code> to the banned list of
>> SelectionKeys.
>> > * A SelectionKey is banned when new registration aren't allowed
>> on the
>> > * Selector.
>> > */
>> > public void addBannedSelectionKey(SelectionKey key){
>> > bannedKeys.offer(key);
>> > }
>>
>> I'm using this trick for Comet. Which version of GF are you using? I
>> suspect the API is there.
>
> Interesting! I must have missed that while reading the Comet code.
>
> So instead of canceling the selectionkey associated with the main
> selector, you just mark it as "banned", which causes the selector to
> ignore it.
Indeed. So the CometSelector has full control over what's happening.
>
> In your comet code, you close the channel/connection by calling
> cancelKey on the main selector. Wouldn't it be possible to just close
> the channel, which cancels the key automatically?
Just to make sure, can you point me to the code?
This would allow me to
> avoid having to retain a reference to the main selector and its
> selectionkey resulting in less clutter.
I agree.
A+
-- Jeanfrancois
>
> /i
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>