You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "nadir amra (JIRA)" <ax...@ws.apache.org> on 2005/10/12 03:15:09 UTC

[jira] Commented: (AXISCPP-745) Use non-blocking receive in transport

    [ 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