Hi Oleg, > http://issues.apache.org/bugzilla/show_bug.cgi?id=38943 > ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
