quickfast
quickfast copied to clipboard
objectcomputing
TCPReceiver::start blocks execution when other party is not available
TCPReceiver inherits start method from Receiver class.
Receiver::start() description says that it should return immediately.
The code of this method calls virtual initializeReceiver() provided by the
derived class.
TCPReceiver::initializeReceiver() method never proceeds beyond
socket_.connect(*iterator, error) call it makes.
As it stays now, the "Returns immediately" Receiver::start() description is
misleading because blocking is possible.
As a minimum it should be changed.
But it would be better to keep this description and
1. have a timeout for connection's efforts
2. return false if connection exited on timeout and was unsuccessful.
I am using library downloaded on 2010-09-14 with the last record at the change
log dated Mon Aug 23 14:40:01 UTC 2010.
But code in question is the same at least as of March, 2011.
Original issue reported on code.google.com by [email protected] on 27 Apr 2011 at 7:17
An interesting problem.
It won't actually hang forever. The TCP connection timeout seems to be on the
order of 5 minutes. It's not settable directly. As long as the TCPReceiver is
using a synchronous connect, that's how things are going to work.
It would be possible to change to an asynchronous connection and run a timer to
detect when it's been "too-long." When the timer triggers it would cancel the
connect request and call reportCommunicationError on the Assembler.
This would satisfy the "returns immediately" description with the downside you
wouldn't know whether or not the connection was successful. Instead a
connection timeout would show up as a reportCommunicationError callback to the
Assembler at some later time.
Would this work for you?
Original comment by [email protected] on 10 May 2011 at 4:19
- Changed state: Accepted
I like the proposed solution. It would keep description accurate and keep
user's options open on how to treat the failure coming via callback. It could
be a secondary optional channel of lesser importance after all.
Also, 5 minutes to realize that connection had failed is too long for the
industry even during application startup (this is when connections will likely
occur).
If you would set a default limit, make it shorter - 30 seconds or 1 minute.
Original comment by [email protected] on 6 Jun 2011 at 4:12