Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:35
    dependabot-preview[bot] labeled #128
  • 06:35
    dependabot-preview[bot] opened #128
  • 06:35

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.10.2… (compare)

  • Apr 07 22:47
    PiotrJustyna commented #4368
  • Apr 07 22:13
    PiotrJustyna opened #4371
  • Apr 07 19:14
    PiotrJustyna commented #4368
  • Apr 07 17:03
    Arkatufus closed #4368
  • Apr 07 15:55
    dependabot-preview[bot] synchronize #3986
  • Apr 07 15:55

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • Apr 07 15:55
    dependabot-preview[bot] synchronize #4337
  • Apr 07 15:55

    dependabot-preview[bot] on nuget

    Bump FSharp.Quotations.Evaluato… (compare)

  • Apr 07 15:55
    dependabot-preview[bot] edited #4337
  • Apr 07 15:55
    dependabot-preview[bot] edited #3986
  • Apr 07 15:54
    dependabot-preview[bot] edited #4337
  • Apr 07 15:54
    dependabot-preview[bot] edited #3986
  • Apr 07 15:53

    dependabot-preview[bot] on dev

    Bump BenchmarkDotNet from 0.12.… (compare)

  • Apr 07 15:53

    dependabot-preview[bot] on nuget

    (compare)

  • Apr 07 15:53
    dependabot-preview[bot] closed #4370
  • Apr 07 15:53
    Aaronontheweb commented #4370
  • Apr 07 14:59
    PiotrJustyna commented #4368
Aaron Stannard
@Aaronontheweb
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
I figure it'd be fun to switch things up a bit a give Travis a try on this repo