Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 17:48
    to11mtm synchronize #4642
  • 16:43
    to11mtm opened #4642
  • Nov 27 23:37
    motmot80 edited #4641
  • Nov 27 23:35
    motmot80 commented #4641
  • Nov 27 23:26
    motmot80 opened #4641
  • Nov 27 07:30
    to11mtm synchronize #4581
  • Nov 27 06:37
    tesgu commented #4639
  • Nov 26 17:31
    razvangoga commented #4215
  • Nov 26 17:28
    razvangoga commented #4215
  • Nov 26 17:18
    Aaronontheweb commented #4215
  • Nov 26 17:16

    Aaronontheweb on 1.4.12

    (compare)

  • Nov 26 17:15

    Aaronontheweb on master

    Bump AkkaVersion from 1.4.5 to … Bump Microsoft.NET.Test.Sdk fro… Bump MongoDB.Driver from 2.10.4… and 10 more (compare)

  • Nov 26 17:15
    Aaronontheweb closed #163
  • Nov 26 17:15
    Aaronontheweb opened #163
  • Nov 26 17:14

    Aaronontheweb on 1.4.12

    (compare)

  • Nov 26 17:14

    Aaronontheweb on dev

    Added v1.4.12 release notes (#1… (compare)

  • Nov 26 17:14
    Aaronontheweb closed #162
  • Nov 26 16:48
    Aaronontheweb opened #162
  • Nov 26 16:48

    Aaronontheweb on 1.4.12

    Added v1.4.12 release notes ##… (compare)

  • Nov 26 16:47

    dependabot-preview[bot] on nuget

    (compare)

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