Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 03 22:24
    huzaifak opened #4367
  • Apr 03 21:45
    Aaronontheweb commented #4344
  • Apr 03 05:55
    Lutando commented #4344
  • Apr 02 17:23
    huzaifak commented #4303
  • Apr 02 17:23
    huzaifak closed #4303
  • Apr 02 02:13
    ShawnYun commented #4366
  • Apr 01 17:18
    huzaifak commented #4303
  • Apr 01 14:30
    Aaronontheweb commented #4366
  • Apr 01 14:29
    Aaronontheweb closed #4360
  • Apr 01 14:29
    Aaronontheweb commented #4360
  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    (compare)

  • Apr 01 06:43
    dependabot-preview[bot] closed #151
  • Apr 01 06:43
    dependabot-preview[bot] commented #151
  • Apr 01 06:43
    dependabot-preview[bot] labeled #152
  • Apr 01 06:43
    dependabot-preview[bot] opened #152
  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    Bump AkkaVersion from 1.4.1 to … (compare)

  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    (compare)

  • Apr 01 06:43
    dependabot-preview[bot] closed #125
  • Apr 01 06:43
    dependabot-preview[bot] commented #125
  • Apr 01 06:43
    dependabot-preview[bot] labeled #127
Aaron Stannard
@Aaronontheweb
it resolves an issue where sockets were not cleanly shutdown in Akka.Remote
but on the flipside, if you just nuke the process (i.e. you don't actually program your windows service to call System.ShutDown())
the sockets might still linger open for a brief period of time
so make sure your Windows service performs a shutdown call when it stops
and upgrade to the latest
@billyxing > When a client is shutdown, the server will print out akka.remote.endpointdisassociatedException: Disassociated
I want to you make the following distinction for me
exception != something is wrong
it means something exceptional happened
Akka.Remote will always throw a disassociationexception and mark it as an error, even if it's an intentional planned termination
reason for this is so it always shows up in the logs
I get that question a lot - and the answer is just to not make it mean something that it isn't
Anthony Brown
@bruinbrown
@Aaronontheweb awesome, I've managed to work around it now but I'll move stuff around when I refactor. Hopefully I'll be able to get a PR in soon for the list data stuff
Aaron Stannard
@Aaronontheweb
we have an outstanding issue to make disassociation messages clearer specifically akkadotnet/akka.net#1087
Anthony Brown
@bruinbrown
@Aaronontheweb I was planning on doing a partial pull request for now, since I've only implemented a couple of the CRDTs in C# so far, it might make a decent up for grabs issue
Aaron Stannard
@Aaronontheweb
when you should care about disassociations is when they happen unexpectedly
When a client is shutdown, the server will print out akka.remote.endpointdisassociatedException: Disassociated
in this case, since the error message is "disassociated"
this actually is an error - it means an unplanned termination
if you shutdown a client and make a call to System.Shutdown() first
that log will change to akka.remote.endpointdisassociatedException: Shutdown
which is benign
@bruinbrown cool, we might have to create a feature branch for that - but we'll discuss that on the PR!
looking forward to it
Anthony Brown
@bruinbrown
@Aaronontheweb it's almost complete as is, just got a few bits left to finish, btw any thoughts on the monotonic clock issue from the other day? Happy to make the change, I'd just be interested in a little guidance since it might touch a lot of clustering code
Ivan R. Perez
@irperez
@Aaronontheweb thanks for merging the pull request. @MaciekLesiczka thanks for the new feature!!!
This message was deleted
Aaron Stannard
@Aaronontheweb
@bruinbrown is there any reason why it should be made public? otherwise you can just expose it via a friend assembly
Properties/AssemblyInfo.cs inside the core Akka.NET project will show you where we did that in a number of areas
that'll give your assembly access to the MonotonicClock even though it's internal
Anthony Brown
@bruinbrown
@Aaronontheweb cool, I'll take that approach
Aaron Stannard
@Aaronontheweb
@billyxing @creepone we'll make sure that #1087 gets done - it's important to make the reason for those messages clearer. But in the meantime, remote deathwatch should work fine. Could you show me a gist where you're setting it up and handling it?
@cpx taking a look at your PR now
going to see if I can replicate that error
yep, repro'd it
Aaron Stannard
@Aaronontheweb
looks like the message is being sent twice...
interessant
Aaron Stannard
@Aaronontheweb
ha! I figured it out
@cpx so one of the things we do inside Akka.Remote when we first create an association is we put all non-system messages into a buffer, queued for delivery after the association opens
in the event that some of those buffered messages fail delivery, we schedule a backoff + retry
so the reason why we're seeing two OversizedPayloadExceptions is because of the retry
this is the culprit:
private void Writing(object message)
        {
            if (message is EndpointManager.Send)
            {
                var s = message as EndpointManager.Send;
                if (!WriteSend(s)) //returns false on oversized payload
                {
                    if (s.Seq == null) EnqueueInBuffer(s);
                    ScheduleBackoffTimer();
                    Context.Become(Buffering);
                }
            }
inside Endpoint.cs
Aaron Stannard
@Aaronontheweb
ok, this is an easy fix actually
I'll post a comment on the diff
John Haigh
@haighis
@Aaronontheweb akkadotnet/HOCON#11
Aaron Stannard
@Aaronontheweb
thanks @haighis
working on syncing all of my repos to Travis now