This thread has migrated away from the original issue I was seeing, which was my filter not getting called for the CLOSE event. I've submitted this pull request that fixes the issue.
https://github.com/zedshaw/mongrel2/pull/132 -Rob On 5/21/12 6:22 AM, William MARTIN wrote: > I am agree with loic for a 1.8 release, because they have lot of bug fix, > like the 100% CPU bug > https://github.com/zedshaw/mongrel2/issues/131 > > For the next release, > If they have a BC break for answer, i am pro to add BC break in the > same time about the configuration, > you can read the enhancement memo i have create juste after i wrote > the mongoDB configuration module. > https://github.com/zedshaw/mongrel2/issues/97 > > With read/write configuration module, and the URI, we can write very > quickly lot of configuration backend, > - SQL databases (MySQL, PgSQL, ...) > - XML files > etc ... > > It's will allow m2sh to write the configuration in every backend with > only a first modification, all backend's write after will be > compatible. > I am ready to drive this part of the job, if everyone is aggree. > > William > > On Mon, May 21, 2012 at 3:01 PM, Loic d'Anterroches<[email protected]> wrote: >> On 2012-05-21 13:11, Florian Anderiasch wrote: >>> On 05/18/2012 04:46 PM, Loic d'Anterroches wrote: >>>> More than just in case. What you are mentioning here is also a reason >>>> some of the users are advocating a tnetstring answer from the handler to >>>> M2 and not just a raw message. As you send a raw message at the moment, >>>> outside of the "empty message" hack to close a connection from the >>>> handler (or accessing the control port), you cannot do more. With a >>>> tnetstring for M2, we could tell M2 to close the connection at the end, >>>> rate limit, consider the message as "non valuable" in the case of >>>> streaming, so if the buffer is full, just drop the message, etc. Way >>>> more control, cleanly encapsulated. >>> A bit offtopic, how's the general plan for that? >>> >>> I'd be more for getting out the next release as it is, and only then >>> focus on this tnetstring change, if at all - as that's the hardest BC >>> break we've ever had iirc. >> Should definitely go after the 1.8. We are already "late" for the 1.8 in >> terms of marketing as it gives the feeling the project is a bit "dead" >> at the moment. >> >> Note that tnetstrings to communicate back to the server is not something >> agreed by everybody, but something which has been poping on the list on >> a regular basis. The idea is definitely not from me. >> >> It would provide a lot of flexibility in the design of the filters too. >> For example, you could create an embedded varnish cache. You send an >> answer back from the application with a tnetstring telling which cache >> level you want on the answer for the given URL, then you have a filter >> on the requests which can match against the URL and conditions and >> directly answer back or things like that. >> >> You basically open the ability to have a flexible async two-way >> communication channel between the application handlers and Mongrel2. I >> don't think any webserver is offering such flexibility at the moment (if >> so, it always through headers hack which requires the parsing of the >> answer by the server). >> >> loïc > >
