On Nov 28, 2008, at 7:40 AM, Jeanfrancois Arcand wrote:
> Salut,
>
> Igor Minar wrote:
>> Hi there,
>> On Nov 26, 2008, at 1:22 PM, Jeanfrancois Arcand wrote:
>>>>> 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.
>> So I played with this today and realized that this api won't work
>> for me.
>> As I previously mentioned I have two kinds of algorithms blocking
>> and non-blocking (http://kenai.com/projects/grizzly-sendfile/pages/Algorithms
>> ). For in order to get the blocking algorithms to work, I need to
>> switch the SocketChannel to the blocking mode and that can be done
>> only when that channel is not registered with any selector.
>
> I see. This is easy to do with 1.9...let me reminds myself 1.0 :-)
>
>> Since addBannedSelectionKey doesn't deregister the channel from the
>> selector, it is impossible for me to switch to the blocking mode.
>> Any idea how to get around this? Is my only option to patch grizzly
>> and add my forceKeepAlive() method in order to get this to work?
>
> Hum..I don't like the solution. Let me think of it.
Any thoughts on this?
I benchmarked my blocking vs nonblocking algorithms [1] and while the
performance of nonblocking is acceptable, the performance of blocking
algorithms is superior (10-20%). I totally understand that blocking io
is ugly and doesn't scale, but I can imagine cases when performance is
more important than scalability.
Any chance I can get a patch like this accepted in grizzly:
--- DefaultProcessorTask.java.orig 2009-02-18 20:54:29.000000000 -0800
+++ DefaultProcessorTask.java 2009-02-18 22:43:16.000000000 -0800
@@ -2228,5 +2228,16 @@
public boolean getDisableUploadTimeout() {
return disableUploadTimeout;
}
+
+
+ /**
+ * Ugly patch to prevent non-keep-alive connections from being
closed when
+ * grizzly-sendfile takes over (when using a blocking algorithm).
+ */
+ public void forceKeepAlive() {
+ keepAlive = true;
+ connectionHeaderValueSet = true;
+ }
+
}
I understand that this is a hack because I basically take advantage of
the fact that keepalive connections are being closed differently than
non-keepalive connections.
A proper fix would require to add an api that would allow me to take
over responsibility for closing a socket channel when I deregister a
key from the main selector and register it with my custom (grizzly-
sendfile) selector.
If you don't like this patch then don't worry about it, I plan to use
a nonblocking algorithm by default starting with grizzly-sendfile 0.3,
but I thought that it would be nice to have full support for blocking
algorithms as well.
cheers,
Igor
[1]
http://kenai.com/projects/grizzly-sendfile/pages/Algorithms