by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 26 16:37
    to11mtm commented #4563
  • Sep 26 16:34
    to11mtm commented #4563
  • Sep 25 07:59
    ingted commented #4570
  • Sep 25 07:57
    ingted commented #4570
  • Sep 25 07:54
    ingted commented #4570
  • Sep 25 06:10
    ismaelhamed commented #4570
  • Sep 24 22:46
    nagytech commented #4570
  • Sep 24 14:18
    ingted commented #4570
  • Sep 24 10:40
    ingted edited #4570
  • Sep 24 10:39
    ingted edited #4570
  • Sep 24 10:36
    ingted edited #4570
  • Sep 24 10:33
    ingted opened #4570
  • Sep 17 17:14
    briansain commented #4567
  • Sep 17 16:59
    briansain synchronize #4568
  • Sep 17 16:27
    VaclavK closed #51
  • Sep 17 16:27
    VaclavK closed #50
  • Sep 15 14:57
    BartHuls closed #4569
  • Sep 15 14:18
    Aaronontheweb commented #4563
  • Sep 15 13:53
    Zetanova commented #4563
  • Sep 15 13:41
    Aaronontheweb commented #4563
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
I am not sure if it was appropriate to add comments on the PR though
Tomas Vana
@creepone
blob
@Aaronontheweb I boiled it down to this gist. I start 2 instances of this app, reconfiguring each to point to the other one. If I kill one of them and wait for ca. 2 seconds, the first one does get the Terminated message and Peer terminated is printed. However, if I'm too fast to restart the killed instance running on the same port, the first one gets confused, spits out the errors above and the Terminated message is not received.
Roger Johansson
@rogeralsing
@creepone that sounds like an UID issue, the new system should not get the same UID as the previous one and the cluster should not think they are the same
Tomas Vana
@creepone
@Aaronontheweb I just figured that adding AwaitTermination after the Shutdown call fixes it both in 1.0.4 and 1.0.5 if I stop it gracefully. When killing it hard, even in 1.0.5 the behavior is same though. Of course when under my control I can try to gracefully close it down, but what if it crashes on me and gets restarted automatically ?
@rogeralsing That sounds plausible. Is there any way to confirm (find out what the UIDs are) ?
Roger Johansson
@rogeralsing
what bits are you running? nuget or dev branch?
Tomas Vana
@creepone
I tried both nuget and 1.0.5.69-beta from the MyGet feed.
Bartosz Sypytkowski
@Horusiath
@Aaronontheweb why did you put all of the spec porting tasks in a separate issues each? This feels a little messy for me