These are chat archives for akkadotnet/akka.net

4th
Jun 2018
Vagif Abilov
@object
Jun 04 2018 00:09
@voltcode it is very stable.
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 08:42
Hi guys, I am working with MessagePack binary serializer at the moment, I would like to serialize an IActorRef. The documentation tells me how it could work, except I don't have extendedSystem in the implementation of me IActorRefFormatter, so serializing is quite easy, but I have no idea how I would deserialize the IActorRef.
public class IActorRefFormatter : IMessagePackFormatter<IActorRef>
{
    public int Serialize(ref byte[] bytes, int offset, IActorRef value, IFormatterResolver formatterResolver)
    {
        string id = Serialization.SerializedActorPath(value);
        return MessagePackBinary.WriteString(ref bytes, offset, id);
    }

    IActorRef IMessagePackFormatter<IActorRef>.Deserialize(byte[] bytes, int offset, IFormatterResolver formatterResolver, out int readSize)
    {
        string id = MessagePackBinary.ReadString(bytes, offset, out readSize);
        IActorRef deserializedActorRef = extendedSystem.Provider.ResolveActorRef(id);

        return deserializedActorRef;
    }
}
I could add some static object links to an actorsystem, but that just seems strang te do.
Only other way I can think of is JSonConvert to string, but that's strange to me as well ....
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 08:49
And I don't really understand the paragraph about ExternalAddresses at the url: http://getakka.net/articles/networking/serialization.html
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 13:23
Ended up with this
public class IActorRefFormatter : IMessagePackFormatter<IActorRef>
{
    private static ExtendedActorSystem system;
    public static void SetExtendedActorSystem(ExtendedActorSystem extActorSystem)
    {
        system = extActorSystem;
    }

    public int Serialize(ref byte[] bytes, int offset, IActorRef value, IFormatterResolver formatterResolver)
    {
        string actorSerialized = Serialization.SerializedActorPath(value);
        return MessagePackBinary.WriteString(ref bytes, offset, actorSerialized);            
    }

    IActorRef IMessagePackFormatter<IActorRef>.Deserialize(byte[] bytes, int offset, IFormatterResolver formatterResolver, out int readSize)
    {
        string actorSerialized = MessagePackBinary.ReadString(bytes, offset, out readSize);
        return system.Provider.ResolveActorRef(actorSerialized);
    }
}
And all actorsystems are created like this:
using (var clusterSystem = ActorSystem.Create("system", config))
        {
            IActorRefFormatter.SetExtendedActorSystem(clusterSystem.AsInstanceOf<ExtendedActorSystem>());
Is there a better way?
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 14:26
Thanks, looks exactly what I need
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:35
ok, wow
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:42
just tried compiling with the .NET Core 2.1 tools
man, it really is significantly faster
Riccardo Terrell
@rikace
Jun 04 2018 14:45
yes! I did some benchmarks last week, in same cases it is 65% faster
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:46
I just benchmarked RemotePingPong with it
.NET Core App 1.1 is like 52k msg / s
.NET Core App 2.1 is 62k msg / s
(.NET 4.6.1 achieves about the same performance as .NET Core 2.1)
so there's definitely some noticeable improvements there as well, just from changing the runtime around
Riccardo Terrell
@rikace
Jun 04 2018 14:47
wow, this is awesome

question (again) regarding async/await inside a Receive. Is it good practice to run an async operation (using async/await) and using ContinueWith for handle the response? Here sub-version of the code.
void ReadyValidateRule()
{
Receive<ValidationEnvelope<ValidateRule>>(vr =>
{
var message = vr;
Validat e(vr.Message.IndividualId)
.ContinueWith<ValidationEnvelope<RuleValidationCompleted>>(taskRule =>
{
// some code here
return message.Update(new RuleValidationCompleted(RuleErrorCode, targetPopulation: taskRule.Result));

            }, TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously)
        .PipeTo(message.Message.ActorRef);
});

}
public async Task<RsDataValidationTargetPopulation> Validate(int? individualId = null)
{
using (var ctx = this.dbFactory.Create())
{
var result = await ctx.GetParticipantInfo(individualId).ToListAsync().ConfigureAwait(false);
return new RsDataValidationTargetPopulation(this, result);
}
}

note that the PipeTo sends the output the a different actor
Riccardo Terrell
@rikace
Jun 04 2018 14:53
mm.. the code formatting is not helping
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:54
yeah I can't make heads or tails of that with the formatting :p
Riccardo Terrell
@rikace
Jun 04 2018 14:54
LOL... between Slack, Skype, Gitter I am loosing it ;)
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:55
hey, once this Microsoft + Github acquisition really gets going we'll have Visual Studio Teams for Github
Riccardo Terrell
@rikace
Jun 04 2018 14:55
YES!!!
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:55
and that'll really be awesome
because Microsoft has done really well with acquiring communication platforms like Skype, Yammer, and Nokia
checks notes
oh
Riccardo Terrell
@rikace
Jun 04 2018 14:55
MSFT is really pushing to become OSS friendly
LOL
Aaron Stannard
@Aaronontheweb
Jun 04 2018 14:56
:p actually I think they'll probably make Github into a worthy JIRA + Confluence competitor
and that stuff will get integrated into the Visual Studio Services story
and it'll probably be pretty nice
the DevOps integrations might be pretty cool
in terms of stuff that affects me
so despite my jokes there I'm optimistic
Riccardo Terrell
@rikace
Jun 04 2018 14:59
me too
ok.. I ll try again with the code formatting.. here it comes

protected void ReadyValidateRule()
{
Receive<ValidationEnvelope<ValidateRule>>(vr =>
{
var message = vr;

    Validate(vr.Message.IndividualId)
    .ContinueWith<ValidationEnvelope<RuleValidationCompleted>>(taskRule =>
    {
        if (taskRule.IsFaulted)
        {
            return message.Update(new RuleValidationCompleted(RuleErrorCode, errorMessage: taskRule.Exception.Message));

        }
        return message.Update(new RuleValidationCompleted(RuleErrorCode, targetPopulation: taskRule.Result));
    }, TaskContinuationOptions.AttachedToParent & TaskContinuationOptions.ExecuteSynchronously)
.PipeTo(message.Message.ActorRef);

});

}

public async Task<RsDataValidationTargetPopulation> Validate(int? individualId = null)
{
using (var ctx = this.dbFactory.Create())
{
var query = ctx.GetParticipantInfo(individualId);

    var targtePopulation = await query.Flatten().ConfigureAwait(false);

    return new RsDataValidationTargetPopulation(this, targtePopulation);
}

}

ok... this is not a good Monday so far
Aaron Stannard
@Aaronontheweb
Jun 04 2018 15:01
lol
I think I can figure it out from here
yeah, this is fine
having the handling in a continuation function
I do similar things myself
Riccardo Terrell
@rikace
Jun 04 2018 15:02
thank you... at least one of us can figure stuff out
thank you!!!
chipdice
@chipdice
Jun 04 2018 15:30
Has anyone ever run into a situation in which an akka cluster has caused a port exhaustion issue on a machine? It has happened to me a couple of times on our dev and testing clusters before, but over the weekend we had it on one of our prod machines. Our cluster is about 12 nodes spread across 2 machines. All local network. Had to restart one of the servers. When we have been able to do a netstat, we saw a ton of akka connections, but usually we cannot even get to the machine to look at it. It has only happened a few times.
Aaron Stannard
@Aaronontheweb
Jun 04 2018 15:30
yeah we've had people report this before
two thoughts here
first: are you running on IIS?
second: DotNetty v0.4.8, which we've upgraded to in our next release, fixed a bunch of issues with socket leaks after the fact
chipdice
@chipdice
Jun 04 2018 15:31
No, Self-hosted, but IIS is installed on the machine
Aaron Stannard
@Aaronontheweb
Jun 04 2018 15:31
ok, so that rules out suspect zero
let me pull up the issues DotNetty reported
chipdice
@chipdice
Jun 04 2018 15:31
DotNetty 0.4.6
Aaron Stannard
@Aaronontheweb
Jun 04 2018 15:31
due to API changes
you wouldn't be able to upgrade to DotNetty v0.4.8 directly
you'll need to either use the latest Akka.NET nightlies or wait until 1.3.8 ships
I've asked the development team to sign off on doing the latter ASAP
chipdice
@chipdice
Jun 04 2018 15:32
You have an estimated on 1.3.8? Is this an issue w 0.4.6?
I'd like to start pushing it out today if possible
but by the time I update the release notes et al
it'll probably be tomorrow when it goes live
chipdice
@chipdice
Jun 04 2018 15:34
I can wait. So I'll need to update my Akka libs as well as DotNetty right?
Aaron Stannard
@Aaronontheweb
Jun 04 2018 15:34
if you upgrade to 1.3.8
DotNetty v0.4.8 should be included automatically
chipdice
@chipdice
Jun 04 2018 15:35
ok, I'll upgrade when you are ready. Thanks for the info
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 16:45

@Aaronontheweb

just tried compiling with the .NET Core 2.1 tools

Do you also get the performance gain netcore 2.0 vs netcore 2.1?

Aaron Stannard
@Aaronontheweb
Jun 04 2018 16:45
yeah we got some too
when we originally benchmarked on 2.0
let me see what that figure looks like
(since I'm here)
Aaron Stannard
@Aaronontheweb
Jun 04 2018 16:58

ProcessorCount: 8
ClockSpeed: 0 MHZ
Actor Count: 16
Messages sent/received per client: 20000 (2e4)
Is Server GC: True

Num clients, Total [msg], Msgs/sec, Total [ms]
1, 20000, 45978, 435.13
5, 100000, 58208, 1718.78
10, 200000, 59666, 3352.45
15, 300000, 60097, 4992.15
20, 400000, 59111, 6767.59
25, 500000, 58991, 8476.90
30, 600000, 58174, 10314.57

so it's an improvement over .NET Core 1.1
but not as high as .NET Core 2.1
AndreSteenbergen
@AndreSteenbergen
Jun 04 2018 16:58
thx, right in the middle
;)
Aaron Stannard
@Aaronontheweb
Jun 04 2018 16:59
and for folks who are interested in some of the stuff we're looking into for Akka.Remote performance, I just spent 45 minutes writing up this wall-o-text: https://github.com/akkadotnet/akka.net/issues/2378#issuecomment-394420980
voltcode
@voltcode
Jun 04 2018 17:02
thanks @Aaronontheweb
Aaron Stannard
@Aaronontheweb
Jun 04 2018 17:10
no problem @voltcode
figured giving you the full story on that thread would be worth it
other folks from the Akka.NET team may have some different theories (although I think we're pretty much agreed on the serializer stuff being something that can and will be improved)
but those are mine
performance issues that come about as a result of architectural choices are a pain in the ass to debug because it's not something that a performance profiler is going to help you find
because it's usually not just one thing that causes an issue, it's a combination
so that's why I'm doing a bit of dogfooding with Akka.Streams inside Akka.Remote here - super, super early stages there though: https://github.com/Aaronontheweb/Akka.Streams.RemoteTransport
but TL;DR; - our model for Akka.Remote would really benefit from the "reactive streams" design that Akka.Streams exposes, IMHO
as that will do a better job managing the bandwidth of each connection than what we currently do
on top of that, if we did get the guts of Akka.Remote re-arranged and expressed as streams
making performance tweaks would become a much simpler exercise in some respects
Aaron Stannard
@Aaronontheweb
Jun 04 2018 17:16
i.e. I could just add a batching stage (GroupedWithin or something) after we've serialized the messages to ensure that we're always filling up the outbound buffer with as much capacity as it can handle each time
and that'd be a one-line code change instead of a big engineering project like it is today
Ebere Abanonu
@eaba
Jun 04 2018 17:21
Persist(expired, async subscriptionExpired =>
{
                });
is that safe?
@Aaronontheweb
Aaron Stannard
@Aaronontheweb
Jun 04 2018 17:25
does it compile?
without any warnings?
Ebere Abanonu
@eaba
Jun 04 2018 17:25
yes it does
Aaron Stannard
@Aaronontheweb
Jun 04 2018 17:25
should..... be.....
:worried:
not 100% sure on that lol
cc @Horusiath any ideas on that?
Ebere Abanonu
@eaba
Jun 04 2018 17:26
am doing await within it
Just wanted to find out from the experts if am safe on that path
``
Persist(send, async sendMessage =>
{
if (_cachedEndPoints.TryGetValue("ooooo", out var endPoint))
{
await endPoint.Send(sendMessage);
}
else
{
var endpoint = await _bus.GetSendEndpoint(new Uri("https://ppppppppp.servicebus.windows.net/uiiiii_messaging"));
await endpoint.Send(sendMessage);
_cachedEndPoints.Add("opppp_messaging", endpoint);
}
});
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:33
@eaba @Aaronontheweb it's not quite safe
Ebere Abanonu
@eaba
Jun 04 2018 17:34
How can it be made safe?
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:37
@eaba persist callbacks are meant mostly for persistent actor state update + they should store events, not commands. I really don't see, what advantage does your Persist usage promotes over plain old Receive method.
Ebere Abanonu
@eaba
Jun 04 2018 17:39
It was imposed on me by a library that only provides awaitable task.....am actually trying to avoid Result...from experience I know that can deadlock
Ok....after the message has been persisted, I need to publish a notification
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:44
but what do you need to persist message for?
Ebere Abanonu
@eaba
Jun 04 2018 17:48
The actor acts as a response actor.....The system gets a command, after the actor assigned to that command has successfully executed, the result is sent to the Response actor......am trying to avoid loosing any message in case of crash or reboot.....azure cloud classic
I know i can use PipeTo
am just being lazy
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:52
ok, so you've persisted a message - but what gain does it give you? You don't know if you've already processed that message (since you're presisting message itself, not an event being the effect of the processing), you also cannot replay it reliably in case of actor restart, as you may replay thousands of commands, you've already executed
also you're using service bus in the middle of actor processing
Ebere Abanonu
@eaba
Jun 04 2018 17:53
yes
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:55
the usual pattern with service bus is to send a command - which starts some sort of pipeline processing - to the service bus itself, and then handle the entire processing using just actors. For this, service bus is used only on the facade of your actor system and notified when the entire process has finished.
Ebere Abanonu
@eaba
Jun 04 2018 17:57
@Horusiath my implementation is not far from that
I didnt forget about SnapShots though
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 17:57
the case I've described has no notion of akka.persistence ;)
Ebere Abanonu
@eaba
Jun 04 2018 17:58
What you are saying in other words is that I should get rid of Akka.Persistence, right?
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 18:02
based on your example, I don't see any advantage of using it
Ebere Abanonu
@eaba
Jun 04 2018 18:03
Ok General @Horusiath !!
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 18:03
xD
Ebere Abanonu
@eaba
Jun 04 2018 18:05
can I atleast do this? Task.Run(async()=>{})
with UntypedActor
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 18:07
Akka ReceiveActor and ReceivePersistentActor have ReceiveAsync and CommandAsync which can work with async lambdas
Task.Run will start a task but it won't block actor from picking the next message from its mailbox
Ebere Abanonu
@eaba
Jun 04 2018 18:12
ReceiveAnyAsync(message =>
{
return Task.Run(async () => { await Handle(message); });
});
correct?
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 18:14
I think that ReceiveAnyAsync(Handle); looks shorter
but Receive<> and ReceiveAsync<> are there for a reason - to decouple incoming messages by their function.
Ebere Abanonu
@eaba
Jun 04 2018 18:15
ok
I went for ReceiveAnyAsync because I chose to use switch pattern matching
Since am not really doing much
just pushing out
Ebere Abanonu
@eaba
Jun 04 2018 18:32
Thanks @Horusiath and @Aaronontheweb more happiness to your hearts
Bartosz Sypytkowski
@Horusiath
Jun 04 2018 18:32
Thanks @eaba . Happy hakking :)
Aaron Stannard
@Aaronontheweb
Jun 04 2018 22:59
Akka.Persistence.SqlServer v1.3.7 is going live on NuGet https://github.com/akkadotnet/Akka.Persistence.SqlServer/releases/tag/v1.3.7 cc @mrrd
soon-ish