|
Jean Lagarde
jean.lagarde at gmail.com
Wed Dec 10 22:54:02 EST 2008
You had put the flush under an "if not filter.closed:", but you wrote in the last entry of that ticket that the Infrae guys reported it hadn't fixed their problem. I did patch my version (commented out the whole if block). Tramline doesn't seem to be aggressively maintained these days (at least not by Infrae -- a branch I was talking about was from someone else). I did a quick search for similar functionality but did not find anything. If I was to find the time to do this myself, I would probably look at the source of mod_upload as a starting point. Thanks again for the help, -- Jean On Wed, Dec 10, 2008 at 7:25 PM, Graham Dumpleton < graham.dumpleton at gmail.com> wrote: > 2008/12/11 Jean Lagarde <jean.lagarde at gmail.com>: > > Thanks Graham, > > The difference is very clear now. > > Yes I agree that performance with mod_python is not optimal, but for now > > it's a compromise because I'm using an existing product > > ( http://www.infrae.com/products/tramline -- I know there's been other > > questions about this product on this list before). The question came up > > because there's a couple of branches of it around and I wanted to > understand > > what was going on. > > Hmmm, are they still claiming mod_python needs to be patched? I can't > remember the change they were saying needed to be made, but couldn't > see how that change fixed anything. A different change was made for > another issue in code which was found when investigating their change, > but not sure I ever got back any conclusive response as to whether > that addressed problem. There ticket related to that is: > > http://issues.apache.org/jira/browse/MODPYTHON-76 > > Tramline was a good example of something that should have been a > Apache C module. I wouldn't be surprised actually if one already did > exist that does the same thing. > > Graham > > > -- Jean > > > > On Wed, Dec 10, 2008 at 2:13 AM, Graham Dumpleton > > <graham.dumpleton at gmail.com> wrote: > >> > >> 2008/12/10 Jean Lagarde <jean.lagarde at gmail.com>: > >> > Hi all, > >> > The subject says it all. The documentation seems a little sparse on > the > >> > topic. The description of pass_on is: > >> > Passes all data through the filter without any processing. > >> > > >> > The description of disable is: > >> > Tells mod_python to ignore the provided handler and just pass the data > >> > on. > >> > (which also states that mod_python uses that one internally). > >> > "passes all data through" and "just pass the data on" sound like the > >> > same > >> > thing to me. What is the additional functionality to "ignore the > >> > provided > >> > handler"? I assume that there is a difference between the two methods > >> > and I > >> > would like to know what it is no matter how subtle. I'm looking for > the > >> > most > >> > CPU efficient way to decide early on in the execution of a filter that > >> > we > >> > don't want to filter a particular request in any way, but maybe > >> > understanding the difference would help me to make a better use of > >> > mod_python filters in other ways. > >> > I did try to use both in code, and on one server with one version of > >> > Apache > >> > 2 (and other components) it seemed to make no functional difference > >> > (although I did not attempt to closely measure CPU usage), whereas on > >> > another server with an earlier version of Apache 2 (and other > >> > components), > >> > using disable() caused no error, but dropped values from POST forms > >> > passed > >> > on to PHP scripts. > >> > Thanks for any info. I did search the lists, but only found one > comment > >> > on > >> > someone's code from Graham that "Normally 'filter.pass_on()' would be > >> > used > >> > here, not 'filter.disable()'", but without explaining why. > >> > >> If you use disable(), your filter will never be called for that > >> request (input or output as appropriate) again. > >> > >> If you use pass_on(), then it is passing on data available to that > >> specific call to your filter function. > >> > >> The distinction exists because your filter function can be called > >> multiple times for a request. The latter is allowing you to pass on > >> the data for that call, but still allowing you the option to process > >> data in a subsequent call of the filter function. > >> > >> The disable() call is used internally to mod_python to ensure that > >> filter function is never called again for a specific request if the > >> filter function itself raises an exception of some sort. If it doesn't > >> do this you could end up with a loop if the error in filter function > >> actually generates output, for which it would then call the filter > >> function again, etc etc. > >> > >> FWIW, if you are concerned about performance in any way, then you > >> shouldn't be using mod_python to implement Apache input/output > >> filters. Yes you can write filters with mod_python, but it will impact > >> performance. For best performance you should write filters in C code > >> as proper Apache module. > >> > >> Graham > > > > > > _______________________________________________ > > Mod_python mailing list > > Mod_python at modpython.org > > http://mailman.modpython.org/mailman/listinfo/mod_python > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20081210/376da38d/attachment.html
|