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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
