On 03/08/2006 03:46 AM, Jim Jagielski wrote:
> How about something like this? I whipped this out very quickly
> and just did some quick compile and config-test tests on it...
> Comments before I commit sometime tomorrow:
Basicly looks good to me. Thanks for doing so. Some comments inline.
>
> - */
> - if (apr_poll(conn_poll, 1, &conn_poll_fd, FLUSH_WAIT)
> - == APR_TIMEUP) {
> + if ( (conn->worker->flush_packets == flush_on) ||
> + ( (conn->worker->flush_packets == flush_auto) &&
> + (apr_poll(conn_poll, 1, &conn_poll_fd, FLUSH_WAIT)
> + == APR_TIMEUP) ) ) {
Shouldn't we make the size of FLUSH_WAIT configurable somehow (possibly in a
next step)?
> @@ -366,6 +355,7 @@
> "proxy: error processing body");
> isok = 0;
> }
> + /* XXX: what about flush here? See mod_jk */
We sent an eos bucket down the chain just a few lines up. Doesn't this cause a
flush
of the remaining data by the core output filter?
> ===================================================================
> --- modules/proxy/mod_proxy.h (revision 384045)
> +++ modules/proxy/mod_proxy.h (working copy)
> @@ -301,6 +301,11 @@
> #if APR_HAS_THREADS
> apr_thread_mutex_t *mutex; /* Thread lock for updating address cache */
> #endif
> + enum {
> + flush_off,
> + flush_on,
> + flush_auto
> + } flush_packets; /* how to deal with bad headers */
Just a style question: Shouldn't we define a type for this outside the struct
and
declare flush_packets as this type?
Regards
Rüdiger
