Actually after looking a little more my issue is that mongrel2 doesn't
trigger RESP_SENT for requests sent to a handler (it does for directory
backends and the browser sends a request for favicon.ico so it made me
think it was triggering RESP_SENT) and it never runs filters registered
for CLOSE. I'll look into making that work.
-Rob
On 5/18/12 11:24 AM, Rob LaRubbio wrote:
> I think the issue I'm seeing is that the browser keeps the connection
> open with the server so mongrel2 moves the connection through it's
> state machine and eventually closes it. When curl issues the request
> it closes the connection immediately after retrieving the URL and it
> looks like mongrel2 doesn't finish running through it's connection
> state machine. I do notice that when the request comes from curl
> mongrel2 sends my handler this message:
>
> request:
> {"conn_id":"17","sender":"38f857b8-cbaa-4b58-9271-0d36c27813c4","path":"@*","body":"{\"type\":\"disconnect\"}","data":{"type":"disconnect"},"headers":{"METHOD":"JSON"}}
>
> I never get that for a request when a browser initiates the connection.
>
> Anyway that is my current theory. I'm going to have to drop this
> issue soon to move onto other more pressing issues.
>
> -Rob
>
> On 5/18/12 7:46 AM, Loic d'Anterroches wrote:
>>
>> On 2012-05-17 21:16, Justin Karneges wrote:
>>> This week I noticed that Mongrel2's python library doesn't issue close
>>> messages by default. Of course this is to ensure streaming works,
>>> but for some
>>> reason I figured if Content-Length was passed and enough content
>>> sent, then
>>> either the python library would send a close message or Mongrel2 would
>>> automatically close the connection but it turns out that neither of
>>> these
>>> things actually happen.
>>>
>>> Curl and pretty much every browser seems to receive HTTP responses
>>> just fine
>>> with this behavior. But some other clients are pickier, and need the
>>> explicit
>>> close (like Pingdom for example). I'm not sure what the right server
>>> behavior
>>> is, but I've started issuing explicit close messages from my
>>> handlers when my
>>> intention is that the HTTP response is complete.
>>>
>>> I don't know if this is the issue you're seeing, but I'm mentioning
>>> it just in
>>> case.
>> 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.
>>
>> loïc
>>
>>> On Thursday, May 17, 2012 11:49:00 AM Alberto Salce wrote:
>>>> Could this be related to why ApacheBenchmark and Mongrel2 don't get
>>>> along. AB just hangs like if the connections are not being accepted.
>>>> Siege works just fine.
>>>>
>>>> On 5/17/2012 12:14 PM, Rob LaRubbio wrote:
>>>>> I'm trying to write a filter that I can use to track how long
>>>>> requests
>>>>> are taking to run through my system. The filter is pretty simple, it
>>>>> just intercepts the REQ_RECV and RESP_SENT states, tracks the time of
>>>>> each and prints it.
>>>>>
>>>>> When I run my filter and access my server with a browser I see both
>>>>> states execute and the filter correctly prints the time. However
>>>>> if I
>>>>> access my server using curl on the command line I only see
>>>>> REQ_RECV. I
>>>>> do see the response from my service in the terminal and the curl
>>>>> command
>>>>> returns. I've also tried different combination of states with
>>>>> HANDLER&
>>>>> CLOSED but I still see the same results. I'm a little stumped by
>>>>> this
>>>>> so any suggestions on where to look next would be really helpful.
>>>>>
>>>>> -Rob
