These are chat archives for akkadotnet/akka.net

8th
Feb 2016
y-vasilyev
@y-vasilyev
Feb 08 2016 09:01
Hi, folks! How-to set delivery timeout when using AtLeastOnceDeliveryActor?
Actor re-send message when child actor processing same message
Yin Zhang
@melcloud
Feb 08 2016 09:15
@y-vasilyev that is the point of at least once delivery. You receive actor needs to handle multiple messages without side effect
@y-vasilyev you can increase the redelivery interval, if you want to contain number of messages you received, but this doesn't change the idempotency of receive actor
voltcode
@voltcode
Feb 08 2016 09:20

synchronization question - I have an actor in a ASP.NET app that needs to resolve a singleton that's bound via IoC to session lifetime. Then it needs to call a method on that singleton.

There are other user actions that may affect the singleton so I need to ensure that no race conditions occur - either by locking or by ensuring proper thread synchronization. Is there a way for an actor to call a method on ASP.NET thread that's dedicated to serve a particular user?

Would SynchronizedDispatcher work with ASP.NET out of the box, as it does for winforms (I've used in akka bootcamp but not sure if it works with ASP.NET)?

If not is locking the only way to synchronize the calls? I can't change entire logic to actors, but am wondering if an actor waits on a lock, won't it spoil the actor system somehow?

Bartosz Sypytkowski
@Horusiath
Feb 08 2016 09:27
@y-vasilyev akka.persistence.at-least-once-delivery.redeliver-interval setting, by default it's 5s. Also remember that message sender is responsible for confirming in order to stop redelivering.
Christian Sparre
@christiansparre
Feb 08 2016 10:29
So I just experience ActorSystem.Create just blocking the thread. The aparent cause was a mismatch between Newtonsoft.Json versions. This is a library that has Akka 1.0.6 and Newtonsoft.Json 8.0.2 the library was called from a WPF app that has newtonsoft.json 7.0.1. This caused it to blow up as expected when the library tried to use Newtonsoft.Json. I then added binding redirects and then the ActorSystem.Create would hang. I then downgraded the library reference to 7.0.1 and then it worked. Any idea why ActorSystem.Create would hang?
y-vasilyev
@y-vasilyev
Feb 08 2016 10:54
@melcloud @Horusiath Thanks a lot!
voltcode
@voltcode
Feb 08 2016 12:29
@christiansparre I had some problems with mismatching newtonsoft libs (albeit not with WPF), after upgrading everything to be in line with Akka 1.0.6 on all cluster elements everything worked fine (Newtonsoft 8.0.2).
Christian Sparre
@christiansparre
Feb 08 2016 12:39
@voltcode thanks, then it's not just me :)
voltcode
@voltcode
Feb 08 2016 12:42
@christiansparre I suggest upgrading not downgrading though
Christian Sparre
@christiansparre
Feb 08 2016 12:44
Agree but was testing something and to be honest we have a mess of dependencies that all use different versions of Newtonsoft.Json :)
Zetanova
@Zetanova
Feb 08 2016 12:46
yes, discovered it 1-2monath ago
Eugéne Suter
@easuter
Feb 08 2016 13:18
@rogeralsing : yep, right on the money, thanks!
Marc Piechura
@marcpiechura
Feb 08 2016 13:21
@voltcode @christiansparre you could use Wire instead of Newtonsoft that would maybe fix the problems
Wire will be replace Newtonsoft in the feature
voltcode
@voltcode
Feb 08 2016 13:37

@Aaronontheweb remember #1670? I now have a smaller case - start WCFService first, windows service second. Restart WCFService - it won't be able to rejoin the cluster, I see multiple disassociations and "Member is UP" messages but no connection:

2016-02-08 14:35:53,674 [8] INFO Fabric - Leader is moving node [akka.tcp://actorsystem@localhost:7001] to [Up]
2016-02-08 14:35:54,674 [8] INFO Fabric - Leader is moving node [akka.tcp://actorsystem@localhost:7001] to [Up]
2016-02-08 14:35:55,684 [8] INFO Fabric - Leader is moving node [akka.tcp://actorsystem@localhost:7001] to [Up]
2016-02-08 14:35:56,684 [6] INFO Fabric - Leader is moving node [akka.tcp://actorsystem@localhost:7001] to [Up]
2016-02-08 14:35:57,694 [8] INFO Fabric - Leader is moving node [akka.tcp://actorsystem@localhost:7001] to [Up]

intertwined with disassociation errors. After a while "Up" messages stop and only disassociations exceptions are thrown every 5 sec

I am using static ports all the time, WCF should be recognized but isnt
Previously I used a custom cluster listener that was downing the nodes on unreachable as suggested by @cgstevens. However after your recent response on rejoining, i decided to try again without that. Manual downing has other problems, in non seed nodes I would need to add manual rejoin in several cases. Sort of defeats the purpose of the cluster if it cant heal itself
Garrard Kitchen
@garrardkitchen
Feb 08 2016 13:40
@Horusiath Thank you
voltcode
@voltcode
Feb 08 2016 13:55
@Aaronontheweb if I had a sample on github, would you be willing to have a look?
Weston
@ronnyek
Feb 08 2016 14:40
hey hey hey.... its faaaat albert
alexgoeman
@alexgoeman
Feb 08 2016 16:19
Question related to Persistence: Is there a reason that the Persist methods are not returning a Task ( not async ) ? Now I cannot await on it. I have some "Command" handler in which there are multiple execution flows and generating in several spots some events, but by not being able to use async/await this seems to become complex. Does this imply I am doing something wrong (semantically, technically,...)
Aaron Stannard
@Aaronontheweb
Feb 08 2016 17:42
@garrardkitchen you also need to call Cluster.Leave on the node that is leaving
which will send a signal that a planned termination is occurring and to remove this node from the cluster
you should then wait to get a ClusterEvent.MemberRemoved message before shutting down the actor system
@voltcode I've explained why this is before but I'll reiterate here
Manual downing has other problems, in non seed nodes I would need to add manual rejoin in several cases. Sort of defeats the purpose of the cluster if it cant heal itself
Automatic downing has its own class of issues
namely: computers are usually worse at classifying network failures and dealing with them correctly than humans
unless you have some sort of API that can tell you with a degree of certainty that a node is permanently down
i.e. a status API from a cloud provider or something like that
then it's difficult to do correctly - there are some strategies in place that Typesafe recently added to the proprietary version of Akka (Reactive Platform) that use a variety of academically approved strategies for dealing with failures in a way that doesn't require human intervention
such as minimum quorum size and that sort of thing
Bartosz Sypytkowski
@Horusiath
Feb 08 2016 17:47
@alexgoeman in general akka rarely relies on async/await, making async pauses more explicit and relying on finite state machines. Can you describe your case? Maybe we can suggest something useful
Aaron Stannard
@Aaronontheweb
Feb 08 2016 17:47
and that stuff operates off of probabilistic model - that it will usually but not always do the right thing
that being said, your logs - if the member is being moved to Up then there's a connection
but if it disassociates immediately between all of those messages then that's a problem
for now, other than troubleshooting some sort of configuration issue, sit tight until we can get a patch out for the transport layer
we're working on it
Garrard Kitchen
@garrardkitchen
Feb 08 2016 18:22
@Aaronontheweb Thank you!
voltcode
@voltcode
Feb 08 2016 19:00
@Aaronontheweb thanks for reiterating. My use case is that all cluster members sit on the same machine, ie. i don't have network partitions, but am interested in cluster self-healing when an IIS app pool or a service is restarted. At the moment I don't know much about Akka internals yet, logs don't really say much to me and I'm not sure if transport layer changes can fix this issue on localhost. I hope to isolate this case to a minimal setup and share it.
and perhaps you could share your thoughts on my previous synchronization question @Aaronontheweb ? :)
Bartosz Sypytkowski
@Horusiath
Feb 08 2016 19:08
@voltcode why are you keeping multiple actor systems on the same machine?
voltcode
@voltcode
Feb 08 2016 19:14
@Horusiath it's a cluster, actor system name is the same in all processes
Bartosz Sypytkowski
@Horusiath
Feb 08 2016 19:15
ok, but why? :)
voltcode
@voltcode
Feb 08 2016 19:17
@Horusiath depending on deployment scenario some of them can be deployed on separate machines. However our typical on-premises scenario involves installing all components on the same machine. I need a async communication layer for pub sub between those components
I also need to hook it into existing web apps code without rewriting entire app to be actor based
Bartosz Sypytkowski
@Horusiath
Feb 08 2016 19:19
so in case of running on a single machine you could set auto-downing
voltcode
@voltcode
Feb 08 2016 19:22
I'll check again tomorrow, but as far as I remember my last experiment with auto down went worse than manual down on cluster unreachable event.
I'm testing in dev by killing the processes, not by actually recycling the app pool, so Cluster.Leave doesnt get called.
voltcode
@voltcode
Feb 08 2016 20:09
Ok thanks @Aaronontheweb . I mainly need to guarantee that if one app pool is res
Aaron Stannard
@Aaronontheweb
Feb 08 2016 20:20
sure thing @voltcode - about to head out to drive to a meeting but I'll get you an answer to your question
Yin Zhang
@melcloud
Feb 08 2016 21:41
Hi guys. Is there any changes in the 1.4.2 version of Helios? I got a client actor which sends to a server actor through remote. If I killed the server actor, client keeps trying to send message in 1.4.1, and as soon as server actor went online, it can successfully process the incoming message. However, in 1.4.2. version of Helios, it no longer works.
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:42
+#### 1.4.2 Dec 12 2015
+Bugfixed - fixed an issue with NoOpDecoder where it wouldn't properly drain incoming IByteBuffer instances.
that's the bugfix in 1.4.2
doesn't affect Akka.Remote at all
since we don't use the NoOpDecoder
Yin Zhang
@melcloud
Feb 08 2016 21:43
@Aaronontheweb So why it stops performming any work?
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:43
are you getting any exceptions or anything else?
Yin Zhang
@melcloud
Feb 08 2016 21:43
@Aaronontheweb I downgraded to 1.4.1, and everything worked as expected...
@Aaronontheweb I cannot see anything in the client console. In fact, I try to log unhandled message, and there is none in 1.4.2, but 1.4.1 log it as expected
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:44
that is really weird
because we literally didn't change anything in the network stack for Helios that affects Akka.Remote
that bug fix was for people using Helios stand-alone
im trying to think why that might be
this other change was added there too helios-io/helios@912ce7e
which added notifications when BeginConnect fails
we changed that behavior to a no-throw
used to throw before
so maybe that's happening
Yin Zhang
@melcloud
Feb 08 2016 21:48
@Aaronontheweb So when there is a socketException, we no longer propgate the error back?
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:48
we're supposed to
but it happens in an event handler now
I may not be handling it in the right place inside Akka.Remote
Yin Zhang
@melcloud
Feb 08 2016 21:48
@Aaronontheweb That maybe the reason why. I
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:48
could you log a bug for this? I'll move it to the front of my queue - and for now stay downgraded to Helios 1.4.1
Yin Zhang
@melcloud
Feb 08 2016 21:49
sure, no problem
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:49
issue here is I probably screwed up adding this to the Akka.Remote handlers
the exception might have "covered up" the bug before
and making the method no longer throw may have exposed it :p
Yin Zhang
@melcloud
Feb 08 2016 21:49
@Aaronontheweb I will create a issue under helios, and attached some logs. thank you :smile:
@Aaronontheweb Love it!
Aaron Stannard
@Aaronontheweb
Feb 08 2016 21:50
thanks Yin
Yin Zhang
@melcloud
Feb 08 2016 21:50
No problem
Yin Zhang
@melcloud
Feb 08 2016 22:40
@Aaronontheweb done. helios-io/helios#68. Thanks for your help. It is not something urgent, as I can stay use 1.4.1. :smile:
John Nicholas
@MrTortoise
Feb 08 2016 23:59
what is src\core\Akka.API.Tests\CoreAPISpec.ApproveCore.approved.txt?