Hello, can maybe someone Confirm that the first example releated to this: https://getakka.net/articles/intro/use-case-and-deployment-scenarios.html using FluentConfig is absolete and have to be updated ?
How can i configure hyperion serialization?
I followed getakka.net serialization document, but it doesn't work.
I followed getakka.net serialization document, but it doesn't work.
As you can see, matched serializer is still
NewtonSoftJsonSerializer
I've been using Akka.Net for over 3 years and just really enjoy working with Actors, messaging and SignalR.
Here is my latest creation - https://github.com/cgstevens/FileProcessor
Here is my latest creation - https://github.com/cgstevens/FileProcessor
and this can work simultaneously across multiple machines?
@Aaronontheweb Thanks Aaron!
Well I have only been working on my system but I did run a quick test and my work was in a different domain as well as a copy of my WindowsMonitor, so yes to answer your question :)
I am trying to get a project together that demonstrates all of the AWESOME tools you all have built.
So right now in the solution contains the following services:
Lighthouse - service discovery
Processor (EastCoast/WestCoast) - This is to simulate the Singleton Actor, there can only be one just like highlander :) Basically keeps track of jobs.
Worker (EastCoast/WestCoast) - This demonstrates the ClusterRouterPool and distributes the reading of a line.
WIndowsMonitor - WindowsForms application that allows you to view into the cluster... (just like my other I have created)
WebMonitor - This is using SignalR to funnel message from an actor which is using PubSub Mediator to subscribe to Topics from the Processor and Worker services.
Well I have only been working on my system but I did run a quick test and my work was in a different domain as well as a copy of my WindowsMonitor, so yes to answer your question :)
I am trying to get a project together that demonstrates all of the AWESOME tools you all have built.
So right now in the solution contains the following services:
Lighthouse - service discovery
Processor (EastCoast/WestCoast) - This is to simulate the Singleton Actor, there can only be one just like highlander :) Basically keeps track of jobs.
Worker (EastCoast/WestCoast) - This demonstrates the ClusterRouterPool and distributes the reading of a line.
WIndowsMonitor - WindowsForms application that allows you to view into the cluster... (just like my other I have created)
WebMonitor - This is using SignalR to funnel message from an actor which is using PubSub Mediator to subscribe to Topics from the Processor and Worker services.
@zimayel_gitlab yes, that's correct
we haven't supported that syntax in years
Hey guys,
I have data duplication issue when using TCP. I'm sending from "for" loop on client and reply with the same message from akka (echo).
If the message size 15 bytes + 4 for length, everything is perfect (sent 20k messages that is arrived in order and no duplication).
If message size more than that, duplications arrived. The pattern here is 1,2,3,4,2,3,4,5,6,7,8,2,3,4,5,6,7,8,9,10, ... (not always)
From my investigation the issue caused by
- <NetworkStream>.WriteAsync(packet, 0, packet.Length).ConfigureAwait(false) on client
or - <Tcp.Received>.Data.ToArray() on server (akka)
I have a repro project and will send to anyone who volunteers for investigation :)
@HIPERCUBE I've also captured traffic it shows that client sent 10 messages and got 22 in the reply https://drive.google.com/open?id=1KYSKINzPWPoyUuK5BWHR8PeXQPg7Z-iz
remark: this is a localhost
Phobos is a monitoring and tracing integration for Akka.Net build by @Aaronontheweb
the JVM has the advantage of using AOP like things to weave that stuff into your actors. .NET does not has that advantage
akka {
stdout-loglevel = DEBUG
loglevel = DEBUG
loggers=["Akka.Logger.Serilog.SerilogLogger, Akka.Logger.Serilog"]
log-config-on-start = on
actor {
provider = "cluster"
}
remote {
dot-netty.tcp {
hostname = "127.0.0.1"
port = 8081
maximum-frame-size = 256000b
}
}
cluster {
seed-nodes = ["akka.tcp://tradex@127.0.0.1:4053"] # address of seed node
roles = ["ordersync", "logger"] # roles this member is in
role.["ordersync"].min-nr-of-members = 3 # crawler role minimum node count
# auto downing is NOT safe for production deployments.
# you may want to use it during development, read more about it in the docs.
#
# auto-down-unreachable-after = 10s
}}
Would this be of any interest to anyone for akka.net contrib? https://doc.akka.io/docs/akka/2.5.9/actor-discovery-typed.html
I have a WebApi app that is running in an Azure App Service and I was about to try to get it to communicate back and forth with a remote actor system running on a VM. However, I don't think I can open up a port on the App Service that the remote actor system can communicate with. If I understand correctly, attaching to a vnet will only give my WebApi app access to the things in the VNet, but not vice-versa. Do I need to move the webapp to an App Service Environment or is there a better way of accomplishing this?
heh, similar question to @mikebridge. I've been using remoting on Azure with WebApps (not ASE) since the end of September. Occasionally messages were not received back from the VM, but VM always got them. In general, WebApp restart seemed to be the way to address it. Recently it's been happening more frequently. Not sure if it has anything to do with an upgrade to 4.7.2 and/or latest Akka+dependencies. I do use VNET. When I start WebApps first and then the windows service on the VM - everything is fine. It can last for days. Basically it seems to pair webapp -> VM and keeps it like that. However, when I restart the WebApp I see "connection was reset by peer" on the VM and then when WebApp is started and the message is sent then I see the debug text in the VM's service: attempt to associate WebApp -> VM, which seems to pass, then it receives the message, processes it and tries to reply. And this fails because at this moment VM's service tries to pair back to the WebApp and I get a warning that remote is not accessible and it is gated etc. etc. What's interesting is that it doesn't happen in the happy path start-up order, but does if WebApp is restarted (at least). BTW, happy path works well in the scale-out scenario too. Is there a way to configure VM's service to not try to pair back on connection resets? :) I understand that's against the peer-to-peer nature of Akka where both endpoints should be reachable... However, ASE is not an option and given that it already works half-way... maybe there's some tweak? :) Or is this trully the case (as per docs) for a custom low-level Akka I/O approach? @Horusiath, @Aaronontheweb what do you guys think?
@mikebridge In my particular case my webapp's communication with the remote actorsystem is only ever one-way. My best guess is that a better solution is to get rid of Akka.Net in WebApi and rewrite the remote actor system as a Rest API that uses Akka.Net internally. ASE looks like overkill for this system, and redeploying in a VM isn't difficult but seems like a hassle just to open a port in WebApi that isn't receiving any messages anyway. (It would be too bad, because the remote actor works great in all my internal deployment scenarios.)
If we want to implement Akka.Monitoring AND establish tenant/user context AND do some authorisation checks based on message header, what's a good way to do it without multiple inheritance and traits, and with much of these infrastructural needs requiring access to lifecycle overrides of the Actor. I'm thinking of a ReceiveActor derived class (e.g. AspectReceiveActor) that provides extension points to an ordered list of "aspects" to be executed AroundXYZ. The aspect list is populated by the derived class of AspectReceiveActor in its constructor. Any other better ideas?
(and yeah, the port part too)
@Havret I don't see quarantine related messages in the console output, only gating for 5s and disassociation due to VM being unable to reach the WebApp. After 5 second WebApp can send another mesage and it will be received and processed, but reply will fail and this behaviour seems to remain until I restart the VM service. In this case association is created from WebApp -> VM. And VM's Akka doens't seem to require to associate back. However, if I restart the WebApp and VM's service sees it (via connection was reset by peer info log message) and try to reconnect, then it associates WebApp -> VM successfully, but at this moment VM's service Akka decides to also associate from itself back to WebApp and this fails which causes disassociation and 5s gating
@OnurGumus yes, you can use
IActorRef<obj>, but then you'll catch any obj matching signature, including system messages sent to an actor. There's no easy way to just filter them out. Once I'll be done with porting akka-typed, then this will be much easier and consistent to do.
hi, Why does the IPersistenceIdsQuery.PersistenceIds() not provide any filtering or offset logic? I cant find any other method to resume a query, beside the method with the EventsByTag + Offset. Is the regular why realy to save every LastSeqNr for each PeristenceId in a projection?