Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:46
    Arkatufus synchronize #4228
  • 20:17
    Arkatufus synchronize #4228
  • 19:55
    Arkatufus opened #4228
  • 19:14
    Arkatufus synchronize #4226
  • 18:28
    Aaronontheweb commented #4226
  • 18:27
    Aaronontheweb commented #4226
  • 18:23
    Aaronontheweb synchronize #4226
  • 18:23

    Aaronontheweb on nuget

    (compare)

  • 18:23

    Aaronontheweb on dev

    Bump Google.Protobuf from 3.11.… (compare)

  • 18:23
    Aaronontheweb closed #4225
  • 18:23

    Aaronontheweb on dev

    ActorSpawn benchmark tweaks (#4… (compare)

  • 18:23
    Aaronontheweb closed #4227
  • 18:17
    Aaronontheweb labeled #4227
  • 18:17
    Aaronontheweb labeled #4227
  • 18:17
    Aaronontheweb opened #4227
  • 18:15
    Aaronontheweb commented #4226
  • 18:13
    Arkatufus commented #4226
  • 18:12
    Arkatufus commented #4226
  • 17:54
    Arkatufus commented #4226
  • 17:27
    Arkatufus synchronize #4226
Aaron Stannard
@Aaronontheweb
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
I figure it'd be fun to switch things up a bit a give Travis a try on this repo
John Haigh
@haighis
@Aaronontheweb make sure you specify the solution name correctly.. I didn't ...can you merge this PR akkadotnet/HOCON#25
Suhas Chatekar
@schatekar
@Aaronontheweb I added some questions on the PR for the multinode spec you ported. This is more for my understanding of how the spec works