Re: [Bug 38943] - missing notification API for http-async

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

> http://issues.apache.org/bugzilla/show_bug.cgi?id=38943
> ------- Additional Comments From olegk@apache.org  2006-03-23 16:43 -------
> (1) OK. Now I know what I was missing. So, essentially you want the consumer of
> the notification interface simply to queue the responses up for processing
> rather than to process them.

Yes, exactly. That was my working assumption right from the start.
I would like to keep this restriction (and enforce it rigorously)
until I have completed some production ready dispatchers. Then we
can consider more tolerant dispatchers. Lifting the restriction will
not break any code. Other event handling frameworks have a similar
restriction, though it is usually more informal. For example the AWT:
http://java.sun.com/docs/books/tutorial/uiswing/events/generalrules.html
(first section of "Design Considerations").

The reason why I want to enforce "good behavior" of developers rather
than giving advice and hoping for the best is simple: bad experience.
I have seen code from a skilled developer who used an AWT event callback
to perform communication with a Smart Card, thereby triggering a
password dialog. The UI consisted of three or four windows which were
frozen for 30s or more - except for the password dialog of course.

> I thought differently of it and would certainly
> prefer both options.

I have pondered this more than once. There really isn't anything wrong
with handling a redirect (including a few KB of HTML) in the handler.
But it's Pandora's Box. Once you allow access to the response entity,
somebody *will* open a file and write several MB to it. That may not be
too bad as long as we have a thread or two per connection, but ultimately
we want to have fewer threads handling more connections.

That's why I have defined (though not explicitly written down) a few
restrictions. I know I can deliver useful dispatcher implementations
based on these restrictions, though they may be less simple to use than
most people would like them to be. As you have stated before, it is
better to have something that is useful with limitations, than to
work forever one something without limitations.
I don't consider these restrictions (see below) to remain standing for
eternity. It's just that I expect new problems for every one we drop.
I don't want to get distracted, neither by problems popping up in
real life, nor by myself constantly imagining what might go wrong.
Implementing dispatchers is hard enough as it is.

And for the records, here are the restrictions and/or design guidelines:

1. Application code is not trustworthy. To keep background threads
   stable, don't let them execute any more application code than is
   absolutely necessary.

2. Request preprocessing and response postprocessing are done by
   application threads, not by background threads. Interceptors are
   considered application code. See 1 about application code.

3. Notification handlers have to be called by the background threads.
   Make sure they delegate processing to application threads as soon
   as possible. Notification handlers are application code. See 1
   about application code.

4. Notification handlers do not get access to the response entity.
   Because of 2, the response is not and can not be postprocessed at
   the time the notification handler is called. The response entity
   might not be accessible without postprocessing in the first place,
   for example because of content decompression. Apart from that,
   processing huge response entities is the biggest temptation for
   developers to implement time consuming handler methods. Denying
   access to the response entity encourages 3.

The restriction that notification handlers are not allowed to call
handle.getResponse() or handle.awaitResponse() is a direct result of 2.
Both methods perform response postprocessing in the calling thread.

cheers,
  Roland

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