[KIEKER-772] NTP time source

rju commented 2 weeks ago

JIRA Issue: KIEKER-772 NTP time source Original Reporter: Andre van Hoorn

Has been developed by Christian Zobel in a Master's thesis at Mannheim University of Applied Sciences.

The time source periodically connects to a configured NTP server for (re-)synchronization. The implementation is based on the Apache Commons Net(tm) library's NTP/SNTP functionality.

Christian has to clarify whether he can contribute the sources.

rju commented 1 week ago

author Jan Waller -- Wed, 1 Feb 2012 10:55:29 +0100

On a first look, this would be very easy to implement on our own.
The inclusion of the required source files from Apache Commons directly into our source tree (to avoid new dependencies) should be no problem and the usage of the classes is simple enough.

rju commented 1 week ago

author 557058:cff1b6ca-d67f-4407-91f9-091bc876d232 unknown Jira user -- Wed, 1 Feb 2012 11:02:36 +0100

yeah, reinventing the wheel would of course be no problem, and that's what you typically want for open source projects. code contributions are not on the wishlist as they haven't been invented by the project members themselves... what about another distribution jars for all these addons? this would not introduce any dependencies to any libs and also could be a nice way to keep the modularity of the system.

rju commented 1 week ago

author Jan Waller -- Wed, 1 Feb 2012 11:07:37 +0100

You didn't understand what I meant

1. A NTP referencing time source would be a nice feature.
2. We are not sure if we can include the work of Christian Z. into our releases due to constraints out of our hands.
3. He uses the apache commons lib, which is fine and functional
4. The usage of this lib is easy
5. We want to avoid more runtime (strongly) or compile time (perhaps ok) dependencies
6. So instead of simply adding yet another jar into the distribution we could include the few needed classes
1. Not to hide any dependencies, but to make their usage easier

rju commented 1 week ago

author André van Hoorn -- Wed, 1 Feb 2012 11:11:39 +0100

My thoughts are similar to Robert's:

Concerning the Kieker NTP time source: {br}
Sure, we can basically implement everything on our own. But in my opinion, we should be happy for external contributions and solicit those.
Concerning the Apache Commons code: dependencies to external libs should be explicit and not result in a class-level "cherry-picking" to hide dependencies.

rju commented 1 week ago

author Jan Waller -- Wed, 1 Feb 2012 11:15:03 +0100

see above

rju commented 1 week ago

author 557058:cff1b6ca-d67f-4407-91f9-091bc876d232 unknown Jira user -- Wed, 1 Feb 2012 11:56:41 +0100

1. yes, would be, but depends on the implementation. querieing ntpservers for every record is somewhat useless... for long running systems, it would even be possible to use some very advanced timing features, like calculating clock drifts and set timestamps to be intervals, like done in highly distributed systems like sensor nets (10000+ nodes).
2. let's wait and see
3. yeah, so? what kind of argument is that? he didn't reeinvent the wheel but used a nice lib
4. whatever, even if it was hard, i don't see the point. if he can't contribute the code though, this would be a pro for using the lib ourselves, too.
5. thats why i proposed some add on jar. the jar i proposed is something that should have been added since ages in my opinion. my pov is that this jar would be something like "texlive-extra" or "texlive-recommended" if you compare these projects. dependencies won't get cyclic, instead there is a line drawn between absolutely basic implementations and features not commonly used but proposed to solve several tasks. if kieker should be used in other than business systems, there might be constraints on network usage or dependencies (mobile devices for instance), also for ntp, many systems update there clocks regularly via ntp, so they won't actually need this feature.
6. see 5 and think about some dependency management system like maven. i don't think the future of modular projects is to include (binary or source) code from other libraries and link it statically like it was done in c applications ages ago. instead using dynamic linking (i.e. classpath and replacable jars) would be the way to choose. let's just suspect, there is a bug in commons, which has to be fixed immedeatly. this means to repack a new distribution. having it as a dependenciy to a jar would just mean one mail on the mailing list and throwing in the new version of commons... of course, monolithic software is easier to use, but it's also monolithic

rju commented 1 week ago

author André van Hoorn -- Mon, 6 Aug 2012 16:01:10 +0200

Replying to KIEKER-772 Open :
> Christian has to clarify whether he can contribute the sources.

Unfortunately, he is not allowed to contribute them.

kieker-monitoring / kieker

[KIEKER-772] NTP time source #1466