Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Renato Cavalcanti
    @renatocaval
    sounds a good plan @WellingR
    maybe you can open a PR for it already and we use it to discuss it further?
    Ruud Welling
    @WellingR
    Done
    Renato Cavalcanti
    @renatocaval
    hey @WellingR, finally did some updates on dnvriend/akka-persistence-jdbc#191
    add a warning when logical deletes are enabled and used
    not so convinced if best approach, let me know what you think
    tomorrow, I'm travelling to Amsterdam to speak at the Scala User group
    I will try to review dnvriend/akka-persistence-jdbc#191 on the train
    Ruud Welling
    @WellingR
    I took a quick look, but I need some more time to look at it later
    Ruud Welling
    @WellingR
    @renatocaval I have not heard from James for a while. Do you agree with merging dnvriend/akka-persistence-jdbc#180 to the 4.x.x branch? I can open separate issues for the open PR comments
    Dmitriy Zakomirnyi
    @dmi3zkm

    hi, team!
    There are a number of min/max connections related configs in reference.conf.

    # 5 * number of cores
      numThreads = 20

      # number of threads
      maxConnections = 20

      # number of threads
      minConnections = 20

    Do you know where that "magick" number 5 comes from ?

    Renato Cavalcanti
    @renatocaval
    @WellingR, sorry, somehow I missed your message here
    I think the PR will bring the branch to a broken state, no?
    Ruud Welling
    @WellingR
    @dmi3zkm I have no idea where this number comes from. I guess someone has used this as a starting point. A better recommendatioin can be found on https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing (keep in mind that the max number of connections and the number of threads must be equal)
    Ruud Welling
    @WellingR
    @dmi3zkm Okay, i found it. this magical * 5 originates from a previous default in slick-hikaricp, see https://github.com/slick/slick/blob/65a59491fdf238bb0af581fefd80447bfd2540f9/slick-hikaricp/src/main/scala/slick/jdbc/hikaricp/HikariCPJdbcDataSource.scala#L47-L48
    Nevermind, this is 5 x number of threads, so it's something different
    Ruud Welling
    @WellingR
    @renatocaval I do not think this will bring the 4.x.x branch to a broken state, however there are some merge conflicts (probably not hard to fix)
    What I can do is merged it to a separate branch
    And only merge it with 4.x.x when it it completely done
    Ruud Welling
    @WellingR
    @renatocaval a while ago we have merged dnvriend/akka-persistence-jdbc#193, however this introduced a breaking changed to the custom database api. Specifically in the SlickDatabaseProvider trait. I originally thought this was not a big problem because we had just released, this feature, but now quite a bit of time has passed. Should we spend some effort to keep this source compatible?
    Renato Cavalcanti
    @renatocaval
    Hi @WellingR, I need to check it in detail. I don't see where the breaking change was introduced.
    Renato Cavalcanti
    @renatocaval
    @WellingR, I check it. I don't think we should worry about it
    I think it's very unlikely that users are implementing their own SlickDatabaseProvider
    Renato Cavalcanti
    @renatocaval
    it’s true that the fact that we didn’t release just after 3.4.0 increases the chances of getting something broken, but that risk will always be around.
    Renato Cavalcanti
    @renatocaval
    @WellingR, I openned a PR for Akka-2.6.0-RC1 that bumps the version and uses the new Materializer.matFromSystem
    it would be nice to have a version for Akka 2.6
    Renato Cavalcanti
    @renatocaval
    would you be able to cut a release for us? I was thinking on 3.6.0-RC1
    3.5.x series we keep for Akka 2.5.x and 3.6.x for Akka 2.6.x
    I have those compatibilities matrix, but we need it as soon we get a major Akka release