Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Adelbert Chang
    @adelbertc
    @timperrett seeing your recent tweets on infrastructure, ive been interested in learning more about infrastructure but haven't an idea where to start. i've got this Release It book but no clue how good/relevant it is - do you have any recommendations?
    Adelbert Chang
    @adelbertc
    (or general systems-y books)
    Steve Buzzard
    @sbuzzard
    was the reason for using apache commons object pooling for channels because netty only introduced channel pooling relatively recently (4.0.28 I think)? Also, any thought to exposing the config for this pooling? I think right now the generic object pool is created with the default config, so it has a max of 8 channels in the pool, unless I’m misinterpreting something - always a string possibility with me. :-). Generally this is fine but we get storms of activity where load testing is showing lags with remotely I believe waiting for a pool object.
    Mike (stew) O'Connor
    @stew
    at the time when I did the netty integration, if there was object pooling in netty I would have certainly used it
    Timothy Perrett
    @timperrett
    @sbuzzard ^^^^
    Mike (stew) O'Connor
    @stew
    in fact, IIRC i implemented my own object pool on the side to see how bad the performance would be compared to apache commons on my first try
    and the answer is 50% as performant
    Lars Hupel
    @larsrh
    Is there any interest in a PR/release of remotely for scalaz 7.2.x?
    I'm investigating using it, but pretty much all other libs I'm using depend on 7.2
    Timothy Perrett
    @timperrett
    @larsrh hey :) sorry for the delay, but yeah, if it can be cross-built that would be aweosme. I added the same thing to knobs as we still need 7.1
    i wont have time to update remotely right now though, but if you were motifivated to send a PR that would be awesome
    Lars Hupel
    @larsrh
    @timperrett Cool! It's just a two-line change and a fresh release :smile:
    Lars Hupel
    @larsrh
    @timperrett #116 – I took the liberty of bumping some more dependencies
    Lars Hupel
    @larsrh
    FYI, I created a 2.12 and scalaz 7.2.x fork here: https://github.com/larsrh/remotely and will release artifacts under my own id soon-ish
    If anybody wants me to upstream some of the commits there, please ping me, happy to do so
    Timothy Perrett
    @timperrett
    @larsrh thanks lars. Sorry i have been AWOL - got sucked into something else at work and haven’t had time to give this my attention :-(
    Lars Hupel
    @larsrh
    @timperrett no worries
    Lars Hupel
    @larsrh
    I tried following along the "Simple" example in the remotely sources
    I've defined a custom codec for a tree-ish type
    The first exchange works perfectly, but the second one throws an exception scodec
    wait, the third one
    This is the error I'm getting: result: -\/(java.lang.IllegalArgumentException: 6 bits remaining: 0x00)
    that seems to come from somewhere inside scodec
    Lars Hupel
    @larsrh
    err, scratch that, I was reading the log in the wrong way
    so the server is apparently able to encode the response, but the client can't decode it
    The codec itself is working fine: if I round-trip through .decode(x.encode(...)) it works
    Lars Hupel
    @larsrh
    After some debugging it appears that this is in fact an issue with the codec
    sorry for the noise
    Lars Hupel
    @larsrh
    I talked to @mpilquist and it's verizon/remotely#118.
    Timothy Perrett
    @timperrett
    @larsrh thanks for moving this along! we're in the middle of something major at work right now, so im not sure if we'll get to this
    Jean-Baptiste Giraudeau
    @jbgi
    @timperrett any clue if remotely as a future within Verizon? or should the community take over maintenance of (a fork of) the project?
    Lars Hupel
    @larsrh
    @jbgi, fwiw, I'm maintaining a 2.10/2.11/2.12 fork
    Jean-Baptiste Giraudeau
    @jbgi
    @larsrh thanks for the work, do you know if your fork have been use in production significantly?
    Lars Hupel
    @larsrh
    probably not
    But the only thing I changed is deleting benchmarks and porting to 2.12
    Jean-Baptiste Giraudeau
    @jbgi
    and bumping scalaz major version
    Lars Hupel
    @larsrh
    ah, right
    Timothy Perrett
    @timperrett
    @jbgi morning. thanks for the question about does remotely have a future internally for us. Well, few things here: firstly, remotely was a highly experimental prototype for us, and given other business needs we’ve not proliferated its usage internally as much as we might have liked - currently its exceedingly limited. This is largely because the ad-hoc testing story is missing (e.g. an analog to curl or some stuch) and debugging tools are also highly limited right now, and we dont have time to invest in those as remotely is not as strategic as some other goals. Secondly, and this has become more of a problem since we’ve grown and eaten other teams internally is that we no longer have a 100% scala code base. We have a largely Scala code-base, but not entirely (Some C++, some Node, some Go etc) - there’s no cross platform story with remotely, and creating one could be quite expensive. For me at least - and we’ve done no work on this yet, so its more of a brain fart - i’d like to see something like remotely as a scala API for something like gRPC which is already x-platform, as there have been many advances in routers and such for http2 and gRPC transport optiomisations (e.g. Envoy, Linkerd etc)
    So I would not anticipate that we’d end up using remotely in its current incarnation in a ubiqutious manner for the reasons i mentioned above - these are ultimately more social than technological; there’s nothing strictly wrong with remotely as-is.
    Thanks to @mpilquist and team for pushing things forward and using the system as intended - im stoked that people find it useful!
    Jean-Baptiste Giraudeau
    @jbgi
    @timperrett thanks for the extensive answer, I appreciate it. I also like grpc multi-plateform support (although I'd like it would have haskell support server-side).
    Timothy Perrett
    @timperrett
    @jbgi im curious, what use case are you looking to solve?
    Jean-Baptiste Giraudeau
    @jbgi
    pretty standard microservice architecture I guess. We are exclusively using scala right now, but I'd like to also use haskell in the future.
    currently we use akka-remote but this is pretty horrible for our rather basic rpc need.
    not to mention the scala lock-in
    Timothy Perrett
    @timperrett
    @jbgi oh yeah akka remote is almost certainly not what you want :D
    IMHO
    Paul Snively
    @PaulAtBanno
    @timperrett: So, the question behind the question: does Remotely have some specific support for chaining calls? The docs discuss Remote#response, but that doesn't seem to actually exist.
    Paul Snively
    @PaulAtBanno
    @timperrett: Trying to use Endpoint.failoverChain by constructing a stream of NettyTransports via iterating over InetSocketAddresses with NettyTransport.single. But when we runWithoutContext that Endpoint in a for-comprehension multiple times, it crashes. By comparison, if we put those InetSocketAddresses in a single NettyTransport and construct an Endpoint with that, it works (but we aren't sure what the semantics of having multiple InetSocketAddresses in a single NettyTransport actually are). Does this ring any bells?