These are chat archives for akkadotnet/akka.net

4th
Jun 2015
mick delaney
@mickdelaney
Jun 04 2015 08:57
is there an interop story between Scala Akka & akka.net i.e. remoting etc.
Nikita Tsukanov
@kekekeks
Jun 04 2015 09:15
nope, no compatible serializers
And you'll need to somehow translate type names and namespaces
Ian Barry
@ianbarry
Jun 04 2015 09:18
If anyone has updated to the new release 1.0.2, have you encountered any issues with Akka.Remote? I have a working version of 2 Azure VMs speaking to each using Akka.Remote with v1.0.1 but when I updated the package to 1.0.2 I got a SendHeartBeat Exception of method not found, that just kept looping and outputting the same error every second... So I reverted back to 1.0.1 and everything was dandy again :/
Nikita Tsukanov
@kekekeks
Jun 04 2015 09:30
Installed Akka.Cluster from Nuget, got a lot of crap from google protobufs in my project
wtf
Thomas Tomanek
@thomastomanek
Jun 04 2015 09:33
Yeah I've had that a few times, annoying
Nikita Tsukanov
@kekekeks
Jun 04 2015 10:12
I think that ps-scripts should be banned in NuGet
Or there should be an option to disable them
people misuse them for useless things like opening a website with ads
Damian Reeves
@DamianReeves
Jun 04 2015 11:16
Good morning guys. I have a scenario where I have a client (console) application which will be invoked by an enterprise job scheduler (AutoSys). This client sends work to my "Server " (quotes because this could be a cluster). I need to be able to ship log messages from the server to the client for all log messages related to the client's work request. Does the built in logging support this kind of distribution? Any guidance on how I can achieve this?
Natan Vivo
@nvivo
Jun 04 2015 11:22
@DamianReeves yes, akka log adapter just receives the messages and directs to a logger, that by default writes to the console. you can create a custom logger that directs the messages to the server.
the logger itself it just an actor that receives "log messages". take a look at https://github.com/akkadotnet/akka.net/tree/dev/src/contrib/loggers to see the implementations, they are quite simple. And to use it, just set it up in HOCON as shown here: http://getakka.net/docs/Logging
Damian Reeves
@DamianReeves
Jun 04 2015 11:26
So are the log messages available system wide out the box? For example if in my client process I register something as a Logger will it receive messages from remote actors automatically. Or do I need to be explicit about sending remote messages
Natan Vivo
@nvivo
Jun 04 2015 11:28
I'm not familiar with cluster. I think with remoting only, you will probably need to be explicit about that. With cluster, there might be something out of the box
Someonw with more knowledge on cluster can answer that
Damian Reeves
@DamianReeves
Jun 04 2015 11:29
@nvivo Okay. Thanks
Natan Vivo
@nvivo
Jun 04 2015 11:30
but since logs are just messages sent to an actor at an address, I'm guessing this is possible somehow. if not, it should be really simple to just have an actor that receives and tells another actor
Damian Reeves
@DamianReeves
Jun 04 2015 11:31
I'm seeing something in the code base about BusLogging. That might be where I need to look, I need to support message filtering and so forth (i.e. only ship over messages of Info level and higher).
Natan Vivo
@nvivo
Jun 04 2015 11:33
@Aaronontheweb is the guy to talk to about cluster and remoting. He should be online in a few hours
But you can try a post on stackoverflow too
Damian Reeves
@DamianReeves
Jun 04 2015 11:33
The key thing is I want to log all messages correlated to the request as it progresses through the actor chain i.e.: DispathActor->[Server]->CommanderActor->WorkForkActor->WorkItemActor etc
Thanks
Natan Vivo
@nvivo
Jun 04 2015 11:35
@Aaronontheweb finally had time to see your new akka remote video. That was nice. I was wondering, is there anything written related to when it's a good idea to remotely deploy actors vs have the remote system to start the actors and use only actorselection? looks like remote deploying is more of a base feature for a cluster coordinator, and not something you'd use directly, but I might be missing something. Could you write something about that?
Nikita Tsukanov
@kekekeks
Jun 04 2015 13:55
@DamianReeves
You may achive that this way:
1) create some log proxy on each machine that can handle subscription messages
2) in your client subscribe to cluster topology changes and send "subscribe" message to each note with your request id, so these loggers can send you relevant data
3) log proxy itself should also react to cluster topology changes and discard any subscribers from disconnected nodes
Or just use some clusterwise singleton as your logger, so you can send subscription requests to it directly
Nikita Tsukanov
@kekekeks
Jun 04 2015 15:02
Default configuration of JSON.NET would be unable to serialize them
@Aaronontheweb
How Akka.Remote deals with something like
public class OnDemandActorEnvelope<TId>
{
    public OnDemandActorEnvelope(TId id, object message)
    {
        Id = id;
        Message = message;
    }

    public TId Id { get; }
    public object Message {get;}
}
I mean with messages containing object fields
Bartosz Sypytkowski
@Horusiath
Jun 04 2015 15:03
we don't use default JSON.NET settings
each serialized message has it's fully qualified type name stored in $type field of produced JSON
Aaron Stannard
@Aaronontheweb
Jun 04 2015 15:08
@ianbarry could you post some of the errors that you saw to github as an issue?
@nvivo our Akka.Remoting training does talk about that - we have a section on "designing actor hierarchies when you know remoting is going to be involved"
Aaron Stannard
@Aaronontheweb
Jun 04 2015 15:26
@nvivo the TL;DR; of it is though - use remote deployment when for work distribution
anything you could use a round-robin type router for would be a good fit for remote deployment, assuming that the work being done is sufficiently CPU/memory-intensive to merit adding more machines to your application
so the web crawler example is a good one
we deploy the workers that do all of the I/O and parsing remotely onto the new processes
otherwise, use a remote actor selection to initiate remote communication between systems
but design your over-the-network message contract to reply back with at least one IActorRef that the sending side can begin talking to going forward
cc @annymsMthd I just tested out Akka.Remote v1.0.2 inside a real application and yeah, it does look like what @ianbarry reported might be true. Have you guys experienced any issues with it?
Natan Vivo
@nvivo
Jun 04 2015 16:04
Got it. Thanks Aaron!
Nikita Tsukanov
@kekekeks
Jun 04 2015 16:10
@Aaronontheweb is it valid to use IActorRef as a key for a dictionary?
@jweimann About yesterday's conversation about Passivate semantics. I'm preparing a demo project which will use it. I'll send you my example implementation in a couple of hours.
If you still need it
Joshua Benjamin
@annymsMthd
Jun 04 2015 16:29
@Aaronontheweb I'm not seeing any issues on my end
Joshua Benjamin
@annymsMthd
Jun 04 2015 16:36
method not found sounds like a mismatch in versions
Roger Johansson
@rogeralsing
Jun 04 2015 16:42
My guess that some other lib has an old version ref. Eg a lib with shared messages/actors and then only main apps have been upgraded. Resulting in old versions being copied over the correct ones.. One that, been there :)
Done*
Nikita Tsukanov
@kekekeks
Jun 04 2015 16:50
@Horusiath is original Sender used in callback from Persist method or this property is filled with something completely irrelevant?
Chris Martin
@trbngr
Jun 04 2015 17:32
@Horusiath The change to paket in your cqrs demo has broken many project references.
Ian Barry
@ianbarry
Jun 04 2015 17:53
Does anyone have any sort of best practice approach to handling errors in actors, in scenarios where you need to do a sort of exponential back-off and retry. Can you achieve this within a SupervisorStrategy on a parent of the child that threw the exception? Something similar to Polly?
Bartosz Sypytkowski
@Horusiath
Jun 04 2015 17:56
@trbngr did you try to restore dependencies using paket?
Bartosz Sypytkowski
@Horusiath
Jun 04 2015 18:01
@ianbarry in Akka.Persistence you have AtLeastOnceDelivery semantics, which can be used for your case. But often there is more than one resolution for retry mechanics, depending what are your concerns (eg. performance, resilence for both actor and VM failures) you may need to apply different tradeoffs.
Chris Martin
@trbngr
Jun 04 2015 18:02
I did. @Horusiath here's what I needed to do. delete all existing directories in packages and run 'paket convert-from-nuget --force'
PR sent
Bartosz Sypytkowski
@Horusiath
Jun 04 2015 18:07
thx :)
Chris Martin
@trbngr
Jun 04 2015 18:08
Thank YOU for this project! This is exactly the kind of reaction I wanted when I posted my little cqrs spike.
Sean Gilliam
@sean-gilliam
Jun 04 2015 18:51

hey thx @Aaronontheweb

sorry i didn't respond sooner but I've been up to my eyeballs with work this past week and am just now reading through the chat.

Ian Barry
@ianbarry
Jun 04 2015 19:48
@Horusiath awesome, thanks! Will have to check this out!
Nikita Tsukanov
@kekekeks
Jun 04 2015 21:16
Guys, I'm going to use this as a demo project to demonstrate event sourcing in cluster being consumed from WebAPI
at a conference tomorrow
If anyone has some spare time, please, take a look and tell me if I've done something wrong
Damian Reeves
@DamianReeves
Jun 04 2015 22:32
Gitter is blocked at work, so I missed the replies earlier. @kekekeks thanks for the pointers. I will give the log proxy stuff a try. If I'm using vanilla Akka.Remote is this simplified? I can probaby go with a non-clusteredbsolution first.
Nikita Tsukanov
@kekekeks
Jun 04 2015 22:32
Cluster actually does a lot of work for you by tracking connected/disconnected nodes
If you join your client to the cluster other nodes will be automatically notified when it disconnects
It's also easier to discover other nodes than storing all that information in configuration
Damian Reeves
@DamianReeves
Jun 04 2015 22:34
Ok. Sounds like cluster makes it easier not more complicated.
Are there any plans by the community to create a reusable set of Actors/ActorSystems. Things like this LogProxy, FileWatcher, & FileSyncing all sound like common scenarios one might encounter.
Nikita Tsukanov
@kekekeks
Jun 04 2015 22:39
Well, they will be published once someone actually implement them
For now we even don't have some core stuff like sharding.
Damian Reeves
@DamianReeves
Jun 04 2015 22:46
I'll leave things like sharding to the experts. I have to work on some filewatcher and the log proxy stuff for work, so I'm more than happy to take a stab at these in the open? Sounds like we should have an Akka.Contrib.