Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 18 19:12
    IgorFedchenko commented #3998
  • Oct 18 18:29
    Aaronontheweb commented #3998
  • Oct 18 18:24
    Aaronontheweb opened #3998
  • Oct 18 18:19

    Aaronontheweb on fix-readme-logo

    (compare)

  • Oct 18 17:30
    Aaronontheweb milestoned #3973
  • Oct 18 16:38
    jaydeboer opened #3997
  • Oct 18 15:53
    Aaronontheweb synchronize #3973
  • Oct 18 15:52

    dependabot-preview[bot] on dev

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

  • Oct 18 15:52

    dependabot-preview[bot] on nuget

    (compare)

  • Oct 18 15:52
    dependabot-preview[bot] closed #3996
  • Oct 18 15:52
    Aaronontheweb commented #3996
  • Oct 18 14:53
    Aaronontheweb commented #3973
  • Oct 18 12:20
    IgorFedchenko commented #3973
  • Oct 18 12:17
    IgorFedchenko commented #3973
  • Oct 18 11:58
    IgorFedchenko synchronize #3973
  • Oct 18 11:33
    IgorFedchenko commented #3973
  • Oct 18 11:25
    IgorFedchenko synchronize #3973
  • Oct 18 07:04
    dependabot-preview[bot] labeled #3996
  • Oct 18 07:04
    dependabot-preview[bot] opened #3996
  • Oct 18 07:04

    dependabot-preview[bot] on nuget

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

Aaron Stannard
@Aaronontheweb
since each will hold an actor ref to each other
Corneliu
@corneliutusnea
hm, but then if it dyes ?
Aaron Stannard
@Aaronontheweb
Context.Watch
get a deathwatch notification
and then go back through the hierarchy again
Corneliu
@corneliutusnea
ok .. so there is no way for a parent to monitor the dead-messages for their potential children
Aaron Stannard
@Aaronontheweb
there is, but all dead messages go globally to the same place
Corneliu
@corneliutusnea
yeah, so that was my question, I want to pick/intercept that in the parent not globally
Aaron Stannard
@Aaronontheweb
yeah, not possible to do that
parent can check if the child exists first
before routing the message to it
and that's the preferred way of dealing with it
Corneliu
@corneliutusnea
guys, is there a way to "consolidate" somehow multiple logs based on some correlation id?
"old school" code we used to be able to track multiple logs by the thread-id most of the times, now I get logs from all over the place
Alex Valuyskiy
@alexvaluyskiy

@Aaronontheweb Have you plan to update Persistence providers for 1.0.7? I've already made pull requests for PostgreSql and SqlServer (Akka 2.4.2 compatible) providers
akkadotnet/Akka.Persistence.PostgreSql#20
akkadotnet/Akka.Persistence.SqlServer#24

and created MySql provider
https://github.com/alexvaluyskiy/Akka.Persistence.MySql
Is it possible to move this mysql implementation to akkadotnet github account?

Corneliu
@corneliutusnea
no idea what correlates with wht
Alex Valuyskiy
@alexvaluyskiy
@Aaronontheweb also it would be good to release a new version of Wire serializer, because 0.0.6 version has a lot of bugs
Vagif Abilov
@object
Hello, I just posted a question on SO where I express my unhapinnes about message boxing in F# actors. Here it is:
http://stackoverflow.com/questions/36470453/how-should-f-actor-functions-be-defined-to-avoid-message-boxing
I must say while I enjoy Akka.NET F# API and prefer it to C#, this particular aspect looks better in C#.
Bartosz Sypytkowski
@Horusiath
@object why are you boxing them at all?
and are you using Akka.FSharp?
Vagif Abilov
@object
Yes I am using Akka.FSharp. I am boxing to be able to match messages of different types.
Bartosz Sypytkowski
@Horusiath
from my perspective this is usually a problem with handling system messages
unfortunately .NET type system is poor and don't have anything like Ceylon's type unions (don't confuse them with union types)
Vagif Abilov
@object
Exactly. I don't know Ceylon but I believe I understand what you mean and this is what I lack.
So this is partly a design question: is boxing mailbox messages a design smell (except system message case)? And if so, what is the better way? Can't see any better. They all suck :-)
@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