> -----Ursprüngliche Nachricht----- > Von: Mladen Turk > >
First: I am the author. > Hi, > > I would love that we remove the FLUSHING_BANDAID from the code > because it concept breaks the AJP protocol specification. I do not understand how this breaks the spec. There might be reasons to handle this differently, but I see no violation of the specs. The flushing bandaid simply tries to detect whether it needs to add a flush bucket or not after the data of *one* packet has been added to the brigade. So if buffering the data in the core output filter without the flushing bandaid or with flush=off does not break the spec and if setting flush=on does not break the spec how does the flushing bandaid breaks this? > > Instead FLUSHING_BANDAID I propose that we introduce a new > directive 'flush=on' that would behave like the most recent > mod_jk directive 'JkOptions +FlushPackets'. The drawback of this solution form my point of view is that - The user has to configure it - It is a bang bang switch: Either you flush after each packet or never do explicit flushing (apart from the case that the core buffer is filled). BTW: mod_proxy_http also tries to be that intelligent, but it does not work as the EAGAIN handling does not work as expected and httpd always reads in blocking mode from the backend. > > The point is that the AJP protocol is packet based, so trying > to mimic the 'stream' behavior is bogus. > Further more, this (FLUSHING_BANDAID) does not resolve the > explicit flush from the application server, because it take Ok, it does not do this exactly, but in most cases it works, because if you flush data explicitly on the application server it usually takes some time until you sent the next data. > care only on the transport rather then a spec. > > I know that for such cases we would need to extend the AJP > protocol with explicit flushing, but for now the only solution is > to have an directive that will flush on each packet. That seems to be the final solution to me. Something like a SEND_BODY_FLUSH AJP message. > > So, since FLUSHING_BANDAID has none particular usage I'm asking > the author to remove that code, so we can work on a packet > flushing rather then a time based one. > I am happy to discuss a better solution. As the name says it is a BANDAID :-). So I am keen on additional proposals / comments on this. As a summary from your side I see: 1. Extend AJP protocol [The desired target from my view]. 2. Add an option to flush after every AJP packet [has some drawbacks from my point of view (s.o).] Regards Rüdiger
