Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Alessandro Vermeulen
@spockz
@ryanoneill FYI, we switched back to the SslContextClientEngineFactory and tls connections are now established 10x faster overall when reconnecting to the same instance, and first shot is 2.25x faster than with the netty4clientenginefactory.
Alessandro Vermeulen
@spockz
I expected the connections with session reuse to be faster but I’m puzzled about why the first connection with the ssl context should be faster when it uses JSSE instead of boring ssl.
This is on GraalVM 1.8_252 btw
Andre Souza
@andrerocker
Hey folks, given a Http.client request, are there an easy way to send a haproxy-protocol to the target host? Tks in advance
Beck Gaël
@beckgael
Hi, i'm new to microservices, i've not establish yet which of Finagle, Finch, Finatra will fit the most my use case. And by reading some disadvantages of RPC technologies i fall on the fact that RPC has issues when dealing with large quantity of data. In my use case i will need to load large datasets from DB to process them. Are there really any restrictions about the size / load speed of that kind of files with RPC and more specifically with Finagle and frameworks on top of it ?
Thank you.
Alessandro Vermeulen
@spockz
@beckgael most RPC doesn’t support resumption or other niceties of say sftp but that depends more on the client and server business logic then RPC itself.
Hamdi Allam
@hamdiallam
Finagle supports streaming over HTTP which works well for large payloads
Roger
@rogern
Hello! Im using scrooge to build thrift structures and I've run into a complicated include problem. I got a common library including projects with thrift files where one of the projects act as a main module with shared types in a single thrift file. The whole library is then used in many services that also have their own thrift structures that requires the shared types from both the main module and the other projects of the common library. This makes it really hard to depend on include in the thrift files because the paths will be different depending on which context you are in. I can't get it to work both for builds in commons library as well as from jar in services. I can't find any docs about how you would organise a build like this? It has lead us to do a lot of workarounds with custom plugins etc. But what would a recommended way of setting this up be?
Roger
@rogern
I solved it with a combination of scroogeThriftSources and scroogeThriftIncludeFolders. Not sure if this is the best approach since it means a "copy" of the shared types file. But it works for us.
Vladimir Ivanovskiy
@vi-p4f
Hi! Are there any particular reasons why "fixedinet" schema is not implemented in Path resolution?
Namer.scala:84
def unapply(path: Path): Option[(Var[Addr], Path)] = path match {
        case Path.Utf8("$", "inet", host, IntegerString(port), residual @ _*) =>
          Some((resolve(host, port), Path.Utf8(residual: _*)))
        case Path.Utf8("$", "inet", IntegerString(port), residual @ _*) =>
          // no host provided means localhost
          Some((resolve("", port), Path.Utf8(residual: _*)))
        case _ => None
      }
11 replies
Moses Nakamura
@mosesn
@spockz we’re looking at changing how trace id gets printed, I remember you had some way you wanted to change it, right? can you remind me what how it was?
renyuliu
@renyuliu
hi, does anyone knows how to config the Redis client with tls-enabled ?
peterstorm
@peterstorm:matrix.org
[m]
Is the Twitter Future lazy or eager?
Alessandro Vermeulen
@spockz
@mosesn not necessarily the format but the contents. We use OpenTracing instead of the built in tracer and I want the ability to show our trace information in Failures
And somewhere in our infinite wisdom we choose 128bits for both span and trace if
Moses Nakamura
@mosesn
@peterstorm:matrix.org Futures don’t have work attached to them, so I wouldn’t call them either eager or lazy. NB calling Future.applyA to construct a future executes synchronously, a is call-by-name to catch thrown exceptions, not to trigger work on a different thread. You can think of a Future as being like a box–but the work that is done to fill that box is not attached to the box, except for interruptions, which are advisory
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 }