----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3402/#review11401 -----------------------------------------------------------
My only problem with this patch is that I really want to know for sure that there is something low level and buggy happening that requires such a change before approving it. So I have a few questions: 1) I notice you're using both fflush() and shutdown(). If you remove the fflush() does the bug still occur? What about if you add the fflush() but keep the close() in instead of using shutdown()? The reason I ask is that shutdown() and close() are both supposed to send a TCP FIN and flush out the write buffer on its own, so in theory the fflush() call should not be necessary. However, if removing fflush() causes the bug to return, then that leads to my next question: 2) Did this bug manifest itself on many HTTP client implementations or was it only seen on one? When calling close() or shutdown(), if there is data in the socket's write buffer, this data may be sent in the TCP FIN that Asterisk sends. It may be that whatever HTTP client is being used ignores data in TCP FIN and that may be where the real bug lies. It would be interesting to use TCPdump or some tool to monitor the HTTP traffic to see if there is any correlation between the way the HTTP traffic is sent and when the bug manifests itself. Overall, I'm just not comfortable saying that this fixes a race condition in the kernel since I don't know what due diligence has been done to prove that. On the other hand, I also can't really fault the changes here if they're actually helping improve the situation for an HTTP client. I guess what I'm saying is that the comments and the reasons for the code changes are bothering me more than the actual code changes themselves :) - Mark Michelson On March 27, 2014, 6:52 p.m., Scott Griepentrog wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3402/ > ----------------------------------------------------------- > > (Updated March 27, 2014, 6:52 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23548 > https://issues.asterisk.org/jira/browse/ASTERISK-23548 > > > Repository: Asterisk > > > Description > ------- > > When running asterisk in a virtual machine, responses to ARI requests would > frequently be missing. A race condition related to closing the socket > immediately after writing data onto it is resolved in this patch by insuring > the output stream is flushed, and then informing TCP of the shutdown prior to > the close. > > > Diffs > ----- > > /branches/12/main/tcptls.c 411242 > /branches/12/main/manager.c 411242 > /branches/12/main/http.c 411242 > > Diff: https://reviewboard.asterisk.org/r/3402/diff/ > > > Testing > ------- > > Tested on Ubuntu server 12.04 with Sam's json api test from issue. > > > Thanks, > > Scott Griepentrog > >
-- _____________________________________________________________________ -- 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
