On Tue, 2007-01-23 at 13:48 -0800, Anders Wallgren wrote: > I'm having problems putting DefaultConnectingIOReactor to use. It seems > the intended use it to call connect() from another thread, while > execute() is (basically), sitting on a select() in some other thread. I > say this because the timeout on the select is quite large and there is > no way to cause DefaultConnectingIOReactor to wakeup the select call, > from what I can see. > > > > My experience is that calling register() on the selector while the > selector is in a select() call in another thread makes the call to > register() block for long periods of time. Usually, the pattern is to > queue up the new connections, then call wakeup() on the selector to have > it configure the outbound connection. My experience here isn't deep, > and largely through trial and error, so I might be completely wrong on > this. >
Hi Anders, The selector in DefaultConnectingIOReactor is used exclusively to select for OP_CONNECT events, so I felt maintaining a queue for new connections might not be justified. Apparently I was wrong. Please open a bug in Jira for this issue and I'll look into it in the coming days. > > > The sample code in NHttpClient makes a few calls to connect() before > calling execute() from the same thread, so this code isn't really a > real-world example, it would seem. I've poked through the wiki but > haven't found anything relevant to the design of this piece of the code. > This problem has already been reported and fixed in the SVN trunk [1]. I am currently in the process of reviewing the client-side NIO code, so please bear with us for a little while, there will be a lot of improvements (and fixes) coming in ALPHA4 Hope this helps Oleg [1] https://issues.apache.org/jira/browse/HTTPCORE-23 > > > What am I missing? > > > > anders > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
