[ http://issues.apache.org/jira/brows...2362
117 ]

Graham Dumpleton commented on MODPYTHON-76:
-------------------------------------------

No response from the person who reported this yet, so am trying again.

In the mean time, I have seen myself in my own experiments that an output fi
lter can be called an extra time after the filter has already been closed be
cause of the mandatory flush that is occuring. This doesn't seem to happen i
n all cases though. The fac
t that a filter is called after the close has occured is definitely not good
 though as any state it has may be bogus and thus problems could occur.

Thus reasonably confident that fix above would most likely solve the origina
l problem.

> input filter hangs in combination with mod_proxy
> ------------------------------------------------
>
>          Key: MODPYTHON-76
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-76
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.2, 3.1.4
>  Environment: Linux, Apache 2.024 and unreleased Apache 2.0.x svn version.
>     Reporter: Martijn Faassen

>
> Input filters hang when mod_proxy is in use. Other behavior seen is infini
te calls of the input filter function even though the data has already
> been processed.
> In Apache 2.0.24, this problem seems to be fundamental; I have no way to g
et rid of the hang, except perhaps in the case of an input filter that
> does not change the size of the passed-through data.
> In svn Apache, the problem goes away as soon as I remove the filter.flush(
) in apache.py's FilterDispatch handler. svn Apache does according to its ch
angelog contain a fix to mod_proxy's handling of input filters.
> For my application, use of mod_proxy is essential, as mod_python is essent
ially proxying another web server process.
> Output filters do not seem to be affected by the presence of filter.flush(
), and in fact filter.flush() is important to make sure memory use remains s
mall when handling large amounts of data being outputted by the server.
> All of this is rather hairy and I don't know quite what to blame; part of this see
ms indeed due to Apache itself, but perhaps not everything.

[ Post a follow-up to this message ]