These are chat archives for akkadotnet/akka.net

2nd
Jun 2017
jclagache
@jclagache_twitter
Jun 02 2017 13:28

Hi. I'm modifying parts of a legacy app that makes extensive use of WCF and DI through Unity.
I'm using Akka.NET
One of my concerns is managing dependency between services and actors, more specifically how a service can rely on an actor (its actor ref).
Considering a frontend service (consumer endpoint from an EAP point of view) that delegates to a dispatcher actor.
This frontend service could potentially be exposed as a WCF Http Service.
How should I managed the dependency between the service and the actor ?
like the controller in this docs ?
or should I use constructor dependency :

public class FrontendServiceWithExplicitDependency : IFrontendService
{
    private readonly IActorRef _actor;

    public FrontendServiceWithExplicitDependency(IActorRef actor)
    {
        _actor = actor;
    }
...
}

This repo resumes my concerns between the 2 services implementations.

Arjen Smits
@Danthar
Jun 02 2017 13:42
@jclagache_twitter there is no distinctive set of recommendations when you want to integrate Akka.net In a legacy App. Simply because every legacy app has their own set of constraints.
Actors have their own lifecycle, seperate of what you define in your DI container. You need to realise that the only thing that you are only registering an IActorRef, not the Actor instance itself, in your DI container.
This makes the whole discussion a lot more about "How do i best communicate in my code which dependency my service uses".
You can utilize the constructor injection
But then in your code you will only see an IActorRef dependency
it does not convey what kind of actor it is
That is only defined in your CompositionRoot (the place where you define your DI config)
Personally i dont like this approach.
I like to be clear which actors are being used by a service. So i use a static class reference ActorRefs.MySpecialActor
public class FrontendServiceWithExplicitDependency : IFrontendService
{
    private readonly IActorRef _actor;

    public FrontendServiceWithExplicitDependency(ISomeDependency dep)
    {
        _actor = ActorRefs.MySpecialActor;
    }
...
}
jclagache
@jclagache_twitter
Jun 02 2017 13:52
Thx @Danthar for your response.
So, you would go with the FrontendServiceWithoutExplicitDependency.
Arjen Smits
@Danthar
Jun 02 2017 13:52
Yes
Because its immediately clear with which actor in your system you intent to communicate
Anders Storhaug
@andersstorhaug
Jun 02 2017 14:12
With switchable behaviors, I've found cases where I want specific Receive<TMessage>s in every behavior. Current pattern I've been using is - use an AnyTime() method to define these handlers, then in each behavior, start by calling AnyTime() to register them.
But, that get's a little messy, for instance when I want a "any behavior" handler, but also I want to specifically handle that message in a behavior. So, the AnyTime() handler can return false.. Receive<MyMessageForAnyBehavior>(m => {/*...*/ return false; }) in that case, but I can't help but question if there's a better way to do this
Anyone have a preferred way to do this type of thing?
Anders Storhaug
@andersstorhaug
Jun 02 2017 14:18
Maybe a nice simple example for this is an actor with switchable behaviors, and SetReceiveTimeout
Lealand Vettleson
@spankr
Jun 02 2017 15:57
I have an issue with using Akka.Persistence.MongoDb. If I persist an event or snapshot, I am able to recover just fine, while my application is running. If I power cycle the application, it cannot recover.
If I slap some BsonClassMap.LookupClassMap() calls at the start of our application, this issue goes away.
It bothers me that our app has to know implementation details that are unique to the persistence plugin that I choose. Is there any interest if I submit a PR that would have those LookupClassMap calls be unnecessary?
Aaron Stannard
@Aaronontheweb
Jun 02 2017 16:02
@spankr yeah, that's wrong
send in a PR
@heynickc do we have integrated CI running for Mongo again?
Lealand Vettleson
@spankr
Jun 02 2017 16:02
Will do! What branch should I target on the PR?
Aaron Stannard
@Aaronontheweb
Jun 02 2017 16:02
dev
safe by default
Lealand Vettleson
@spankr
Jun 02 2017 16:03
:+1:
Nick Chamberlain
@heynickc
Jun 02 2017 16:04
@Aaronontheweb no, not yet
Lealand Vettleson
@spankr
Jun 02 2017 16:05
The issue seems to stem from the fact that MongoDB stores snapshots with the type's (short) name
if it stored the full name + assembly, then it would be able to deserialize the snapshot objects
Aaron Stannard
@Aaronontheweb
Jun 02 2017 16:07
@alexvaluyskiy IIRC, we had a standard we discussed in the past about plugin-specific serialization did we not? did that ever make it into a public spec
I don't think it did but I can't remember - lost that thread :p
Alex Valuyskiy
@alexvaluyskiy
Jun 02 2017 16:13
@Aaronontheweb No, it is not ready yet :(
Lealand Vettleson
@spankr
Jun 02 2017 16:31
@Aaronontheweb okay, the PR is out there if you guys want to review it (akkadotnet/Akka.Persistence.MongoDB#28)
Sean Farrow
@SeanFarrow
Jun 02 2017 17:35
If I build a dev branch, will this bill for.net standard? I'm just about to start supporting application I could do with doing this in the next couple of days I know this was due to be released on 30 June but any help is appreciated in the meantime
Marc Piechura
@marcpiechura
Jun 02 2017 17:46
@SeanFarrow if you're targeting Akka.net Core repo please use v1.3 with .net Core, for alpakka you can use dev, without .net Core
Lealand Vettleson
@spankr
Jun 02 2017 19:08
@Horusiath How active are you with the Akka.Persistence.EventStore plugin?
I'm thinking I'll spend some more time with that now that it's Friday afternoon
Bartosz Sypytkowski
@Horusiath
Jun 02 2017 20:37
@spankr feel free to experiment
I'm not an active contributor to this one
Lealand Vettleson
@spankr
Jun 02 2017 20:40
sounds good, thanks!
I'm poking at the EventStore.Client library right now to see if it behaves nicely (it doesn't)