Hi,
Your suggestion worked well, but I think I ran into a problem with it (using
A6, if it matters). I ended up with a hung IOReactor thread:
Thread [I/O dispatcher 2] (Suspended)
KQueueArrayWrapper.register0(int, int, int, int) line: not available
[native method]
KQueueArrayWrapper.setInterest(int, int) line: 99
KQueueSelectorImpl.putEventOps(SelectionKeyImpl, int) line: 179
SocketChannelImpl.translateAndSetInterestOps(int, SelectionKeyImpl)
line: 733
SelectionKeyImpl.nioInterestOps(int) line: 87
SelectionKeyImpl.interestOps(int) line: 65
IOSessionImpl.clearEvent(int) line: 125
AsyncHTTPClient$AsyncConnection(DefaultNHttpClientConnection).produceOutput(NHttpClientHandler)
line: 183
AsyncHTTPClient$EventDispatch(DefaultClientIOEventDispatch).outputReady(IOSession)
line: 102
AsyncHTTPClient$EventDispatch.outputReady(IOSession) line: 353
BaseIOReactor.writable(SelectionKey) line: 109
BaseIOReactor(AbstractIOReactor).processEvent(SelectionKey) line: 192
BaseIOReactor(AbstractIOReactor).processEvents(Set) line: 174
BaseIOReactor(AbstractIOReactor).execute() line: 137
BaseIOReactor.execute(IOEventDispatch) line: 69
AbstractMultiworkerIOReactor$Worker.run() line: 281
Thread.run() line: 613
The AsyncHTTPClient class is mine, but it is just very thin wrappers on the
default implementations. Anyway, the thread hangs like this while trying to
clear the write interest on the SelectionKey. I only seem to run into this at
high (> 1000 per second) request rates.
I think this may actually be related to waking up the the IOControl:
conn.requestOutput();
this ends up here:
public void setEvent(int op) {
if (this.status == CLOSED) {
return;
}
synchronized (this.key) {
int ops = this.key.interestOps();
this.key.interestOps(ops | op);
this.key.selector().wakeup();
}
}
However, several sites suggest that concurrent modification of SelectionKeys is
a recipe for disaster:
http://rox-xmlrpc.sourceforge.net/niotut/index.html
As a result, if you plan to hang onto your sanity don't modify the selector
from any thread other than the selecting thread. This includes modifying the
interest ops set for a selection key, registering new channels with the
selector, and cancelling existing channels.
But that is _exactly_ what I am doing here. The thread that wants the
connection is touching the SelectionKey and the IOReactor (I/O dispatcher)
thread is also touching it.
Am I understanding this correctly?
Thanks,
David Koski
-- Oleg Kalnichevski wrote :
On Thu, 2007-07-12 at 14:10 -0700, David Koski wrote:
> Hi,
>
> I have been reading NHttpClient and I think I finally understand how
> it all works, but I am a bit stuck with how to use it. Let's say I
> wanted to build something along the lines of a load balancer: many
> incoming connections, many outgoing connections, most are idle or
> waiting for a response.
>
> Focusing on the outgoing connections part, I want to have keep-alive
> connections to a set of hosts, multiple connections per port. For
> example:
>
> LB -> host1:80
> LB -> host1:80
> LB -> host1:80
>
> LB -> host2:80
> LB -> host2:80
>
> If I have a queue of operations I want to do, I can see how I might
> use a series of ioReactor.connect() calls to create the connections
> and have submitRequest() methods in my HttpRequestExecutionHandler
> pull them off the queue and service them.
>
> The problem I am having is dealing with the steady state. I would
> like to keep these connections around for a while (and indeed using
> the DefaultConnectionReuseStrategy they are kept alive. However, once
> my queue drains and my submitRequest() method returns null, how do I
> wake the handlers back up? I can see any way to get the reactor to
> call back into my handler without opening a new connection.
>
> Am I missing something? Or going about this the wrong way?
>
Hi David
Just invoke IOControl#requestOutput() (implemented by all NHttp
connections) and it will cause the I/O reactor to fire up the
NHttpClientHandler#requestReady() event, which you can use to submit a
new request on that connection
Hope this helps
Oleg
> Thanks,
> David Koski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
http://www.opensubscriber.com/message/[EMAIL PROTECTED]/7128633.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
