Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
peterstorm
@peterstorm:matrix.org
[m]
Well, another way of asking, I guess, is if it's referentially transparent?
Moses Nakamura
@mosesn
@spockz good to know, thanks!
Alessandro Vermeulen
@spockz
@mosesn do you see a way for us to be able control which tracing info is a#deed in a failure?
peterstorm
@peterstorm:matrix.org
[m]
Can I somehow configure a finagle-thrift client to do streaming?
Moses Nakamura
@mosesn
@spockz hmm, I’m not sure.
@peterstorm:matrix.org not right now. there isn’t a streaming protocol for thrift, afaik.
you can stream thrift objects over HTTP/2 if you want. but Finagle any special support for it.
Alessandro Vermeulen
@spockz
@mosesn would you be willing to consider a MR to make the trace id type definable by the user?
Alessandro Vermeulen
@spockz
@mosesn or switch to using the OpenTracing/OpenCensus interface, that would be ideal for us
Moses Nakamura
@mosesn
possibly! I think we’re still a little nervous about adopting OT because it still feels like the early days. opentelemetry was announced less than two years ago, and we’re not as confident it will be a longterm standard as something like slf4j
I think a PR to change how the trace id is displayed would probably be accepted. making the type flexible would probably be pretty invasive though, so we’d want to discuss it before doing something like that
hllrsr
@hllrsr

Hi everyone!

I got a question about dependency versions and security issues. The latest release from finagle is using the zookeeper version "3.5.0-alpha" which uses a vulnerable version from io.netty/netty 3.x.
After reading some issues and PR's, I've saw this issue (twitter/finagle#665) mentioning some changes that make sure that finagle is not using netty on version 3.x anymore.
What I'm trying to figure out is if finagle is not using netty on version 3.x only on the finagle project or in a whole perspective (even 3rd party dependencies that use netty on an outdated version are having their netty dependency overriden).
If the issue that I've mentioned only takes effect on the finagle project, should it be considered a bump on the zookeeper version?

Thanks!

Alessandro Vermeulen
@spockz
@mosesn open telemetry is indeed new. But with adoption of spring and other jvm frameworks plus integration with opencensus and tracing it seems the most stable form. If at least the Tracer interface can be made compatible with open telemetry tracing it would be a benefit
Moses Nakamura
@mosesn
@spockz for sure! but my inclination would be to first build an OT adapter for c.t.f.tracing.Tracer instead of migrating Finagle to the OT API
@hllrsr netty 3 and netty 4 are published in different namespaces and under different package names, so it’s possible for a single program to depend on both netty 3 and netty 4. what’s the version you would want to bump ZK to?
Moses Nakamura
@mosesn

it looks like we should be able to bump to at least zk 3.5.5 safely, which I believe is on netty 4.x.

https://github.com/apache/zookeeper/blob/branch-3.5.5/build.xml#L40

hllrsr
@hllrsr
@mosesn I would sugest the nearest version from zk which is not using netty 3.x. In this case, you suggested zk 3.5.5 which should be fine
Is there a way I can help with this bump? i.e: open an issue or something like this
Moses Nakamura
@mosesn
yeah, can you make a PR against Finagle?
should just be bumping the version, I would be surprised if there was a breaking API change
hllrsr
@hllrsr
Sure, I will open the PR today.
Also, I'll try to run through changelogs on zookeeper to see if there is any breaking change
Moses Nakamura
@mosesn
thanks! and if you wouldn’t mind, if you could publish a local version of the updated Finagle and double check that it solves your problem, that would be great!
Alessandro Vermeulen
@spockz
@mosesn I tried building such an adapter I faced some challenges: controlling wgeee the spans were created. I think this is fixed now by the recreation of the span in the requeuefilter. Then there was the mismatch berwwwb the Tracer api letting the trace is be set externally which is not available in OT. And the third thing was cintrollling which attributes are placed on spans
hllrsr
@hllrsr
@mosesn In the process of compiling finagle with zk on version 3.5.5 I've got some type conversion errors. The latest version that didn't show any errors, only warnings was 3.5.4-beta.
How should I proceed in this case? Should I investigate why this errors are being caused or should I go with the 3.5.4-beta version?
Also, going through change logs they didn't mentioned any breaking change being introduced on 3.5.5.
hllrsr
@hllrsr
Those conversion errors were fixed on 3.5.6. I've manged to compile it on this version.
hllrsr
@hllrsr
I've published a local version and it solve my issue! I've also opened the PR on finagle. Thanks for the directions @mosesn :kudos:
Moses Nakamura
@mosesn
@hllrsr nice work! I commented on the PR
Moses Nakamura
@mosesn
hey folks, we did the January release today. enjoy 21.1.0!
TP Diffenbach
@tpdi
I have a question about Finagle Contexts and com.twitter.util.Local . Documentation suggests both are replacements for ThreadLocals across asynchronous Futures, but I'm not quite sure how to get there. Contexts cannot be updated, only let in order to change their values for execution of a function passed in to let. Locals can be updated, and the updated value is visible to child threads. But updates in child threads are not visible to siblings. That's strictly right in asynchronous programming I suppose, but I'm not sure how to emulate something like the synchronous process A updates ThreadLocal X to 1, process B reads 1 from ThreadLocal X.
In my case, I want parallel Futures in one request to share the same database transaction. If I stick the transaction in a LocalContext or a Context, and then create a bunch of async Futures, they all see the same transaction, which is great! But if transactions are started lazily by the first thread to need to, how can I ensure the other threads see that same transaction? And that different requests/contexts see only their own transaction? Thanks.
Christopher Coco
@cacoco

Does this help at all:

Finagle explicitly manages them for you across threads and execution contexts such as Future composition, FuturePools, Timers, and in some cases — across the client/server boundary.

(https://twitter.github.io/finagle/guide/Contexts.html)

let is a way of scoping a value in a closure
TP Diffenbach
@tpdi
I suppose I could add an extra level of indirection, allowing threads to write to mutable state in the context object, but I'm hoping for something cleaner
Christopher Coco
@cacoco
foo.let(something) { //everthing here sees the something value }
if you’re trying to coordinate state across a lot of futures...
TP Diffenbach
@tpdi
Right, I understand let. But I need updates within "//everthing here sees the something value" to be seen by all threads/Futures within that block
Christopher Coco
@cacoco
right we do this in places by mutating a value held in the context
(like how we propagate slf4j MDC values in Finatra)
TP Diffenbach
@tpdi
So I have in synchronous code some database access object that does a if (myThreadLocal.get() == null) myThreadLocal.set(new Transaction); and then subquestnt calls to it in that thread use the transaction
Ok, so you do use an extra level of indirection
the context is fixed, but the value it holds is mutable
Christopher Coco
@cacoco
exactly
TP Diffenbach
@tpdi
com.twitter.util.Local does almost what I want; in order to replace multiple ThreadLocals, I'll need to establish a key or index for each, com.twitter.util.Local does that, using a counter in the companion object that serves as the array index
I was hoping someone else had already had to do this ;)
Christopher Coco
@cacoco
hah, it is possible there’s something out there
TP Diffenbach
@tpdi
Out of curiosity, when do you use a Local rather than a LocalContext?
Christopher Coco
@cacoco
I think generally when we say local we mean a local context (at least I do)
TP Diffenbach
@tpdi
Sorry, I meant com.twitter.util.Local vs com.twitter.finagle.context.LocalContext.
But thanks so much for clarifying this for me
Alessandro Vermeulen
@spockz
So if you want to share a db transactionwithin the same calls to the database you set the context with .let(mydbkey, newAtomicRef)(... handler code that calls multiple dB calls). On access of the mydbkey you can make sure the transaction is created only once