Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313635 - Java TCF implementation uses miliseconds, C agent uses seconds for time sent across
Summary: Java TCF implementation uses miliseconds, C agent uses seconds for time sent ...
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 0.4.0   Edit
Assignee: Doug Gaff CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-19 18:21 EDT by Daniel Friederich CLA
Modified: 2013-06-05 07:56 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Friederich CLA 2010-05-19 18:21:46 EDT
Build Identifier: HEAD

For the TCF UDP discovery message which informs about slaves (UDP Discovery peers on a non 1534 port), the C reference implementation and the java reference implementation are using a different time base.
The java implementation uses miliseconds since 1.Jan 1970, the C implementation uses seconds. Therefore when the java implementation tell the C agent about a UDP peer, the C agent will never (well not in the next 40000 years) forget about it.

both the java and the C reference implementation support to notify about agents



Reproducible: Always

Steps to Reproduce:
TODO: I guess not too hard.
I had another machine on the local network running eclipse/tcf and I did locally run the C agent with trace output. Then when starting slaves, this produced the trace (from the C agent) below,
it shows that the C agent initially started to report the 64569/64570 slaves with seconds, then gets the time in miliseconds from the tcf java implementation and then
starts to propagate that time.


TCF 02:42.531: ACK_INFO to 127.255.255.255:1534, ID=TCP:10.82.136.36:1534
TCF 02:42.532: ACK_INFO to 127.255.255.255:1534, ID=TCP:127.0.0.1:1534
TCF 02:42.532: REQ_SLAVES from 10.82.138.15:1534
TCF 02:42.533: ACK_SLAVES (1274306530:64569:10.82.136.36) to 10.82.138.15:1534
TCF 02:42.533: ACK_SLAVES (1274306530:64570:10.82.136.36) to 10.82.138.15:1534
TCF 02:42.534: REQ_SLAVES to 10.82.138.15:1534
TCF 02:42.535: ACK_SLAVES (1274306563599:64569:10.82.136.36) from 10.82.136.36:1534
TCF 02:42.536: ACK_SLAVES (1274306563660:64570:10.82.136.36) from 10.82.136.36:1534
... Later ...
TCF 14:44.966: ACK_SLAVES (1274306563599:64569:10.82.136.36) to 10.82.138.15:1534
TCF 14:44.967: ACK_SLAVES (1274306563660:64570:10.82.136.36) to 10.82.138.15:1534

I wonder what the right way to fix this issue is (in a compatible way), I would think that using an absolute time seems a bit dangerous regardless of this offset of 1000,
I would think that using for example remaining seconds this agent should be kept (or mili seconds :-), would make more sense in case the two agents would use a different clock.
Comment 1 Daniel Friederich CLA 2010-05-19 18:25:42 EDT
The main effect of this bug is that the C agent does not forget about stale slaves.
Comment 2 Eugene Tarassov CLA 2010-06-24 20:18:50 EDT
The bug was fixed in revision 989 6/2/2010.
Now both Java and C code use milliseconds.
Comment 3 Doug Schaefer CLA 2011-05-17 10:48:57 EDT
Moving bugs to new home for IP log.
Comment 4 Martin Oberhuber CLA 2013-06-05 06:26:16 EDT
Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3