On Nov 26, 2008, at 1:22 PM, Jeanfrancois Arcand wrote:
>
>
> 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?
I believe I have copy of the comet code from gfv2ur2 and in CometTask
I see:
} finally {
// Bug 6403933
if (connectionClosed){
cometSelector.cancelKey(cometKey);
}
And in CometSelector there is:
SelectorThread st = cometTask.getSelectorThread();
SelectionKey mainKey = cometTask.getSelectionKey();
if (cometTask.getCometContext() != null){
cometTask.getCometContext().interrupt(mainKey);
}
cometEngine.interrupt(key);
st.cancelKey(mainKey);
/i
>
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>