On Thu, 2014-12-04 at 11:41 +0100, Ander Juaristi Alamos wrote:
> Hi all,
>
> I'm trying to send a non-blocking HTTP request, and based on the
> documentation and some source code lookup, I've written the following code:
>
> BasicHttpEntityEnclosingRequest request = new
> BasicHttpEntityEnclosingRequest("GET", "/");
> BasicHttpEntity entity = new BasicHttpEntity();
>
> InetSocketAddress addr = new InetSocketAddress("www.****.es", 80);
> SocketChannel socket = SocketChannel.open(addr);
> socket.configureBlocking(false);
> SelectionKey sk = socket.register(Selector.open(), socket.validOps(), null);
>
> IOSessionImpl ioSess = new IOSessionImpl(sk, mySessionClosedCallback);
> DefaultNHttpClientConnection nbConn =
> new DefaultNHttpClientConnection(ioSess, 8*1024);
>
> nbConn.submitRequest(request);
>
> while(!nbConn.isRequestSubmitted());
> nbConn.close();
>
> Unfortunately, it doesn't work as expected. It gets blocked forever in the
> while loop, because nbConn returns always false. What's more, I can't see any
> actual data being sent from my computer after the call to submitRequest().
> The only traffic I see is the TCP connection being established when I call
> SocketChannel.open().
>
This is hardly surprising. The request head gets committed to the
session output buffer but the content of the buffer never gets flushed
to the underlying socket channel.
> What I want to do is to establish a non-blocking connection, send an HTTP
> request, let HttpCore do the decoding work (so I don't have to write an HTTP
> chunk decoder myself) for me and then close the socket.
> I don't want to use the IO dispatcher, since I've observed a separate thread
> must be created solely for it, and I don't want that, because my threads are
> state machines that do different things.
That is not going to work. One needs an I/O selector that can select
channels for I/O events. While might be able to interact with the
selector without a dedicated thread but it is just so much easier with a
dedicated i/o dispatch thread.
> For now, I'll stick to that model.
>
> In short, instead of letting HttpCore signal me when an event happens, I'd
> rather poll HttpCore periodically to see if anything has happened and if it
> has, get the data decoded. If it hasn't, I'll do other things and poll again
> later. Is this possible with HttpCore, or not? Or maybe should I use
> HttpClient instead?
>
All this for what? To avoid running one extra thread? This makes no
sense to me what so ever.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
