loop_handlers.asciidoc 3.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124
  1. [[loop_handlers]]
  2. == Loop handlers
  3. Loop handlers are a special kind of HTTP handlers used when the
  4. response can not be sent right away. The handler enters instead
  5. a receive loop waiting for the right message before it can send
  6. a response.
  7. Loop handlers are used for requests where a response might not
  8. be immediately available, but where you would like to keep the
  9. connection open for a while in case the response arrives. The
  10. most known example of such practice is known as long polling.
  11. Loop handlers can also be used for requests where a response is
  12. partially available and you need to stream the response body
  13. while the connection is open. The most known example of such
  14. practice is server-sent events.
  15. While the same can be accomplished using plain HTTP handlers,
  16. it is recommended to use loop handlers because they are well-tested
  17. and allow using built-in features like hibernation and timeouts.
  18. Loop handlers essentially wait for one or more Erlang messages
  19. and feed these messages to the `info/3` callback. It also features
  20. the `init/2` and `terminate/3` callbacks which work the same as
  21. for plain HTTP handlers.
  22. === Initialization
  23. The `init/2` function must return a `cowboy_loop` tuple to enable
  24. loop handler behavior. This tuple may optionally contain
  25. a timeout value and/or the atom `hibernate` to make the
  26. process enter hibernation until a message is received.
  27. This snippet enables the loop handler:
  28. [source,erlang]
  29. ----
  30. init(Req, State) ->
  31. {cowboy_loop, Req, State}.
  32. ----
  33. This also makes the process hibernate:
  34. [source,erlang]
  35. ----
  36. init(Req, State) ->
  37. {cowboy_loop, Req, State, hibernate}.
  38. ----
  39. === Receive loop
  40. Once initialized, Cowboy will wait for messages to arrive
  41. in the process' mailbox. When a message arrives, Cowboy
  42. calls the `info/3` function with the message, the Req object
  43. and the handler's state.
  44. The following snippet sends a reply when it receives a
  45. `reply` message from another process, or waits for another
  46. message otherwise.
  47. [source,erlang]
  48. ----
  49. info({reply, Body}, Req, State) ->
  50. cowboy_req:reply(200, #{}, Body, Req),
  51. {stop, Req, State};
  52. info(_Msg, Req, State) ->
  53. {ok, Req, State, hibernate}.
  54. ----
  55. Do note that the `reply` tuple here may be any message
  56. and is simply an example.
  57. This callback may perform any necessary operation including
  58. sending all or parts of a reply, and will subsequently
  59. return a tuple indicating if more messages are to be expected.
  60. The callback may also choose to do nothing at all and just
  61. skip the message received.
  62. If a reply is sent, then the `stop` tuple should be returned.
  63. This will instruct Cowboy to end the request.
  64. Otherwise an `ok` tuple should be returned.
  65. === Streaming loop
  66. Another common case well suited for loop handlers is
  67. streaming data received in the form of Erlang messages.
  68. This can be done by initiating a chunked reply in the
  69. `init/2` callback and then using `cowboy_req:chunk/2`
  70. every time a message is received.
  71. The following snippet does exactly that. As you can see
  72. a chunk is sent every time an `event` message is received,
  73. and the loop is stopped by sending an `eof` message.
  74. [source,erlang]
  75. ----
  76. init(Req, State) ->
  77. Req2 = cowboy_req:stream_reply(200, Req),
  78. {cowboy_loop, Req2, State}.
  79. info(eof, Req, State) ->
  80. {stop, Req, State};
  81. info({event, Data}, Req, State) ->
  82. cowboy_req:stream_body(Data, nofin, Req),
  83. {ok, Req, State};
  84. info(_Msg, Req, State) ->
  85. {ok, Req, State}.
  86. ----
  87. === Cleaning up
  88. Please refer to the xref:handlers[Handlers chapter]
  89. for general instructions about cleaning up.
  90. === Hibernate
  91. To save memory, you may hibernate the process in between
  92. messages received. This is done by returning the atom
  93. `hibernate` as part of the `loop` tuple callbacks normally
  94. return. Just add the atom at the end and Cowboy will hibernate
  95. accordingly.