Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 12:50
    IgorFedchenko commented #4032
  • 06:50
    dependabot-preview[bot] labeled #4033
  • 06:50

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 06:50
    dependabot-preview[bot] opened #4033
  • Nov 12 22:40
    Horusiath commented #4022
  • Nov 12 22:03

    dependabot-preview[bot] on nuget

    (compare)

  • Nov 12 22:03

    dependabot-preview[bot] on dev

    Bump Microsoft.SourceLink.GitHu… (compare)

  • Nov 12 22:03
    dependabot-preview[bot] closed #4028
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4029
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump ApprovalTests from 3.0.10 … (compare)

  • Nov 12 20:30
    dependabot-preview[bot] edited #4029
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #3991
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4028
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #4021
  • Nov 12 20:30
    dependabot-preview[bot] edited #3991
  • Nov 12 20:30
    dependabot-preview[bot] synchronize #3989
  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Microsoft.SourceLink.GitHu… (compare)

  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump Mono.Cecil from 0.9.6.4 to… (compare)

  • Nov 12 20:30

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

Aaron Stannard
@Aaronontheweb
I don't know what the odds of this happening are, but found an easy edge case that could explain that earlier hashcode problem
From UniqueAddress
        /// <inheritdoc cref="object.GetHashCode"/>
        public override int GetHashCode()
        {
            return Uid;
        }
if that UID is the same for two nodes
that would totally cause a problem
the UID is supposed to be unique per-actor system
and should be able to change across restarts
I doubt that's it
since the UIDs have been in use for a long time
but I know there's an instance when a node is first joining where its UID is unknown initially
that could do it
ErrCode
@ErrCode
congrats on the latest release! Will switch over.
Ismael Hamed
@ismaelhamed
Unable to find a version of 'Akka.Streams' that is compatible with 'Akka.Persistence.Query 1.2.0.35-beta constraint: Akka.Streams (>= 1.2.0.35-beta)'.
Alex Valuyskiy
@alexvaluyskiy
@ismaelhamed it is a bug. Will fix it soon
Arsene T. Gandote
@Tochemey
Hello I can read that the new 1.2 has this beautiful feature and I quote
Akka.Remote now uses DotNetty for its transport layer
However I would like to know whether the Akka.IO has been rebuilt around the DotNetty lib?
The reason I ask that question is due this :
     * SocketChannel does not exists in the .NET BCL - This class is an adapter to hide the differences in CLR & JVM IO.
     * This implementation uses blocking IO calls, and then catch SocketExceptions if the socket is set to non blocking. 
     * This might introduce performance issues, with lots of thrown exceptions
     * TODO: Implements this class with .NET Async calls
     */
Alex Valuyskiy
@alexvaluyskiy
No, Akka IO does not use DotNetty
Arsene T. Gandote
@Tochemey
@alexvaluyskiy Any reasons why?
Arsene T. Gandote
@Tochemey
Hello I need some quick education here. What is the difference between persisting data to db and Akka Persistence?
mwardm
@mwardm
@Tochemey Akka.Persistence provides you with some framework support to allow actors to save messages (/ "events") into the database and have those messages automatically fed back to them when they (re)start, so that they can restore their state by replaying their messages. These messages are saved in a single table with actor-type, actor-id, message-order, message-data format (conceptually, anyway).
@Tochemey If you have an actual requirement for saving data into a database in a particular format (e.g. normal relational stuff), then you'd write your own code in your actors (or maybe some separate DB ones) to do that.
At least, that's how I'm thinking of it. (Not sure if anyone's using any ORM / EntityFramework / other style persistence mechanisms to save their own data. I dislike dropping all the way back to ADO.Net. Seems so primitive!)
Arsene T. Gandote
@Tochemey
@mwardm Thank you
Bartosz Sypytkowski
@Horusiath
@Tochemey Akka.IO is just an actor wrapper over native sockets and files, it exposes all of the socket events as messages. DotNetty is full-blown framework, that hides a lot of low-level details and brings it's own concurrency control (which akka.io handles through actors)
Chris Ochs
@gamemachine
what is the suggested way to setup custom supervision strategy for sharded actors?
Bartosz Sypytkowski
@Horusiath
@gamemachine sharded actors have arbitrary managed lifecycle, I don't see how supervision strategy would apply here
Chris Ochs
@gamemachine
hmm so it appears sharded actors are meant to be long lived only really.
Bartosz Sypytkowski
@Horusiath
you can use passivation mechanics to stop them, but passivation is not part of supervision chain and they will be recreated anyway if some message will arrive
Chris Ochs
@gamemachine
our use case is we want short term actors that have a globally unique id that we can reach from anywhere in a cluster.
we use a database to create and lookup the id's
so probably best to stick with the initial approach I had, which is just remote deploy
or actually probably simpler to have an actor that just creates them on demand, and it supervises them
Chris Ochs
@gamemachine
so cluster sharding docs say I need to specify an event journal. But node A can send a message to a sharded actor on node B (same computer) and I haven't configured any journal. What gives?
Bartosz Sypytkowski
@Horusiath
@gamemachine cluster sharding uses event journals to keep its internal state across the nodes. So i.e. if a node hosting so called shard coordinator dies, coordinator itself can be recreated on another node and it will still know which shards live on which nodes
(it's also useful to remember that cost of creating and communicating with sharded actors is higher than with standard ones)
Weston
@ronnyek
so persistence wise, is there anything like the persistent state like azure service fabric has
(I think it works the same way in orleans)
Arjen Smits
@Danthar
using snapshots is basically the same
persistence has 2 types of storage methods, journal and snapshot
journal is eventsource based
so you save each event that mutates your state, as it comes in
when your actor restarts, all events are replayed, thus rebuilding your actor state
snapshotting stores the current state of your actor. Well, not the the actor state, but whatever state you tell it to
so if you store a list of whatevers in your actor, you can store that in one go with a snapshot
when your actor restarts, it gets the last snapshot you saved
journalling is often used in conjunction with snapshotting, to improve performance.
Boban
@bobanco
@Aaronontheweb can you check if the overridden the GetHashCode() , Equals() is overridden too and you can provide == != operators too if somewhere == is used instead of Equals()
Aaron Stannard
@Aaronontheweb
@bobanco yeah resharper throws a warning about that
fixed it in my local branch
working on some more model based tests to get to the bottom of the issue