Expect some test e-mails for modules.a.o

2011-06-30 Thread Mark Thomas
Hi, I am in the process of migrating modules.a.o to ASF hardware. Expect some test e-mails over the next few days as I migrate and test the software. Feel free to ignore them. Mark

Re: input filters called again after Handler returns

2011-06-30 Thread Sorin Manolache
On Thu, Jun 30, 2011 at 11:12, Nick Kew wrote: > > On 30 Jun 2011, at 08:11, Sorin Manolache wrote: > >> On Thu, Jun 30, 2011 at 02:56, Jodi Bosa wrote: >>> I'm encountering a strange interaction between modules (including my own). >>> When I track it down, it appears that input filters are calle

Re: per-worker-thread counter question

2011-06-30 Thread Massimo Manghi
I found this problem conceptually interesting and worth of generalization in many contexts. I'd like to know if Neil got around the problem with something that could be a satisfying solution. thanks -- Massimo On 06/28/2011 04:57 AM, Neil McKee wrote: Hi, Here's an easy question for someo

Re: input filters called again after Handler returns

2011-06-30 Thread Nick Kew
On 30 Jun 2011, at 08:11, Sorin Manolache wrote: > On Thu, Jun 30, 2011 at 02:56, Jodi Bosa wrote: >> I'm encountering a strange interaction between modules (including my own). >> When I track it down, it appears that input filters are called after the >> handler is finished which results in 2 b

Re: input filters called again after Handler returns

2011-06-30 Thread Sorin Manolache
On Thu, Jun 30, 2011 at 09:11, Sorin Manolache wrote: > On Thu, Jun 30, 2011 at 02:56, Jodi Bosa wrote: >> I'm encountering a strange interaction between modules (including my own). >> When I track it down, it appears that input filters are called after the >> handler is finished which results in

Re: input filters called again after Handler returns

2011-06-30 Thread Sorin Manolache
On Thu, Jun 30, 2011 at 02:56, Jodi Bosa wrote: > I'm encountering a strange interaction between modules (including my own). > When I track it down, it appears that input filters are called after the > handler is finished which results in 2 bodies in the response. > > In other words, this is what