[
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
