----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3624/#review12319 -----------------------------------------------------------
Ship it! /branches/11/res/res_http_websocket.c <https://reviewboard.asterisk.org/r/3624/#comment22495> Same suggestion as the 12 version of this review - Mark Michelson On June 25, 2014, 6:39 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3624/ > ----------------------------------------------------------- > > (Updated June 25, 2014, 6:39 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 11 and only impacts chan_sip - a patch for Asterisk 12 will be on > https://reviewboard.asterisk.org/r/3659. > > 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/11/res/res_http_websocket.c 417210 > /branches/11/include/asterisk/http_websocket.h 417210 > /branches/11/configs/sip.conf.sample 417210 > /branches/11/channels/sip/include/sip.h 417210 > /branches/11/channels/chan_sip.c 417210 > /branches/11/UPGRADE.txt 417210 > > Diff: https://reviewboard.asterisk.org/r/3624/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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
