These are chat archives for akkadotnet/akka.net

13th
Jun 2016
Tyagit3
@Tyagit3
Jun 13 2016 03:46 UTC
@Aaronontheweb Thanks Aaron. But what if the case is peer to peer model ?
ilhadad
@ilhadad
Jun 13 2016 14:52 UTC
@Horusiath is there somewhere where I can read up and see an example on the updated persistence plug-in? I am not sure how to use this.
Bartosz Sypytkowski
@Horusiath
Jun 13 2016 17:14 UTC
@ilhadad what do you need? http://getakka.net/docs/#akka-persistence is the good place to start
Aaron Stannard
@Aaronontheweb
Jun 13 2016 19:22 UTC
@Tyagit3 in a peer to peer model
one of the defining traits of that
is that connectivity must be able to flow in any direction
so the best bet to make that sane
is to standardize your port number
and write some bootstrapper code that resolves the your actor system's IP address from the correct network device
Akka.Cluster is fundamentally peer-to-peer
and so we recommend that same setup there
if you're written client side applications that need peer-to-peer netorking
you'll need to add a script to your installer which requests a firewall exception
(I'm still reeling from the trauma of shipping client-side SDKs at my last job, in case you were wondering lol)
ilhadad
@ilhadad
Jun 13 2016 19:52 UTC
@Horusiath On this statement in the Write MessagesAsync "If the journal (data store) cannot support atomic writes of multiple
/// events it should reject such writes with a <see cref="NotSupportedException"/>
/// describing the issue. This limitation should also be documented by the journal plugin."
Where would I exactly throw the exception?
Bartosz Sypytkowski
@Horusiath
Jun 13 2016 19:54 UTC
@ilhadad you as user, nowhere. It's a duty of the journal plugin to do so
ilhadad
@ilhadad
Jun 13 2016 19:57 UTC
@Horusiath I mean in the plugin. I am updating the Couchbase plugin. It does not support transactions so I am trying to figure out where I would throw the exception so that it won't attempt multiple writes as I cannot guarantee a roll-back if one of them fails.
Bartosz Sypytkowski
@Horusiath
Jun 13 2016 20:00 UTC
I think, that before place where you're iterating over AtomicWrite IPersistentRepresentations - you can check if their length != 1 and if so, then throw an exception with an explanation
Aaron Stannard
@Aaronontheweb
Jun 13 2016 20:13 UTC
private long _nextRandomNameDoNotCallMeDirectly = -1;
@alexvaluyskiy like my fix to your counter issue?
lol
ilhadad
@ilhadad
Jun 13 2016 20:18 UTC
@Horusiath Ok. Got it. Thanks

when sending a response back to another actor, is it possible to have something like:

SomeClass response = null;
Sender.Tell(response);

and test this with ExpectMsg<SomeClass>(), checking that it's null? Or do I have to implement some sort of NotFound class?

I'm guessing I need to wrap this in another class, like:
SomeClassResponse response = new SomeClassResponse(data: null);
Sender.Tell(response);
yep, that worked
Alex Valuyskiy
@alexvaluyskiy
Jun 13 2016 20:39 UTC
@Aaronontheweb not exactly, we have AtomicCounter for this purposes
We we are using surrogates in routers? We have implemented surrogates in Local routes, and unimplemented (with UnsupportedException) in cluster routers
Marc Piechura
@marcpiechura
Jun 13 2016 20:45 UTC
This message was deleted
Aaron Stannard
@Aaronontheweb
Jun 13 2016 21:16 UTC
@alexvaluyskiy for the create children syntax we just use Interlocked
AtomicCounter is just a wrapper over that
Aaron Stannard
@Aaronontheweb
Jun 13 2016 21:41 UTC
working on putting together the multinode test runner nuget packages now
finally, some F# for me!
really looking forward to putting this tool out there
definitely needs some improvements on the UX side
but there's no denying that it's a type of testing tool that is basically unheard of in .NET
sounds awesome @Aaronontheweb ... any sneak peek?
Aaron Stannard
@Aaronontheweb
Jun 13 2016 21:52 UTC
I have a really crappy youtube video we recorded during a contributor's meeting
(I BSODed in the middle of filming it)
the "unheard of" description has piqued my curiosity. I'd like to hear of it! :)
not sure how complete this demo is
but I basically explain how to write one
bah, the movie embedded in Gitter chat starts from the beginning
ship ahead to about 11:30
:plus1:
Aaron Stannard
@Aaronontheweb
Jun 13 2016 21:56 UTC
I'll make one of these with higher production values after we ship 1.1
but the TL;DR; of it is
if you're working with Akka.Remote, Akka.Cluster, etc
and you want to know the answer to a question like
"gee, does my software do the right thing if two of my services get disconnected from eachother?"
the Remote TestKit is how you find out
it provides an API for describing an arbitrary number of nodes
who will be participating in a given test
and you can write those tests in such a way
where Node 1 does X
Node 2 does Y
and Node 3 just kind of hangs out
if Node1 doesn't get the response back it expects from Node 2 or Node 3
it can throw a failure and mark the entire test as failed
even though the other two nodes might be just peachy
the Remote TestKit runs each node in its own isolated process
so we're simulating a network
which also means, ta-da, you can do fun stuff like tell the TestConductor, the coordinator that runs the test, to do things like disconnect two nodes from each other
or introduce packet loss
and then you can restore connectivity again later
there's also synchronization barriers you can use
to make sure all nodes arrive at the same place before moving onto the next part of the test
the multinode test runner is the custom test runner that actually runs the Akka.Remote.TestKit tests
nice... I'm wondering if there's a way to adapt this to specifically test this for an Azure deployment in order to find the most stable way to do Azure hosting. Or is there something else more appropriate?
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:00 UTC
theoretically
you could change the part where the main MNTR process spawns each node in a local process
to have it spawn the process remotely
but that would require forking it
what this tool is really for is testing what happens when the network does "a bad thing"
right, so things like .SimulateNodeDown() isn't pluggable.
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:03 UTC
it uses the transport adapters built into Akka.NET
simulate node down would produce the same result on any cloud environment
it's abstract in that sense
yeah, just thinking that if one could override an INodeTester, that allows for the default virtualized one, or you could plug one in for Azure, AWS, GCE, Linode, DigitalOcean, etc. and ensure expected behavior across platforms.
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:09 UTC
I see what you mean
I don't think that would be all that feasible to do mostly because of the time involved in bringing a new node online
and introducing latency / temporary network failures between nodes would require access to the hardware
that being said, doing things like testing a hot deployment onto a node that's already running
and seeing how that joins the cluster
that would be cool
it'd be somewhat abusing what I imagine is meant to be a unit test, but some kind of platform-based instrumentation/verification might be useful.
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:18 UTC
it's really meant to be a "scenario test"
so it's kind of like an integration test where you pre-program what the user does
yep
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:18 UTC
and then have some failure monkey come in and start screwing stuff up
Jannis
@schjan
Jun 13 2016 22:23 UTC
Hello,
I have a question about Akka.Remote. Documentation says, that for a Client-Server connection it is better tu use HTTP or Akka I/O. In Use Cases it says "1. Client applications (WPF) with duplex communication.."
I tried a local Client-Server connection with Akka.Remote and it worked well. Are there problems to expect when the Client is behind a firewall?
What are the benefits of using HTTP (aka SignalR) over Akka.Remote there?
Aaron Stannard
@Aaronontheweb
Jun 13 2016 22:24 UTC
Akka.Remote is designed to allow actor systems to communicate with each other remotely in a transparent way
nothing wrong with using it in client-server communication
the benefit of HTTP / Akka.IO, and what I think the docs were trying to say
is that if you need some non-Akka.NET system to send input to an Akka.NET actorsystem
HTTP and Akka.IO are designed for that
whereas Akka.Remote is not - it's meant for actor communication only basically
however, if your stuff is already working then that problem is solved
Jannis
@schjan
Jun 13 2016 22:30 UTC
Thank you for your answer. For now I only tested it locally. But later the server should be on a different system. Another part of the documentation: Communication between involved systems is symmetric: if a system A can connect to a system B then system B must also be able to connect to system A independently. This sounds like the server needs to be able to connect to the client, which wouldn't be possible with any firewall or even a router between Server -> Client.
What you say sounds like the Client connects to the Server and then everything will work.
ilhadad
@ilhadad
Jun 13 2016 22:31 UTC
@Horusiath do I persist the AtomicWrite object whole or in part?
Previously, I was creating a journal entry like this:
        private Document<JournalEntry> ToJournalEntry(IPersistentRepresentation message)
        {
            return new Document<JournalEntry>
            {
                Id = message.PersistenceId + "_" + message.SequenceNr.ToString(),
                Content = new JournalEntry
                {
                    Id = message.PersistenceId + "_" + message.SequenceNr,
                    isDeleted = message.IsDeleted,
                    Payload = message.Payload,
                    PersistenceId = message.PersistenceId,
                    SequenceNr = message.SequenceNr,
                    Manifest = message.Manifest
                }
            };
        }
ilhadad
@ilhadad
Jun 13 2016 22:39 UTC
And this object got serialized and written to the database. I am asking because it seems the AtomicWrite has all this baked into it.
Aaron Stannard
@Aaronontheweb
Jun 13 2016 23:21 UTC
@schjan ideally, yes
Akka.Remote should be able to associate in either direction
but in practice you don't have to
if you design your code in such a way
where the client always connects to the server
that is still valid
just have to factor that into the design
Akka.Remote will not attempt to automatically reconnect or anything like that
Akka.Cluster does that
but Akka.Remote is dumb - it's infrastructure