#opendaylight-meeting: kernel projects
Meeting started by rgoulding at 15:57:12 UTC
(full logs).
Meeting summary
- agenda bashing (rgoulding, 15:57:17)
- Carbon blocker: BUG-9028 (rgoulding,
15:57:32)
- Execution Origins (rgoulding,
15:57:39)
- Discussion: Should each thing create its own
ExecutorService or should we have a single central shared one? Like
an EE servers's manged thread pools. (rgoulding,
15:57:53)
- Checkstyle more rulez (rgoulding,
15:57:59)
- Exceptions lost in log from background threads:
How to hunt down ALL usages of thread factories, and make ALL of
them use the setUncaughtExceptionHandler() ? Just grep all (kernel
project) code? Any volunteers? Or is there any way we could enforce
it? (rgoulding,
15:58:14)
- Make sure that nobody just ignores returned
Future (or CompletionStage, and others..) - how? FindBugs, and/or
errorprone, and @CheckReturnValue ? How can we get started to become
more serious about this, everywhere? (rgoulding,
15:58:25)
- errorprone!
https://git.opendaylight.org/gerrit/#/c/62090/ (rgoulding,
15:58:35)
- JavaDoc sites, next step? Merge
https://git.opendaylight.org/gerrit/#/c/60213/ (rgoulding,
15:58:43)
- Thoughts / objections re.
https://git.opendaylight.org/gerrit/#/c/50905/ ? (rgoulding,
15:58:55)
- merged/pending patches (rgoulding,
15:59:10)
- Execution Origins (rgoulding, 16:04:27)
- Introduction and explain the idea, please see
https://git.opendaylight.org/gerrit/#/q/topic:mdc before if you have
the time (rgoulding,
16:04:46)
- agree together on next step re. actually using
this new infra (rgoulding,
16:04:53)
- need a new Servlet Filter with it, and then OK
to have restconf use that (and dep. on infrautils), see
https://lists.opendaylight.org/pipermail/netconf-dev/2017-July/001343.html
? (rgoulding,
16:05:01)
- (re)intro
https://git.opendaylight.org/gerrit/#/c/60828/ into odlparent
(reverted in https://git.opendaylight.org/gerrit/#/c/60857/)
(rgoulding,
16:05:08)
- quid
https://git.opendaylight.org/gerrit/#/c/61499/ re. log4j instead of
slf4j-simple for test - any better ideas, anyone? (rgoulding,
16:05:15)
- https://git.opendaylight.org/gerrit/#/q/topic:mdc
(rgoulding,
16:05:43)
- could be helpful to correlate log events
(rgoulding,
16:05:52)
- could be useful to know that log messages are
coming from common events (rgoulding,
16:06:09)
- pass an identifier down through the
corresponding calls, so that you can correlate as you propagate down
further into code (rgoulding,
16:06:55)
- mdc provides helpers for slf4j that allows you
to set the “execution origin” id (rgoulding,
16:07:21)
- rovarga asks how this propagates into slf4j and
how does it propagate across threads (rgoulding,
16:09:16)
- vorburger says mdc has an mdc API that allows
insertion of this metadata (rgoulding,
16:09:34)
- MDC == Mapped Diagnostic Context (rovarga,
16:09:55)
- “execution origin” is a cross-event correlator,
and is just a linear counter (rgoulding,
16:10:57)
- you don’t put any contextual string or anything
in it (rgoulding,
16:11:15)
- if you would like to correlate this with other
system(s) (i.e., openstack), have them send you the ID and stick
taht into the log (rgoulding,
16:11:53)
- rovarga you cannot just stick it in there, you
need to assign it to an origin and wrap it (rgoulding,
16:12:10)
- how do you ensure that the generated identifier
is unique? (rgoulding,
16:12:23)
- the suggestion, as currently proposed, is to
have an internal opendaylight id, and not mix this up with
correlating with outside systems (i.e., several openstack nodes
etc.) (rgoulding,
16:13:04)
- propagation of ids cross-thread (rgoulding,
16:13:39)
- we don’t have control over where Thread(s) are
created (rgoulding,
16:14:10)
- we could use the wrapper called
CrossThreadContextHolder (rgoulding,
16:14:23)
- a small wrapper around slf4j api (rgoulding,
16:14:30)
- https://git.opendaylight.org/gerrit/#/c/61524/3/common/util/src/main/java/org/opendaylight/infrautils/utils/mdc/CrossThreadContextHolder.java
(rgoulding,
16:14:36)
- use set/get wherever you switch threads
(rgoulding,
16:14:48)
- this must be done manually (rgoulding,
16:15:03)
- rovarga people will forget to propagate the
context, which makes scaing difficult (rgoulding,
16:16:24)
- there is implicit state expressed in the
ThreadLocal (rgoulding,
16:16:31)
- this is not limited to a single JVM which can
make tracking this difficult (rgoulding,
16:17:20)
- any logs from a registered listener would have
the same execution origin id (rgoulding,
16:19:05)
- that is problematic through akka (rgoulding,
16:19:09)
- there is no straight path for a transaction
commit (rgoulding,
16:19:17)
- potential impllications on performance that are
far from trivial, especially wrt to lambdas (rgoulding,
16:21:23)
- tpantelis you may be able to propagate the ID
through the existing message id as a threadlocal (rgoulding,
16:22:00)
- i.e., attach it to the transaction ID
(rgoulding,
16:22:42)
- propagation through md-sal there are a ton of
problems that need to be solved (rgoulding,
16:24:47)
- tpantelis says maybe try just propagating for
RPC(s) first (rgoulding,
16:25:13)
- maybe there is a halfway point where you can
propagate through as much as you can without going through the
kernel etc. (rgoulding,
16:26:30)
- BUG-9028 (rgoulding, 16:38:55)
- rovarga what are the avenues in which we can
fix this (rgoulding,
16:39:26)
- this is happening in the operational data store
in 3-node cluster (with followers) (rgoulding,
16:42:17)
- https://git.opendaylight.org/gerrit/#/c/62096/1
(rovarga,
17:01:04)
Meeting ended at 17:03:27 UTC
(full logs).
Action items
- (none)
People present (lines said)
- rgoulding (56)
- odl_meetbot (4)
- rovarga (2)
Generated by MeetBot 0.1.4.