Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Mar 28 08:16
    AzureGulf commented #4360
  • Mar 28 08:14
    AzureGulf commented #4360
  • Mar 28 01:29
    Aaronontheweb commented #4360
  • Mar 28 01:25
    Aaronontheweb synchronize #4361
  • Mar 28 00:48
    Aaronontheweb synchronize #4361
  • Mar 28 00:44
    Aaronontheweb opened #4361
  • Mar 27 20:32
    Aaronontheweb milestoned #4360
  • Mar 27 20:32
    Aaronontheweb commented #4360
  • Mar 27 20:32
    Aaronontheweb assigned #4360
  • Mar 27 20:32
    Aaronontheweb labeled #4360
  • Mar 27 20:32
    Aaronontheweb labeled #4360
  • Mar 27 19:18
    dependabot-preview[bot] synchronize #3986
  • Mar 27 19:18

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • Mar 27 19:18
    dependabot-preview[bot] edited #3986
  • Mar 27 19:18
    dependabot-preview[bot] synchronize #4337
  • Mar 27 19:18

    dependabot-preview[bot] on nuget

    Bump FSharp.Quotations.Evaluato… (compare)

  • Mar 27 19:18
    dependabot-preview[bot] edited #4337
  • Mar 27 19:17
    dependabot-preview[bot] edited #3986
  • Mar 27 19:17
    dependabot-preview[bot] edited #4337
  • Mar 27 19:16

    Aaronontheweb on dev

    Sharding update (#4354) * Avoi… (compare)

Aaron Stannard
@Aaronontheweb
just pushed it
@bruinbrown unfortunately not - we don't have to do that very often so it hasn't been documented. Last time I had to do this was for Akka.Cluster
now that I think about it, we should include the original .proto files here https://github.com/akkadotnet/akka.net/tree/dev/src/core/Akka.Cluster/Proto if we don't already
for clustering at least
the codegen tools for creating C# files based off of a .proto description can be found here: https://github.com/google/protobuf/tree/master/csharp
I don't think we do anything special in particular, other than always make sure the generated code ends up in its own internal namespace
@creepone you should get Terminated messages if any of the following are true:
  1. the sockets were shut down
Aaron Stannard
@Aaronontheweb
  1. it took longer than the deadline failure detector's breach threshold for the system to come up
you have to explicitly call Context.Watch or you have to remotely deploy an actor onto that system to get a termination notification
upgrade to 1.0.5 immediately
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
Aaron Stannard
@Aaronontheweb
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