You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roy Hashimoto <ro...@gmail.com> on 2019/09/18 00:23:36 UTC

BasicResponseConsumer#failed() and BasicResponseProducer#failed()

Why don't BasicResponseConsumer#failed()
<https://github.com/apache/httpcomponents-core/blob/1a3aff635fa20101373412d1b56ae1b4bd96de1f/httpcore5/src/main/java/org/apache/hc/core5/http/nio/support/BasicResponseConsumer.java#L145>
and BasicResponseProducer#failed()
<https://github.com/apache/httpcomponents-core/blob/1a3aff635fa20101373412d1b56ae1b4bd96de1f/httpcore5/src/main/java/org/apache/hc/core5/http/nio/support/BasicResponseProducer.java#L108>
call failed() on their dataConsumer and dataProducer members (respectively)?

I've created a subclass of AsyncEntityProducer that generates response data
using a Kotlin coroutine. I override failed() and releaseResources() like
this:

  private val responseContinuation = AtomicReference<Continuation<Unit>>()
  private val exception = AtomicReference<Exception>()

  override fun failed(cause: Exception) {
    Log.e(TAG, "", cause)
    exception.set(cause)
  }

  override fun releaseResources() {
    val cause = exception.get()
    responseContinuation.getAndSet(null)?.resumeWithException(cause)
  }

The details of the code are not important. Essentially in releaseResources()
I'm assuming that failed() will already have been called if the exchange is
not completing normally so I can clean up (no stuck coroutines). What I
observe on a prematurely closed connection is that failed() has not been
called.

BasicResponseProducer and BasicResponseConsumer forward other events to
their wrapped AsyncEntity* objects, but not failed(). Is there a reason for
that and a preferred alternative way to detect an abnormal exchange?

Thanks!
Roy

Re: BasicResponseConsumer#failed() and BasicResponseProducer#failed()

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2019-09-17 at 17:23 -0700, Roy Hashimoto wrote:
> Why don't BasicResponseConsumer#failed()
> <
> https://github.com/apache/httpcomponents-core/blob/1a3aff635fa20101373412d1b56ae1b4bd96de1f/httpcore5/src/main/java/org/apache/hc/core5/http/nio/support/BasicResponseConsumer.java#L145
> >
> and BasicResponseProducer#failed()
> <
> https://github.com/apache/httpcomponents-core/blob/1a3aff635fa20101373412d1b56ae1b4bd96de1f/httpcore5/src/main/java/org/apache/hc/core5/http/nio/support/BasicResponseProducer.java#L108
> >
> call failed() on their dataConsumer and dataProducer members
> (respectively)?
> 
> I've created a subclass of AsyncEntityProducer that generates
> response data
> using a Kotlin coroutine. I override failed() and releaseResources()
> like
> this:
> 
>   private val responseContinuation =
> AtomicReference<Continuation<Unit>>()
>   private val exception = AtomicReference<Exception>()
> 
>   override fun failed(cause: Exception) {
>     Log.e(TAG, "", cause)
>     exception.set(cause)
>   }
> 
>   override fun releaseResources() {
>     val cause = exception.get()
>     responseContinuation.getAndSet(null)?.resumeWithException(cause)
>   }
> 
> The details of the code are not important. Essentially in
> releaseResources()
> I'm assuming that failed() will already have been called if the
> exchange is
> not completing normally so I can clean up (no stuck coroutines). What
> I
> observe on a prematurely closed connection is that failed() has not
> been
> called.
> 
> BasicResponseProducer and BasicResponseConsumer forward other events
> to
> their wrapped AsyncEntity* objects, but not failed(). Is there a
> reason for
> that and a preferred alternative way to detect an abnormal exchange?
> 
> Thanks!
> Roy

Roy

There is no particular reason for the current behavior other than the
intent to release resources as early as possible. Feel free to raise a
PR with the changes you deem necessary.

Oleg 



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