hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: DO NOT REPLY [Bug 38279] - define API for http-async
Date Sun, 22 Jan 2006 12:48:22 GMT
Hi Oleg,

> At the moment I fail to see why request preprocessing and response
> postprocessing could not be done by the dispatcher on a background
> thread, but admittedly I have not studied the case in details, so I can
> well be wrong here.

It could be done there. I just don't think it should be done there.
The background threads are a shared resource which should be used
with care. If we want to keep the number of background threads small,
we should not burden them with tasks they don't have to do.

There are two more reasons why I want pre- and postprocessing done
by application threads. First, it simplifies error handling because
exceptions will automatically be thrown in the application thread.
If preprocessing were done by background threads, a request that is
going to cause an exception would have to wait it's time in the queue,
the background thread then has to store the exception and notify the
application, which then has to retrieve the exception.
Second, it significantly reduces potential for blocking background
threads. I am terrified by the thought of an interceptor that pops up
an interactive password dialog, thereby locking up a background thread.

> The problem is not about downcasting as such. It is rather about the
> fact that the generic HttpDispatcher interface may not always be usable
> unless cast to a concrete type.

Fair concern. HttpHandle is an application interface, defining only the
methods meant to be called by applications. The downcasts are in places
where the handle implementation performs callbacks to the dispatcher it
came from. Maybe I can define the callbacks in abstract base classes.

> Overall, I think the code is good enough to be imported into SVN as is
> (probably with System.out.println() and Throwable#printStackTrace()
> problem fixed). You should go ahead and add more concrete dispatchers.
> With several dispatchers in place it will be easier to identify
> commonalities in functionality (leading to better interfaces) and those
> in code (leading to a better code reuse)

I am still more concerned about the application interfaces. I'll have
another round or two with the current use case, then tackle the one
about notification. Without a notification mechanism, http-async will
be basically useless.
I need more time with the SimpleHttpDispatcher to get a feeling for
the pitfalls waiting for me, and I don't want to update multiple
implementations for foreseeable changes in the application interface.
Also, the other dispatchers will most likely require a connection pool,
which is not available in 4.0 yet.

I hope to post preview 3 later today.


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

View raw message