Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:41
    Aaronontheweb commented #4097
  • 08:19
    ismaelhamed synchronize #4097
  • 02:22
    kimbyungeun opened #4098
  • Dec 15 19:47

    Aaronontheweb on dev

    TypeExtensions.TypeQualifiedNam… (compare)

  • Dec 15 19:47
    Aaronontheweb closed #4071
  • Dec 15 19:47
    Aaronontheweb closed #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb milestoned #3767
  • Dec 15 19:44
    Aaronontheweb labeled #4097
  • Dec 15 19:44
    Aaronontheweb milestoned #4097
  • Dec 15 13:23
    Aaronontheweb commented #4096
  • Dec 15 13:22
    Aaronontheweb commented #4093
  • Dec 15 13:16
    ismaelhamed commented #4093
  • Dec 15 13:04
    ismaelhamed edited #4097
  • Dec 15 13:04
    ismaelhamed opened #4097
  • Dec 15 12:50
    ismaelhamed commented #4096
  • Dec 15 12:48
    ismaelhamed commented #4096
  • Dec 15 12:05
    Aaronontheweb commented #4096
  • Dec 15 11:43
    ismaelhamed commented #4096
Vagif Abilov
@object
@Horusiath but since your first reaction was "why boxing them at all?" and you work much with F#, does this mean that you avoid this scenario? But how? Putting all cases in the same type?
Bartosz Sypytkowski
@Horusiath
I just don't box them explicitly - I rather use let! (message: obj) = mailbox.Receive ()
optionally in Akkling this shouldn't be necessary, as system messages have active patterns which tells exactly, that pattern match is expected to work on obj value
Vagif Abilov
@object
I see, but it's kind of the same.
Bartosz Sypytkowski
@Horusiath
unfortunately, I haven't found a way to fix that - .NET/F# type system is too limiting for me in this matter
Vagif Abilov
@object
What I experience is that as the system grows and needs to encounter more compex cases, more and more maiboxes lost their strong types.
And your Akkling project doesn't address this?
I know it addresses the problem of untyped messages, but that's different.
Bartosz Sypytkowski
@Horusiath
in akkling you can spawn actor with behavior working over obj message type, but then narrow type of the messages actor ref is able to tell using retype method
Vagif Abilov
@object
I see, thanks.
Vagif Abilov
@object
I have a persistent actor which I want to be able to reset. In F# I represent its state using option type. Storing "Some state" works fine, but when I assign None state and call "exec" function, it raises NullReferenceException from Akka.Persistence.Journal.WriteJournalBase.AdaptToJournal.
I know that None can be optimized to null and that it's not possible to use null/None as a message to actor. But it should be possible to use None as state, shouldn't it?
Roman Golenok
@shersh
Guys, if you interested in load testing, you can look this - https://tech.yandex.com/tank/?ncrnd=3620
Bartosz Sypytkowski
@Horusiath
@object In loot of F#-oriented DDD talks there is often mentioned something like state 'zero' which is initial state for target aggregate. It has more sense than using options, because empty state is usually needed once during the aggregate lifetime (at the beginning), so bearing the burden of marking each state as option (and checking it everywhere in business logic) may not be a justified case
if you're using record as a state, it may look like that:
type State = 
    { A: int; B: string}
    static member Zero = { A = 0; B = "" }
Vagif Abilov
@object
@Horusiath thanks, yes I am using records, and what you're suggesting makes perfect sense. In fact it will simplify the logic avoiding some matches.
Vagif Abilov
@object
Upgraded Akka to 1.0.7, testing it now in F# interactive, and I am getting almost immediately NullReferenceException with message "Default journal plugin is not configured". AFAIK this is new error message.
Bartosz Sypytkowski
@Horusiath
what journal plugin do you use/
Vagif Abilov
@object
I didn't overwrite it, so it's all default for test purposes. In-memory and local file system.
I.e. the config file doesn't specify any.
And my test persistent actor only takes snapshots, no history.
Bartosz Sypytkowski
@Horusiath
looks like new version of default config loaded by @cconstantin have cleared the default journal field :/ I'll set an issue for that
until then, you should specify akka.persistence.journal.plugin = "akka.persistence.journal.inmem"
also, don't use snapshot store alone, it's missing the point
Vagif Abilov
@object
@Horusiath thanks, I'll set the default journal plugin explicitly. What is it missing the point to use only snapshot store if some an actor only needs to persist its more recent state?
Bartosz Sypytkowski
@Horusiath
snapshot store has been build to optimize journal replay performance, nothing more. It works based on the assumption, that you're using journal anyway.
one of the problems may occur when you'll try to save snapshot and restart your actor right after that - since snapshots are not ACKed, and most of the db roundtrips take a lot longer that actor's restart, after restarting your actor, you have no guarantee that it won't receive an outdated snapshot from persistent store
Bartosz Sypytkowski
@Horusiath
we've already encountered following scenario:
  1. Actor A has state S2, while snapshot store has persisted its previous state S1
  2. A sends save snapshot message with state S2, and restarts immediately after
  3. After restarting A asks snapshots store for the latest snapshot version
  4. Since reads/writes are done asynchronously, snapshot store may retrieve state S1 instead of S2 (because S2 has not been durably stored yet)
  5. Actor A recovers with state S1
Vagif Abilov
@object
Oh I see, that's a great explanation. I knew that journal is a primary concern and snapshot is more for optimization, but I wasn' aware that use of snapshots assumes using journal, I thought that in certain trivial cases using snapshots alone might be justified. Thx for clearing it up.
Zetanova
@Zetanova
@object If you need only some sort of persistent cache value, like "LastPullDate", you dont need to use Persistence for this actor.
But it is nice if you create a DataPulled event and persist it in the journal.
Vagif Abilov
@object
@Zetanova I don't only need a value, I need to assign it to the actor as its current state, so choice of persistent actors was deliberate.
Kamil Wojciechowski
@aph5nt
"PersistentView is deprecated. Use PersistenceQuery when it will be ported." what was wrong with the views ? :D
views are nice, I can create eg. stats based on my actor events
I can partition the read side to n views, where each view is responsible for some part of data
will the PersistenceQuery offer me the same ?
Vagif Abilov
@object
"NewtonSoftJsonSerializer has been detected as a default serializer." (in 1.0.7) even though my config has:
serializers {
wire = "Akka.Serialization.WireSerializer, Akka.Serialization.Wire"
}
serialization-bindings {
"System.Object" = wire
}
JSON.NET is referenced in projects but I can't find any references to it in Akka context.
Bartosz Sypytkowski
@Horusiath
@aph5nt persistence queries are quite similar with the difference, that they may operate on multiple persistence ids, and that they work in stream-lined fashion
@object are you sure, that you're applying this config right when actor system is created?
Vagif Abilov
@object
@Horusiath since actor system reacts on other config parts (like journal plugin) I am pretty sure that it's that config that is used. But I will try building Akka from the sources, debug and check what's going on.
Weston
@ronnyek
akka persistence will effectively allow you to simulate what orleans does?
take some report of an iot device, get actor handles that, set state
disconnect
device calls home again with updated state
persiste those updates
in an efficient manner?
Arjen Smits
@Danthar
@ronnyek yes
Aaron Stannard
@Aaronontheweb
@alexvaluyskiy yes and yes
would you mind rebasing your PRs to use the latest Akka.NET v1.0.7 persistence implementation off of official nuget?