Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 06 17:40
    gvolpe opened #289
  • Dec 06 17:40
    gvolpe labeled #289
  • Dec 06 17:40
    gvolpe labeled #289
  • Dec 06 17:39

    mergify[bot] on master

    Update scalafmt-core to 2.3.1 Merge branch 'master' into upda… Merge pull request #288 from sc… (compare)

  • Dec 06 17:39
    mergify[bot] closed #288
  • Dec 06 17:34
    gvolpe synchronize #288
  • Dec 06 02:39

    mergify[bot] on master

    Update sbt-microsites to 1.0.2 Merge pull request #287 from sc… (compare)

  • Dec 06 02:39
    mergify[bot] closed #287
  • Dec 06 02:36
    scala-steward opened #288
  • Dec 06 02:35
    scala-steward opened #287
  • Dec 05 19:26

    gvolpe on master

    Adding support for timestamp pr… Exposing timestamp as java.time… Fixing broken test and 1 more (compare)

  • Dec 05 19:26
    gvolpe closed #285
  • Dec 05 15:41
    drobert synchronize #285
  • Dec 05 15:02
    gvolpe commented #285
  • Dec 05 15:01
    drobert synchronize #285
  • Dec 05 14:52
    Daenyth commented #285
  • Dec 05 14:46
    drobert synchronize #285
  • Dec 05 10:45

    mergify[bot] on master

    Update sbt-microsites to 1.0.1 Merge pull request #286 from sc… (compare)

  • Dec 05 10:45
    mergify[bot] closed #286
  • Dec 05 10:41
    scala-steward opened #286
Alessandro Zanin
@azanin

Hi @gvolpe, thanks!

Just to open another topic we were wondering if the implicit channel can be injected in Fs2Rabbit constructor instead of methods.

 implicit channel =>
    for {
      _                 <- fs2Rabbit.declareQueue(DeclarationQueueConfig.default(queueName))
      _                 <- fs2Rabbit.declareExchange(DeclarationExchangeConfig.default(exchangeName, Topic))
      _                 <- fs2Rabbit.bindQueue(queueName, exchangeName, routingKey)
      (acker, consumer) <- fs2Rabbit.createAckerConsumer[String](queueName)
      publisher <- fs2Rabbit.createPublisherWithListener[AmqpMessage[String]](
                    exchangeName,
                    routingKey,
                    publishingFlag,
                    publishingListener
                  )
      _ <- new Flow[F, String](consumer, acker, logPipe, publisher).flow.compile.drain
    } yield ()
This means that Fs2Rabbit and a specific channel are coupled and all the operation in fs2Rabbit works for that channel
What do you think? (I’m asking this because I don’t really like the implicit approach in that case)
Gavin Bisesi
@Daenyth
It's not appropriate for the lifecycle model
one connection may have multiple channels (and likely will, for example if you both consume and publish they should be on different ones)
It might simplify the model to make it a regular param - it would remove some of the duplication of methods in the interfaces vs the Fs2Rabbit class
Especially since you can legitimately have multiple channels, implicit maybe isn't the best even though it does reduce a bunch of code
Alessandro Zanin
@azanin
@Daenyth thanks for the clarification :) I’ll try to think about a solution to remove the implicit and reducing the boilerplate as well.
Gavin Bisesi
@Daenyth
Possibly the interface methods that require a channel as an input value should instead be methods on a Channel[F] class (composing various interfaces)
your one-channel-per-client could be "just" an implementation of those interfaces that uses one channel, instead of being the channel itself
Alessandro Zanin
@azanin
Yep in this way we could have a small client (that implements specific algebras) that delegates to a channel (compose basically all the algebra interfaces) the operation required to be implemented.
And still we could “compose” more clients to build bigger programs. Each client is bound to a specific channel but obviously you can have clients instances with different/same channel instances. Does it make sense?
Gavin Bisesi
@Daenyth
I think so but I don't have the brain cycles to examine closely right now
it passes the sniff test at least for me
Alessandro Zanin
@azanin
I’ll give it a try. thanks @Daenyth
Gabriel Volpe
@gvolpe
@azanin that would be nice but as Gavin mentions you normally use different channels per connection, at least one for consuming and one for publishing. It'd be good to think about how that can be improved though :)
Alessandro Zanin
@azanin
@gvolpe yep. we discussed about that and what I meant was exactly what @Daenyth explained way better than me :)
Gabriel Volpe
@gvolpe
oh cool! :D
Gabriel Volpe
@gvolpe
Thinking about making a 2.1.0 release once #255 is merged. Are people okay with it? The only breaking change to the user seems to be the renaming of Fs2Rabbit for RabbitClient.
sourya7
@sourya7
Hi, I'm just playing around with fs2-rabbit and looks like some of the examples won't run with the current release (2.0.0) because they reference RabbitClient. Is there any plans on doing the release for 2.1.0 that was mentioned ^. I could build something locally but an official release would be great.
Gabriel Volpe
@gvolpe
Hi @sourya7 , yeah, I'm running behind on OSS but I should be publishing a 2.1.0 very soon.
sourya7
@sourya7
Oh, ok. Thank you!
Gavin Bisesi
@Daenyth
hmm
@gvolpe Would you be opposed to temporarily incorporating the old types back in (if it can be implemented) with @deprecated to ease the upgrade
I should have laid that out when we started working on the refactor :)
Gabriel Volpe
@gvolpe
Definitely not opposed to it @Daenyth . I just don't have the time nor the energy to do it now but I'd definitely take a PR :)
Gavin Bisesi
@Daenyth
k I'll keep it in mind
Gabriel Volpe
@gvolpe
@/all sorry for the delay, a new release 2.1.0 is on its way to Maven Central: https://github.com/profunktor/fs2-rabbit/releases/tag/2.1.0
Gavin Bisesi
@Daenyth
:+1:
will be nice once I can get onto 2.0 :laughing:
fwiw going forward, unless we get a design boost from it, I'd like to stagger releases from breaking cats/fs2 updates
Alessandro Zoffoli
@AL333Z_twitter
🎉
Gavin Bisesi
@Daenyth
As in, keep the same source compat as much as possible when upgrading cats-effect/fs2, and then break our api after we release on the new base
Gabriel Volpe
@gvolpe
Sounds good :+1:
Gavin Bisesi
@Daenyth
If I was to hypothetically backport the new API onto fs2 1.x and release that... what version would that be? It's both newer than 2.0.0-RC2 but also "older" than 2.0.0 and also not source-compatible with 2.0.0
Maybe this should just be something I hook up a local artifactory for, or vendor it one way or another
Gabriel Volpe
@gvolpe
Yeah, I believe a local published version should be best until you can get onto the latest versions
Victor Viale
@Koroeskohr
hi! I have a question regarding channels, should I basically be using one per consumer/producer? I struggle finding resources on the topic
One per consumer / publisher is in general a good way to get started
Though, you'd need some monitoring to see what's best for your application.
@Koroeskohr
Gavin Bisesi
@Daenyth
At minimum, don't mix producer+consumer on one channel
use a channel for each
Victor Viale
@Koroeskohr
Thanks for the insight. I currently have around 15 queues, a producer and a consumer each (using RMQ as a failure handling mechanism), having 30 channels is not an issue then?
Gabriel Volpe
@gvolpe
Monitoring is the answer
Gavin Bisesi
@Daenyth
@Koroeskohr FWIW in production we use 1 producer + 1 consumer per process. Channels are a limited resource on the rabbit server side, so if you horizontally scale at 30 per process, you could find yourself in a bad spot
Daniel Robert
@drobert
I may be missing this, but I'm not seeing support for amqp property timestamp (looking at the case class AmqpProperties it seems absent). Is this intended or just an oversight? I can probably PR its addition if it's just oversight.
Gabriel Volpe
@gvolpe
Just an oversight @drobert , PRs welcome :)
Daniel Robert
@drobert
:+1:
Daniel Robert
@drobert