[asterisk-dev] [Code Review] 3659: res_http_websocket: Dispose of websocket correctly when writes fail; use ast_careful_write to control disconnects (Asterisk 12+)

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3659/#review12300
-----------------------------------------------------------



/branches/12/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/3659/#comment22469>

    Print what the default is.



/branches/12/configs/ari.conf.sample
<https://reviewboard.asterisk.org/r/3659/#comment22470>

    It looks like you did some tabs-to-spaces changes in this file, but you missed lines 3 and 5.



/branches/12/include/asterisk/http_websocket.h
<https://reviewboard.asterisk.org/r/3659/#comment22471>

    Give these constants AST_ prefixes since they are global.


- Mark Michelson


On June 20, 2014, 4:57 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3659/
> -----------------------------------------------------------
> 
> (Updated June 20, 2014, 4:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23917
>     https://issues.asterisk.org/jira/browse/ASTERISK-23917
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> *Note:* This issue was originally seen when sending large volumes of data to a connected ARI client over a websocket, but it theoretically could occur with any version of Asterisk that uses a websocket. This patch is for Asterisk 12. The patch for Asterisk 11 only is on https://reviewboard.asterisk.org/r/3624.
> 
> When a client takes a long time to process information received from Asterisk, a write operation using fwrite may fail to write all information. This causes the underlying file stream to be in an unknown state, such that the socket must be disconnected. Unfortunately, there are two problems with this in Asterisk's existing websocket code:
> 1. Periodically, during the read loop, Asterisk must write to the connected websocket to respond to pings. As such, Asterisk maintains a reference to the session during the loop. When ast_http_websocket_write fails, it may cause the session to decrement its ref count, but this in and of itself does not break the read loop. The read loop's write, on the other hand, does not break the loop if it fails. This causes the socket to get in a 'stuck' state, preventing the client from reconnecting to the server.
> 2. More importantly, however, is that the fwrite in ast_http_websocket_write fails with a large volume of data when the client takes awhile to process the information. When it does fail, it fails writing only a portion of the bytes. With some debugging, it was shown that this was failing in a similar fashion to ASTERISK-12767. Switching this over to {{ast_careful_fwrite}} with a long enough timeout solved the problem.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip_transport_websocket.c 416805 
>   /branches/12/res/res_pjsip/config_transport.c 416805 
>   /branches/12/res/res_pjsip.c 416805 
>   /branches/12/res/res_http_websocket.c 416805 
>   /branches/12/res/res_ari.c 416805 
>   /branches/12/res/ari/internal.h 416805 
>   /branches/12/res/ari/config.c 416805 
>   /branches/12/res/ari/ari_websockets.c 416805 
>   /branches/12/include/asterisk/res_pjsip.h 416805 
>   /branches/12/include/asterisk/http_websocket.h 416805 
>   /branches/12/configs/sip.conf.sample 416805 
>   /branches/12/configs/pjsip.conf.sample 416805 
>   /branches/12/configs/ari.conf.sample 416805 
>   /branches/12/channels/sip/include/sip.h 416805 
>   /branches/12/channels/chan_sip.c 416805 
>   /branches/12/UPGRADE.txt 416805 
> 
> Diff: https://reviewboard.asterisk.org/r/3659/diff/
> 
> 
> Testing
> -------
> 
> Prior to the patch (using Asterisk 12), sending information to a connected ARI client for a large number of channels would periodically cause a disconnect. Once disconnected, the client could not re-connect.
> 
> With the patch, the disconnects stopped. By setting the write timeout to a very low value, the disconnects occurred again, and the client was seen to reconnect (as the previous socket was completely closed).
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140624/69b7c842/attachment.html>