Re: Throwing socketTimeoutException within HttpAsyncResponseConsumer consumeContent method
On Thu, 2016-10-20 at 12:11 +0200, Joan Balagueró wrote:
> Hello,
>
> In my async client pool, Ive currently set up a select interval of 1000ms.
> But I need to control response timeouts of 50ms, 100ms, etc.
>
> So Ihave tried to implement something like this in the 'consumeContent'
> method of my 'HttpAsyncResponseConsumer':
>
> public void consumeContent(final ContentDecoder decoder, final IOControl
> ioctrl) throws IOException
> {
> int numBytesRead;
>
> if (this.bbuf == null)
> {
>this.bbuf = ByteBuffer.allocate(32768);
>this.vbaos = new VentusByteArrayOutputStream();
> }
>
> // If the difference between now and the starting point of the request
> (when I sent it to the server) is greater than 8ms, throw a
> SocketTimeoutException.
> long diff = System.currentTimeMillis() - this.startTime;
> if (diff >= 8) throw new java.net.SocketTimeoutException("Socket timeout
> :: consumeContent :: [ " + diff + "ms > " + "8ms ]");
>
> while ( (numBytesRead = decoder.read(this.bbuf)) > 0 )
> {
>this.vbaos.write(this.bbuf.array(), 0, numBytesRead);
>this.bbuf.clear();
> }
> }
>
> And it seems to work. The exception is thrown, the consumeContent is no
> longer called, the 'responseCompleted' method is not called, and the async
> client calls the 'failed' method that logs the exception correctly.
>
> My question is: can I be sure that the response reading was stopped, the
> connection was aborted (even without completing the response reading)
Yes, you can.
> and
> the thread was released?
>
I am not sure I understand what thread you are referring to.
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Controlling releaseConnection
On Wed, 2016-10-19 at 10:14 -0400, Pellerin, Clement wrote: > I agree with you this feature is strange and need not be added to the library. > As I said before, I need to preserve this feature for backwards compatibility. > It has something to do with delaying the emission of an MDN in an AS2 gateway > so it represents the status of the receiver instead of the man in the middle. > Again, please don't ask me to change the architecture of the solution. > We don't own the application and we can't change it. Nevertheless it must > continue to work after we port to HttpClient 4.5.2 > > As for the work-around, I have something working but it duplicates too much > code for my taste. I think this is a nice opportunity for HttpClient > to learn what it is like to try to subclass its engine. > > I am subclassing HttpClientBuilder to override createMainExec() > to return my own implementation of the ClientExecChain. > This is nice. > > Unfortunately, our subclass of ClientExecChain must be in the > org.apache.http.impl.execchain package because support classes > in that package are all package private. This is annoying. > > I modified the problematic code in ClientExecChain.execute() > but that was not enough. I need to trap the EofSensorWatcher > of the response HttpEntity. That requires duplicating > HttpResponseProxy and ResponseEntityProxy. > Again this must be done in the apache package. > > The release should go through the ConnectionHolder since that's > where the "AtomicBoolean released" field is stored. > I thought of providing my own implementation of ConnectionHolder > with an empty releaseConnection() method, but that does not work > when ResponseEntityProxy calls cleanup(), this becomes > releaseConnection(false) which closes the connection completely. > Those classes are package private so we would not keep them API compatible between minor releases. I intend to re-evaluate the execution pipeline code in 5.0 and attempt to provide a public API based on the chain of responsibility pattern. > I would appreciate if you have better suggestions for the work-around. > It would be nice to make subclassing easier too. > > By the way, should ResponseEntityProxy.enchance() > be called enhance() instead? > Compare this to RequestEntityProxy.enhance() > Yes, it should be. Please fork HttpClient on Github and raise a PR with changes you are proposing. We can add methods to MainClientExec as long as they remain package private. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Throwing socketTimeoutException within HttpAsyncResponseConsumer consumeContent method
Hello,
In my async client pool, Ive currently set up a select interval of 1000ms.
But I need to control response timeouts of 50ms, 100ms, etc.
So Ihave tried to implement something like this in the 'consumeContent'
method of my 'HttpAsyncResponseConsumer':
public void consumeContent(final ContentDecoder decoder, final IOControl
ioctrl) throws IOException
{
int numBytesRead;
if (this.bbuf == null)
{
this.bbuf = ByteBuffer.allocate(32768);
this.vbaos = new VentusByteArrayOutputStream();
}
// If the difference between now and the starting point of the request
(when I sent it to the server) is greater than 8ms, throw a
SocketTimeoutException.
long diff = System.currentTimeMillis() - this.startTime;
if (diff >= 8) throw new java.net.SocketTimeoutException("Socket timeout
:: consumeContent :: [ " + diff + "ms > " + "8ms ]");
while ( (numBytesRead = decoder.read(this.bbuf)) > 0 )
{
this.vbaos.write(this.bbuf.array(), 0, numBytesRead);
this.bbuf.clear();
}
}
And it seems to work. The exception is thrown, the consumeContent is no
longer called, the 'responseCompleted' method is not called, and the async
client calls the 'failed' method that logs the exception correctly.
My question is: can I be sure that the response reading was stopped, the
connection was aborted (even without completing the response reading) and
the thread was released?
Thanks,
Joan.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
