Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73F38.32D0C72C"
Content-class: urn:content-classes:message
Subject: Intended usage of DefaultConnectingIOReactor in httpcore
Date: Tue, 23 Jan 2007 13:48:18 -0800
Message-ID: <94511A2526233044AC4E4C278B80B3BA386097@IRIS.electric-cloud.com>
Thread-Topic: Intended usage of DefaultConnectingIOReactor in httpcore
Thread-Index: Acc/ODFSGc9hrtq+R2mjlDJaseDwvw==
From: "Anders Wallgren" <anders@electric-cloud.com>
To: <httpcomponents-dev@jakarta.apache.org>

------_=_NextPart_001_01C73F38.32D0C72C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.

=20

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.

=20

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.

=20

What am I missing?

=20

anders

=20

=20


------_=_NextPart_001_01C73F38.32D0C72C--