Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 17:41

    mergify[bot] on master

    Update scalafmt-core to 3.0.7 Merge pull request #633 from sc… (compare)

  • Oct 20 17:41
    mergify[bot] closed #633
  • Oct 20 17:35
    scala-steward opened #633
  • Oct 20 15:07

    mergify[bot] on master

    Update mdoc, sbt-mdoc to 2.2.24 Merge pull request #632 from sc… (compare)

  • Oct 20 15:07
    mergify[bot] closed #632
  • Oct 20 15:01
    scala-steward opened #632
  • Oct 18 17:41

    mergify[bot] on master

    Update scala-library to 2.12.15 Merge branch 'master' into upda… Update scala-library to 2.12.15 and 1 more (compare)

  • Oct 18 17:41
    mergify[bot] closed #615
  • Oct 18 17:36
    scala-steward synchronize #615
  • Oct 18 12:58

    mergify[bot] on master

    Update scala3-library to 3.1.0 Merge pull request #631 from sc… (compare)

  • Oct 18 12:58
    mergify[bot] closed #631
  • Oct 18 12:53
    scala-steward opened #631
  • Oct 18 00:48

    mergify[bot] on master

    Update fs2-core to 3.1.6 Merge pull request #630 from sc… (compare)

  • Oct 18 00:48
    mergify[bot] closed #630
  • Oct 18 00:41
    scala-steward opened #630
  • Oct 14 14:58

    mergify[bot] on master

    Update sbt-ci-release to 1.5.10 Merge pull request #629 from sc… (compare)

  • Oct 14 14:58
    mergify[bot] closed #629
  • Oct 14 14:52
    scala-steward opened #629
  • Oct 08 05:13

    mergify[bot] on master

    Update fs2-core to 3.1.5 Merge pull request #628 from sc… (compare)

  • Oct 08 05:13
    mergify[bot] closed #628
Gavin Bisesi
@Daenyth

@gvolpe It's a good idea! One thing that would help remove your need to spend time is to get the release process a bit more automated (or documented).

Right now I'm not sure how to go about it. Also we'll want to make a new major version release with the PR I just merged ;)

Gabriel Volpe
@gvolpe

@Daenyth cutting a new release couldn't be simpler:

Monitor the automatic release job once done. It works 99.9% of the time but when it doesn't we need to login in Sonatype and drop the release manually. Then retry the GH action for the release.

Gavin Bisesi
@Daenyth
oh nice :)
Gavin Bisesi
@Daenyth
looking at past history, it looks like we're going with a "break bincompat in minor releases"
so I'll make 2.3.0 for the next
I think we can set up release drafter to categorize those with tags on prs or something
hmm but previous releases we've done have preserved bincompat in minor releases, rather than updating compatible changes as patch versions
@gvolpe I think I'd like to set a policy going forward of doing bincompat breaks with major versions, and changes that preserve compat being minor or patch. Thoughts?
Gabriel Volpe
@gvolpe
Yeah that should be ideal, go for it :+1:
Gavin Bisesi
@Daenyth
kk
actually before I do that
nvm
I was thinking of using the @data case class replacement library for helping with binary compat but I don't really want to add the dep
will tackle that part later
Gavin Bisesi
@Daenyth

Where does the release thing happen?

I did the release on github and I don't see a new build in here: https://github.com/profunktor/fs2-rabbit/actions

Gabriel Volpe
@gvolpe
Let me see..
Hmm that's odd. The new tag should have triggered a release job like this one: https://github.com/profunktor/fs2-rabbit/actions/runs/257305157
Gabriel Volpe
@gvolpe
I think it might be related to permissions (re: Github Actions being the author of the tag)
Gavin Bisesi
@Daenyth
hm
Gabriel Volpe
@gvolpe
An action in a workflow run can’t trigger a new workflow run. For example, if an action pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
Gabriel Volpe
@gvolpe
Found this: release-drafter/release-drafter#550 but still don't know how to solve this
Gabriel Volpe
@gvolpe
I commented on the issue but for now, we could just make a v3.0.1
Gavin Bisesi
@Daenyth
ok
Gabriel Volpe
@gvolpe
Wanna do it to get familiar with the process? Should work this time! :smile:
Anyway, I hope we can fully automate the process. I have set up release drafter in another project but haven't done a release yet, pretty sure the same would happen.
Gavin Bisesi
@Daenyth
Would you mind? I'm pretty swamped right now
if it's just 'make a new release' (myself) then I'm already familiar - that's how I set up the work stuff
v3.0.1 is on its way to Maven Central: https://github.com/profunktor/fs2-rabbit/runs/1270696103
Artem Nikiforov
@nikiforo
Hi all,
Is there any library-like solution to cache connections, channels when publishing for fs2-rabbit?
Gabriel Volpe
@gvolpe
@nikiforo a connection is given as a cats.effect.Resource, there's no need to cache that. The connection will be valid in the use { ... } block.
Unless you have a different use case that I don't understand
Artem Nikiforov
@nikiforo

While googling, I encountered several recommendations, that it's better to share connections, because they are expensive to create.

For example this article mentions, that 13 Tcp packets are used to establish a connection+channel
https://www.cloudamqp.com/blog/2018-01-19-part4-rabbitmq-13-common-errors.html

Artem Nikiforov
@nikiforo
I've also found mentions, that Java Spring has some rabbit ConnectionFactory, but haven't explored that further.
Gabriel Volpe
@gvolpe
That's correct, and it's the same with any other messaging broker, database, etc
cats.effect.Resource gives you fine-grained control over your resource, in this case, the RabbitMQ connection
Share your connection within that use { ... } block, which delimits the resource lifetime
This concept is normally called "shared state". You can give this a read if you're not familiar with it: https://typelevel.org/blog/2018/06/07/shared-state-in-fp.html
There's also a talk by Fabio Labella which expands a bit more on the topic: http://systemfw.org/talks (the one at Scala Italy 2018)
Artem Nikiforov
@nikiforo

Indeed, within .use { ... } and Stream.resource this resource will be used, but if an error occures, I should reopen a connection and use the reopened connection in subsequent actions(just like ResilientStream in resilency package).

And I thought that logic of acquiring the connection should be encapsulated somewhere in ConnectionProvider.

Thanks! I'll watch the video and read the article thoroughly!

Gabriel Volpe
@gvolpe

if an error occures, I should reopen a connection

It's the users' responsibility to handle errors. If you don't want the connection to terminate on errors, have look at handleErrorWith, recoverWith, etc

You can find more about shared-state and other design patterns in this book as well: https://leanpub.com/pfp-scala (included in the first two chapters that can be downloaded for free)
Gavin Bisesi
@Daenyth
AFAIK the fs2-rabbit resource impl uses the built-in auto-recovering channel
so you shouldn't need to do anything
Artem Nikiforov
@nikiforo
Wow, it is documented, that some kind of recovery occures on network errors.
https://www.rabbitmq.com/api-guide.html#recovery
BTW, It seems that a ConnectionFactory is created every time createConnection is evoked
Artem Nikiforov
@nikiforo
I should definetely check that, but I think this isn't the way how createConnection should behave, or should it create ConnectionFactory every on every createConnection?
Gavin Bisesi
@Daenyth
Generally you only createConnection once or few times, though