hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: SessionRequest, SessionRequestCallback and other nio stuff...
Date Wed, 07 Feb 2007 15:06:33 GMT
On Wed, 2007-02-07 at 01:35 +0100, Stojce Dimski wrote:
> Hi Oleg,
> 
> Sorry for the late response but only now I have red your messages...
> 
> 1) I think that would be more wise to wait for 'requestReeceived' event
> because some client can not complete whole request, and I would initiate
> outgoing connection before complete request was loaded ?
> 

Most likely yes, because you might want to examine the 'Host' header
prior to establishing the outgoing connection,

> 2) Is it possible that I don't even receive 'inputReady' event if the
> request is not 'enclosing entity' ?
> 

Yes, absolutely. The 'inputReady' events can be fired only if the
request is meant to have content. 

> I gave a look at your 'ThrottlingHttpServiceHandler' in attempt to use
> it as an example for my server part, and looking at the code I have a
> few puzzles:
> 
> a) in a 'requestReceived' method when receiving
> HttpEntityEnclosingRequest you check if 'expectContinue' send a 'ack'
> response, but what happens if client don't 'expectContinue' ? 

It is the client side that initiates the 'expect: continue' handshake.
The server simply reacts to the presence of the 'Expect' header in the
request. I fail to see a problem here.

> Code goes
> on and asynchronously process the request trough 'executor.execute', but
> what happens if we have a big request which doesn't support
> expectContinue, wouldn't this method be followed by a series of
> 'inputReady' calls ? 

Yes, it would.

> How can we know that whole request is received and
> we can process it ? I think that the same problem is present also with
> some NHttpClientHandler ?
> 

The request entity is known to have been received in its entirety when
the corresponding Decoder interface returns #isCompleted() true. Again,
somehow I fail to see a problem here. Could you please elaborate what
you think may go wrong here?


> b) if I execute 'processRequest' asynchronously trough a executor and
> inside processRequest I invoke reactor.connect which gives me
> SessionRequest, invoking 'waitFor' would suspend this thread until
> SessionRequest is processed, but other threads and server and client
> side io threads would run undisturbed ? Do you think it is the correct
> approach ?
> 

This may work, but I would try to avoid using worker threads at all,
unless you have to perform some kind of content transformation in your
reverse proxy. If no content transformation is involved, just try to
ship content chunks to the target server as soon as they arrive. If the
target server is unable to process requests quickly enough, just disable
input on the incoming connection until the there is no more content left
in the intermediate buffer. You can throttle connections even if you are
not using worker threads.

Hope this helps

Oleg


> Thanks,
> Stojce
> 
> 
> Oleg Kalnichevski wrote:
> > (1) First off, one important thing to understand about NIO is that the
> > application does not have to react to I/O events if it is unable to
> > process them. So, after having received an incoming connection you
> > should initiate a request for an outgoing connection, update the HTTP
> > context accordingly and move on without blocking the I/O thread
> >
> > (2) If you start receiving 'input ready' events while the outgoing
> > connection is still being open, you should suspend 'input ready' events
> > by calling #suspendInput() on the incoming connection.
> >
> > (3) Once you receive a 'connection open' event for the outgoing
> > connection, re-enable 'input ready' events by calling #enableInput() on
> > the incoming connection.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message