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.
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? This would allow me
to avoid having to retain a reference to the main selector and its
selectionkey resulting in less clutter.
/i