In fact, this is explicitly to work with `static final` TupleTags, and using a non-stable isn't feasible.
A static final TupleTag won't be serialized in the closure of an object that uses it - it will be instantiated independently in any other ClassLoader, such as on a remote JVM. If you use a constant TupleTag during pipeline construction, and again during runtime, they must have matching identifiers, or the system can't correlate the two objects. Use of something like UUID.random() would remove our ability to use any constant values. On Tue, Apr 10, 2018 at 9:40 AM Robert Bradshaw <rober...@google.com> wrote: > These values should be, inasmuch as possible, stable across VMs. How slow > is slow? Doesn't this happen only once per VM startup? > > On Tue, Apr 10, 2018 at 9:33 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Hi >> >> does org.apache.beam.sdk.values.TupleTag#genId need to get the >> stacktrace or can we use any id generator (like >> UUID.random().toString())? Using traces is quite slow under load and >> environments where the root stack is not just the "next" level so >> skipping it would be nice. >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >> >
