I would not use non-blocking unless client requested it (i.e. if we do not have an API then we should provide one that does non-blocking with a user-specified time-out). The timeout is then use on the select() or poll() to wait a specified amount of time for something to happen on socket. I thought we have the capability in the transport, but maybe I am mistaken.
We should turn on keepalive in the socket to ensure that if the server goes down the client is woken up.
| "Adrian Dick (JIRA)"
<[email protected]>
07/15/2005 05:00 AM
|
|
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
