{"push_id":2776688853,"size":3,"distinct_size":3,"ref":"refs/heads/bug5164","head":"661168b259aa22a741d323a9c5066c7c0b6ce662","before":"8509144e5da668e2a93e5fa7dd2e291e9aae2e4b","commits":[{"sha":"3aa3909e7cc9f55f5a4557ae1ca7be59fdc2f3f8","author":{"name":"Tim Wickberg","email":"5ee0edb9e2229c0838f1959779f1949031de0123@schedmd.com"},"message":"Retransmit on all errors.\n\nBug 5164.","distinct":true,"url":"https://api.github.com/repos/SchedMD/slurm/commits/3aa3909e7cc9f55f5a4557ae1ca7be59fdc2f3f8"},{"sha":"d288a8bb424bce727138a615e84dd9026795a95e","author":{"name":"Tim Wickberg","email":"5ee0edb9e2229c0838f1959779f1949031de0123@schedmd.com"},"message":"Modify slurm_send_only_node_msg() to catch issues with socket.\n\nThere are subtle issues involved in treating a TCP transmission\nas a unidirectional message delivery layer.\n\nThe original code path looks like: connect(), write(), close().\nBut Linux handles the write() and close() asynchronously behind the\nscenes, and does not block until that write() has been ACK'd by the\nremote end. So the write() and close() may succeed, even with data\nstill in flight. A communication error - and message loss - would\nhave been silently ignored, leading to unreliable message transmission.\n\nWorse yet, one side of the connection would believe it sent the message,\nwhile the receive side swears it never saw the packets. This leads to\ninfrequent and yet seemingly impossible data loss, and a very tough\nbug to chase down.\n\nThis teardown code tries to force the connection to shut down in an\norderly manner, giving Slurm a chance to catch a connection problem\nand the upstream calling path an opportunity to retransmit.\n\nThis teardown code is based on an approach described in Section 7.5\nof \"UNIX Network Programming\" Volume 1 (Third Edition), specifically\nthe subsection regarding SO_LINGER. (And also covers why SO_LINGER is\nnot sufficent to prevent this issue.)\n\nBug 5164.","distinct":true,"url":"https://api.github.com/repos/SchedMD/slurm/commits/d288a8bb424bce727138a615e84dd9026795a95e"},{"sha":"661168b259aa22a741d323a9c5066c7c0b6ce662","author":{"name":"Tim Wickberg","email":"5ee0edb9e2229c0838f1959779f1949031de0123@schedmd.com"},"message":"Change debug messages() in _launch_handler().\n\nAfter changes to slurm_send_only_node_msg(), this message is much\nmore likely to appear on systems with overloaded interconnects since\nthat connection handling code may end up retransmitting messages\nthat were actually received (but that the transmit side could not\nverify were delivered successfully).\n\nAs the error() message stated, this isn't actually an error, and\nthe code will proceed happily past this point. So drop the debug\nlevel, and remove the surrealist \"this is not an error\" part.\n\nBug 5164.","distinct":true,"url":"https://api.github.com/repos/SchedMD/slurm/commits/661168b259aa22a741d323a9c5066c7c0b6ce662"}]}
{"actor":{"display_login":"wickberg"}}