[ http://issues.apache.org/jira/browse/AXISCPP-745?page=comments#action_12331855 ]
nadir amra commented on AXISCPP-745: ------------------------------------ Non-blocking should be tied to a timeout value that the client would set. Thus, if a timeout value was not set, then blocking I/O would be done; otherwise, non-blocking with the use of select()/poll(). > Use non-blocking receive in transport > ------------------------------------- > > Key: AXISCPP-745 > URL: http://issues.apache.org/jira/browse/AXISCPP-745 > Project: Axis-C++ > Type: Improvement > Components: Transport (Client), Transport (axis3) > Versions: current (nightly) > Reporter: Adrian Dick > > It would appear we current use blocking receive in the transport. Most of > the time this isn't a problem. > However, in the case where a server stops responding (as has been seen with > recent problems in the MockServer) the client becomes "stuck" waiting for > data that will never arrive. > I, therefore, propose we use the receive in non-blocking mode. > The linux man pages have the following to say about using recv: > "If no messages are available at the socket, the receive calls wait for > a message to arrive, unless the socket is nonblocking (see fcntl(2)) in > which case the value -1 is returned and the external variable errno set > to EAGAIN. The receive calls normally return any data available, up to > the requested amount, rather than waiting for receipt of the full > amount requested. > The select(2) or poll(2) call may be used to determine when more data > arrives." > Which suggests to me we could be a little more intelligent in how receive > data. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
