Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • Nov 14 23:12
    Aaronontheweb commented #4038
  • Nov 14 23:11
    Aaronontheweb synchronize #4038
  • Nov 14 23:08
    Aaronontheweb opened #4038
  • Nov 14 22:55

    Aaronontheweb on 1.3.16


  • Nov 14 22:54

    Aaronontheweb on master

    close #3935 - Akka.Persistence.… fix: data provided to AndThen (… Akka.Persistence.Query: made Of… and 13 more (compare)

  • Nov 14 22:53
    Aaronontheweb closed #4037
  • Nov 14 21:39
    Aaronontheweb synchronize #4037
  • Nov 14 21:39
    Aaronontheweb ready_for_review #4037
  • Nov 14 19:57
    Aaronontheweb synchronize #4037
  • Nov 14 19:53
    Aaronontheweb commented #4037
  • Nov 14 19:51
    Aaronontheweb opened #4037
  • Nov 14 19:08
    Aaronontheweb synchronize #4036
  • Nov 14 19:02
    Aaronontheweb opened #4036
  • Nov 14 16:48
    IgorFedchenko synchronize #4022
  • Nov 14 16:25
    Aaronontheweb commented #4035
  • Nov 14 16:24
    Aaronontheweb commented #4022
  • Nov 14 16:23
    Aaronontheweb labeled #4035
  • Nov 14 16:23
    Aaronontheweb labeled #4035
  • Nov 14 16:23
    Aaronontheweb opened #4035
  • Nov 14 16:21
    Aaronontheweb commented #4022
Maciek Misztal
@Horusiath is it plugin based? can it be extended if needed?
Aaron Stannard
@mmisztal1980 you know, that's a good question
DotNetty itself is very extensible
with Azure KeyVault, is it possible to pull the key out and put it somewhere where the file system can reach it?
haven't worked with it at all myself
that's what the TLS settings take
Aaron Stannard
ah dear god
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
congrats on the latest release! Will switch over.
Ismael Hamed
Unable to find a version of 'Akka.Streams' that is compatible with 'Akka.Persistence.Query constraint: Akka.Streams (>='.
Alex Valuyskiy
@ismaelhamed it is a bug. Will fix it soon
Arsene T. Gandote
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
No, Akka IO does not use DotNetty
Arsene T. Gandote
@alexvaluyskiy Any reasons why?
Arsene T. Gandote
Hello I need some quick education here. What is the difference between persisting data to db and Akka Persistence?
@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
@mwardm Thank you
Bartosz Sypytkowski
@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
what is the suggested way to setup custom supervision strategy for sharded actors?
Bartosz Sypytkowski
@gamemachine sharded actors have arbitrary managed lifecycle, I don't see how supervision strategy would apply here
Chris Ochs
hmm so it appears sharded actors are meant to be long lived only really.
Bartosz Sypytkowski
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
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
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
@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)
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
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