there's stuff inside the behavior stack still being initialized when the actor instance is being constructed
initializing or ready
Initializing is called and then it calls ready.
and so
ReceiveAny misses a message?
Here's the console output...
2016-04-04 18:10:16.6303|INFO|EY.SSA.ActorSystemBridge.Program|Starting SSA Actor System at HTTP Client Bridge at:CF_IHadad
[DEBUG][4/4/2016 10:10:16 PM][Thread 0008][EventStream] StandardOutLogger started
[INFO][4/4/2016 10:10:16 PM][Thread 0015][[akka://SSAActorSystem/system/log1-NLogLogger]] NLogLogger started
[DEBUG][4/4/2016 10:10:16 PM][Thread 0008][EventStream(SSAActorSystem)] Logger log1-NLogLogger [NLogLogger] started
[DEBUG][4/4/2016 10:10:16 PM][Thread 0008][EventStream(SSAActorSystem)] StandardOutLogger being removed
2016-04-04 18:10:16.9651|INFO|EY.SSA.ActorSystemBridge.Program|Started SSA Actor System at HTTP Client Bridge at:CF_IHadad
2016-04-04 18:10:36.2219|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|Actor HTTPClientBridgeActor is initializing.
2016-04-04 18:10:38.6722|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|Actor HTTPClientBridgeActor is Initialized, moving to Ready state.
2016-04-04 18:10:38.6922|INFO|EY.SSA.ActorSystemBridge.Program|HTTP Server running on http://localhost:8080
2016-04-04 18:10:38.7037|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|Actor HTTPClientBridgeActor is getting Ready.
Enter a command:
2016-04-04 18:10:38.7197|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|Actor HTTPClientBridgeActor is Ready.
2016-04-04 18:10:49.7208|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|HTTPClientBridgeActor Got unhandled message From:akka://all-systems/
2016-04-04 18:10:49.7354|DEBUG|EY.SSA.CommonBusinessLogic.Actors.HTTPClientBridgeActor|HTTPClientBridgeActor Got unhandled message From:akka://all-systems/
Yep. it is as if the actor never received it.
because that's your own debug message showing up
I see that.
wierd.
just to test?
give it a try
not sure what our test coverage is for that
It sounds like it preferred the first become over the second one.
It's a good thing I was not consistent in my logging messages :smile:
Thanks so much. We've been scratching our heads for a bit here.
I have to actor system remotely associated, and if I make one of them crash, the other detect actor death in > ~30s after detect endpoint dissociation.
Is there any way for me to make it detect in a fewer delay?
(please read following log time stamp)
Is there any way for me to make it detect in a fewer delay?
(please read following log time stamp)
2016/04/05 07:22:43.637 109 ERROR Akka.Actor.OneForOneStrategy Disassociated Akka.Remote.EndpointDisassociatedException: Disassociated
2016/04/05 07:22:43.637 109 WARN Akka.Remote.ReliableDeliverySupervisor Association with remote system akka.tcp://rcsLocalSystem@203.239.173.241:17001 has failed; address is now gated for 5000 ms. Reason is: [Akka.Remote.EndpointDisassociatedException: Disassociated
2016/04/05 07:23:06.917 159 WARN Akka.Remote.RemoteWatcher Detected unreachable: [akka.tcp://rcsLocalSystem@203.239.173.241:17001]
2016/04/05 07:23:06.917 159 WARN Akka.Event.DummyClassForStringSources Association to [akka.tcp://rcsLocalSystem@203.239.173.241:17001] having UID [1302300886] is irrecoverably failed. UID is now quarantined and all messages to this UID will be delivered to dead letters. Remote actorsystem must be restarted to recover from this situation.
you can turn that heartbeat pause way down
or swap out the failure detector implementation with something simpler like a deadline failure detector
which the transport failure detector (immediately previous node in the configuration) does
I personally don't like the
PhiAccrualFailureDetector - it's meant to be adaptive based around latency
but I think it's one of those things that sounds great in theory but just makes your system more difficult to debug
DeadlineFailureDetector is pretty clear
@Aaronontheweb thanks. wow. You do not like that default failure detector. you know what, any guys like me who've started using Akka.net, the comments in the default Remote.conf is very 'reference' material or something, and it makes me feel that PhiAccrualFailureDetector is something guru's guidance(it even contains the reference paper link!). :smile:
Anyway I'll try that detector. Thanks.
Anyway I'll try that detector. Thanks.
configuration and before transport failure detection, remote watch recognized the unplugged remote actor system works as I want.
hmm... If I do this at home, I could put a fork up... >_>
question: A want to use advantages of App.Config transformation with HOCON let's say that I want to have different
persistence.journal.postgresql.connection-string in App.Debug.Config and App.Release.Config. Right now I came only to storing connection string in appSetting section and then using it by doing withFallback programmatically during startup, is there is a better way to achieve that?
I thought about several Akka.Configuration.Hocon.AkkaConfigurationSection one for general stuff (actors config, deployment stuff and so on ) and one variable part: something like:
cluster {
log-info = off
seed-nodes = ["akka.tcp://cluster-system@127.0.0.1:4052"]
seed-node-timeout = 10s
roles = ["api"]
}And then apply generalConfig.WithFallback(clusterConfig).WithFallback(persistenceConfig) it should works but also looks weird as for me