These are chat archives for akkadotnet/akka.net

11th
Nov 2015
Hyungho Ko
@hhko
Nov 11 2015 02:56
Can I have wordcount sample by Akka.NET?
Esun Kim
@veblush
Nov 11 2015 07:14
Hello! I want to appreciate you guys' great job :)
With integration with DotNetty, is there any change to support message ordering for a given pair of actors ?
Without ordering, it's really hard to give location transparency to actors because they may need to know target actor is located locally or not.
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 07:57
@veblush communication between two actors is always ordered, no matter if they're connected remotely or not
Kelly
@kcliffe
Nov 11 2015 08:30

Hi all, noob question if anybody can help.

I have this config:


var config = ConfigurationFactory.ParseString(@"
akka {  
  actor {
    deployment {
       /workers {
          router = round-robin-group
          routees.paths = [""user/conductor/default/w1""]
       }
    }
  }
}");

The following code (inside a ReceiveActor):

var props = Props.Create<WorkerActor>().WithRouter(FromConfig.Instance);
var actor = Context.ActorOf(props, "workers");

produces:
Configuration problem while creating [akka://myActorSystem/user/conductor/default/workers] with router dispatcher [akka.actor.default-dispatcher] and mailbox and routee dispatcher [akka.actor.default-dispatcher] and mailbox [].

TIA

Bartosz Sypytkowski
@Horusiath
Nov 11 2015 09:04
@kelly-cliffe do you have any further exception message?
also do you have actor under routees.path really created? group routers doesn't manage routees creation by themselfs AFAIK
Kelly
@kcliffe
Nov 11 2015 09:08
Hi there... unfortunately no. I should mention (in case it matters - it shoudn't), I'm running on Mono under Ubuntu.
I did try creating the actors (as is done in the Routing sample) and it made no difference. Might have to download the source and try debugging this...
mph911
@mph911
Nov 11 2015 09:34
Hi folks,
HI there again, I wonder if there is way to inject for example a string in to an FSM actor upon creation or any actor. Or is there any restritino to that due to the lack or a parameterless contstructor since the injected data is madatory for the configuration of the actor.
And also I'm wondering if a FSM actor should have childs or rather not.
Any thoughts on those thwo question are welcome.
Cheers
Esun Kim
@veblush
Nov 11 2015 14:15
@Horusiath Thanks for answer. From akka manual ordering between two actors should be guaranteed for both local and remote. But from akka.net i'm not sure about that. Check this source please (https://gist.github.com/veblush/404875f2bda981c2187f)
Zetanova
@Zetanova
Nov 11 2015 14:21
@mph911
´´´
public override Props GetProps(Guid id)
{
return Props.Create(() => new Account(id) { Name = "Test1" });
}
´´´
Esun Kim
@veblush
Nov 11 2015 14:21
You can build it with "install-package akka.cluster -pre" easily. This program creates two actors. First one is a sender and the other one is a receiver. A sender sends sequential numbers to a receiver actor. If message ordering is guaranteed, receiver should get monotonically increasing numbers. But receiver didn't get those numbers.
Because of this test and akka.net document separating local and remote case for ordering (http://getakka.net/docs/concepts/message-delivery-reliability) I understood that akka.net doesn't provide network message ordering.
Zetanova
@Zetanova
Nov 11 2015 14:26
@veblush I think its the PreStart u need to tell the sender some start-message
Esun Kim
@veblush
Nov 11 2015 14:28
@Zetanova Hi. I assume that you think a receiver did not get any number from sender. But it got all numbers but not sequential (like 1, 3, 2, 4, 5, ...)
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 14:35
@veblush I've run your gist around 10 times and every time I've got sequential ordering
mph911
@mph911
Nov 11 2015 14:35
@Zetanova Got it. Thank you mate!
Roger Johansson
@rogeralsing
Nov 11 2015 14:52
@veblush it should guarantee ordering, however, due to a bug in Helios the guarantee is not enforced, aprox 1 out of 50 000- 100 000 messages gets received out of order. and that is a bug, this should be fixed in later versions of Helios though. and the upcoming DotNetty transport should also guarantee this
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 14:53
what about akka.io transport?
Christian Duhard
@cduhard
Nov 11 2015 14:56
is there any info on DotNetty vs Helios?
Roger Johansson
@rogeralsing
Nov 11 2015 14:57
@Horusiath I havent verified how akka.io transport behaves but I'd expect it to obey the guarantee as there are no bugs reported yet
Christian Duhard
@cduhard
Nov 11 2015 15:01
is akka.io another transport type like Helios?
Roger Johansson
@rogeralsing
Nov 11 2015 15:09
yes
Christian Duhard
@cduhard
Nov 11 2015 15:10
is it related to streams?
Roger Johansson
@rogeralsing
Nov 11 2015 15:10
no, it is new (but largely un-tested), it is based on the built in Akka.IO network layer
Akka.IO is the actor based network support built into Akka.NET, and there is a akka remote transport built ontop of that
Christian Duhard
@cduhard
Nov 11 2015 15:11
what will DotNetty offer over Helios?
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 15:46
@cduhard it's probably faster, easier to extend and will support tls/ssl
Christian Duhard
@cduhard
Nov 11 2015 15:47
cool, where do streams fit into all this?
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 15:49
akka streams is higher level abstraction over actor model, which allow to build your application logic from data flows or graphs rather than particular actors
Christian Duhard
@cduhard
Nov 11 2015 15:51
i haven't finished reading that yet :)
I backed the kickstarter way back when
Weston
@ronnyek
Nov 11 2015 17:20
so what kind of fun things are people using akka.net for
real world stuff
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:22
@ronnyek use cases I've seen first hand: device / sensor-automation, fleet and vehicle tracking, marketing automation, real-time reporting, online gaming, traffic simulation
Weston
@ronnyek
Nov 11 2015 17:22
intersting
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:22
systems with soft real-time requirements
generally
the device / sensor automation stuff covers a wide range of things
Weston
@ronnyek
Nov 11 2015 17:22
yeah
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:23
the business cases are all different but the technical challenges are the same
Weston
@ronnyek
Nov 11 2015 17:23
with akka you can deploy new actors to existing already running servers can you not?
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:23
yes you can, but the server needs to know how to create those actors
i.e. the DLL that defines the actors needs to be present
Weston
@ronnyek
Nov 11 2015 17:30
could that be I have some process that gets the dll out there, and then tell framework to scan for types or should I just try to avoid the scenario of hot deploying aactors
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:31
hot-deploying actors is something that we want to eventually support
here's the rub with it
it's straightforward to do it once
like in a live code demo
but doing it multiple times for a system that's running in production is tremendously complicated
do we kill all of the actors created with a previous version of the DLL?
Weston
@ronnyek
Nov 11 2015 17:32
yeah I realize the implications
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:32
and in order to allow upgrades of a DLL that was previously hot-loaded, we have to run it in a separate AppDomain which we tear down
which requires a whole bunch of inter-domain communication all of the sudden
what'll have to happen if we allow hot-loading is it'll be designed for specific use cases
totally discouraged for perpetual use
Weston
@ronnyek
Nov 11 2015 17:33
yeah I've built systems that did just that
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:33
yeah, it could work for the right use case
we haven't talked much about what that is though
Weston
@ronnyek
Nov 11 2015 17:33
well can I do staged deploys or anything, to reduce impact of framework stopping and starting?
eg, not have a laborous deploy system
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:34
re-deploying Akka.NET systems is easy unless they're stateful
Weston
@ronnyek
Nov 11 2015 17:34
shut down all nodes, deploy dlls, start back up
Aaron Stannard
@Aaronontheweb
Nov 11 2015 17:34
which many Akka.NET systems are
stateful systems have to be updated like a database
one node at a time with partition hand-offs
can't be deployed like a web application
and that's unavoidable - you're literally killing a process that has information your application depends on in-memory when you do that
some of the modules being worked on like DData and Cluster.Sharding solve that through replication
Akka.Persistence resolves it through persisting to an external durable store
Weston
@ronnyek
Nov 11 2015 17:43
Im not talking about real existing problems
Kamil Wojciechowski
@aph5nt
Nov 11 2015 20:00
does any one know when new versionAkka.Persistance will be released?
views are not working because of this
Akka.Actor.IllegalActorStateException: Can't stash the same message Akka.Persistence.ScheduledUpdate more than once ("Can't stash the same message Akka.Persistence.ScheduledUpdate more than once")
at Akka.Actor.Internal.AbstractStash.Stash()
at Akka.Persistence.PersistentView+<>cDisplayClass2.<RecoveryStarted>b1(Akka.Actor.Receive, System.Object)
at Akka.Persistence.PersistentView.AroundReceive(Akka.Actor.Receive, System.Object)
at Akka.Actor.ActorCell.ReceiveMessage(System.Object)
at Akka.Actor.ActorCell.Invoke(Akka.Actor.Envelope)
at Akka.Dispatch.MessageDispatcher.Dispatch(Akka.Actor.ActorCell, Akka.Actor.Envelope)
at Akka.Dispatch.ConcurrentQueueMailbox+<>cDisplayClass1.<Run>b0()
at Akka.Actor.ActorCell.UseThreadContext(System.Action)
at Akka.Dispatch.ConcurrentQueueMailbox.Run()
at Akka.Dispatch.ThreadPoolDispatcher+<>cDisplayClass1.<Schedule>b0(System.Object)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
Aaron Stannard
@Aaronontheweb
Nov 11 2015 20:00
@aph5nt we're going to try to do a new 1.0.5 release in the next 1-2 weeks
Kamil Wojciechowski
@aph5nt
Nov 11 2015 20:00
and the existing bug fix for stashing messages did not help
@Aaronontheweb ok, thx
Aaron Stannard
@Aaronontheweb
Nov 11 2015 20:01
@aph5nt yeah there's another open issue forthat
doesn't work for instances when you literally send the same message instance multiple times
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 20:08
@aph5nt you may want to track this issue #1400
This message was deleted
Aaron Stannard
@Aaronontheweb
Nov 11 2015 20:09
agree
the envelope gets stashed IIRC
but the algorithm for duplicate checking misses a bunch of real edge cases
wonder if it's not a bad idea for envelopes to be assigned monotonic UIDs or something like that
at the level of the ActorCell / Mailbox
within the internal boundary of a single "actor"
Bartosz Sypytkowski
@Horusiath
Nov 11 2015 20:12
if I'm right the problem is that envelopes are structs not classes, and therefore cannot be ref equal asserted
but they can have custom equality operator
Ryan J. Shaw
@ryanjshaw
Nov 11 2015 20:12
with clustering, howcome I can't do Context.ActorSelection("/user/some_actor_on_different_node").Tell(new Message())
Kamil Wojciechowski
@aph5nt
Nov 11 2015 20:12
@Horusiath thx
Ryan J. Shaw
@ryanjshaw
Nov 11 2015 20:13
using a ClusterRouterGroup it is possible to discover remote actors in the cluster -- should I just always create a ClusterRouterGroup even if I know it's just one node that qualifies?
sorry I meant Context.System -- I suppose what I'm asking is, what's the simplest way to get node A and B (and C and D...) talking to each other without having to store a list of ports?