[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] regarding tcp connection in ECF

Hi Abhisek,

abhisek saikia wrote:
Hi Scott
Today i had gone through the ecf generic code
It seems the code is handling the timeout (org.eclipse.ecf.provider.comm.tcp.Client ) it pings peers to keep the connection alive
if remote service execution exceeds 30 sec,i.e the time to get the response exceeds 30 sec ,ECF throws timeout error.The underlying tcp connection is still there.
If by any chance the network link gets broken,jmdns will anyway notify to remove the service and the consumer will remove the service to avoid service call failure.Once again when the network comes up consumer will be notified for the Remote Service again and consumer can successfully make use of this to perform the remote call and get the response.
So basically the container if gets disconnected(i could see only network down as one scenario for this) ,will be reconnected again
So i feel the doubt i raised is wrong ,ECF is handling the tcp connection timeout by making use of tcp ping.Please correct me if i am wrong

Yes, like I mentioned before, the ECF generic does have a configurable keepAlive...and a disconnect (e.g. due to consumer ping failure or some other network failure) results in the service being unregistered from the consumer's OSGi service registry (because of the ECF generic failure detection...which is based upon the keepAlive).


But regarding this statement
>Once again when the network comes up consumer will be notified for the Remote Service again and consumer can successfully make use of this to perform
> the remote call and get the response


Depending upon the nature of the network failure, and the specifics of the discovery mechanism used (i.e. what happens when the 'network is restored'), this notification may or may not occur.

If more info/details are needed specifically about the ECF generic provider's failure detection, I suggest contacting me (or other ECF people) directly for support. Due to my own time constraints, I have limit how much time is spent providing direct support via this forum.

Thanks,

Scott