Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Let handlers respond after timeout #363

Closed
benbro opened this Issue Jan 9, 2013 · 12 comments

Comments

Projects
None yet
3 participants

benbro commented Jan 9, 2013

An handler might want to wait X seconds for a message and if nothing happens reply with a default response.

Is it possible to add it here instead of just terminating the request?
https://github.com/extend/cowboy/blob/master/src/cowboy_handler.erl#L149

case Handler:timeout(Req, HandlerState)

Thanks

Contributor

jeremyong commented Jan 9, 2013

Something similar was brought up in #287 but I don't believe that change helps you here.

Out of curiosity, why do you need this?

benbro commented Jan 9, 2013

I'm implementing long-polling.
If handlers get a message they respond immediately.
After 20 seconds they respond with an empty response.

Contributor

jeremyong commented Jan 9, 2013

it makes more sense for your handler to do this.

the timeout that you are pointing to is used to ensure that there are no process leaks

you should probably set your own timeout and store the timer ref in the state of your handler. you can cancel it once a response is received in handle_info.

Otherwise, you'll receive a timeout message and you can do whatever you like there.

benbro commented Jan 9, 2013

There is no sense in creating two timeouts for a single handler

Owner

essen commented Jan 9, 2013

You don't have to use this timeout. Just return infinity and set your own timeout and only one will exist.

benbro commented Jan 9, 2013

If a user returns a timeout, what's wrong with asking him to decide what to do when the timeout is reached?
He can handle the timeout or just ignore it and let cowboy_handler terminate the request.

Owner

essen commented Jan 10, 2013

It's a protection against dead sockets, if you need to do things after a timeout you can do that on your own, I don't see the problem.

benbro commented Jan 10, 2013

You still get the protection and with the added value of a nice API. I can return a timeout, and when the timeout ends decide what to do with the request. Send a response to the user or 404. For me having a timeout without an option to handle it when the timeout ends just feels very weird.

Owner

essen commented Jan 10, 2013

This timeout means "the connection is gone". There's nothing to handle. It's just one call to create a timeout yourself, I don't see how that's a bad API.

benbro commented Jan 10, 2013

If you think it's such a bad idea to call Handler:timeout(Req, HandlerState) than I don't have anything else to say.

Owner

essen commented Jan 10, 2013

I don't see much point adding another callback for edge cases. :)

Owner

essen commented Jan 12, 2013

Closing, thanks!

@essen essen closed this Jan 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment