On Tue, 2008-01-22 at 16:52 -0500, [EMAIL PROTECTED] wrote:
> 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?
>
David,
The javadocs of the SelectonKey clearly states the class is threading
safe [1]:
"... Selection keys are safe for use by multiple concurrent threads..."
One certainly should not attempt to access the selector from multiple
threads but it is completely new to me some people think this also
applies to the selection keys. Selection keys would be completely
pointless if they were not threading safe
Can this be a JRE issue? What is the JRE you are using?
Oleg
[1]
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/SelectionKey.html
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
