Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 20:47
    IgorFedchenko commented #4085
  • 20:46
    IgorFedchenko commented #4085
  • 15:09
    IgorFedchenko commented #4085
  • 11:24
    Kenji-Tanaka commented #3887
  • 10:45
    nagytech edited #4086
  • 10:45
    nagytech synchronize #4086
  • 10:43
    nagytech opened #4086
  • 09:00
    Horusiath commented #4077
  • 06:31
    Aaronontheweb commented #4085
  • 06:28
    Aaronontheweb commented #4085
  • 06:24
    Aaronontheweb commented #4085
  • Dec 07 11:49
    IgorFedchenko commented #4085
  • Dec 07 10:31
    IgorFedchenko commented #4085
  • Dec 07 08:36
    IgorFedchenko commented #4085
  • Dec 06 20:57
    IgorFedchenko commented #4085
  • Dec 06 20:32
    IgorFedchenko commented #4085
  • Dec 06 20:01
    IgorFedchenko commented #4085
  • Dec 06 19:55
    IgorFedchenko commented #4085
  • Dec 06 16:22
    Aaronontheweb labeled #3997
  • Dec 06 16:22
    Aaronontheweb closed #3997
Aaron Stannard
@Aaronontheweb
we had an issue logged about that somewhere
but in general - don't call Become for behavior #1
only call it when switching from one active behavior to another
there's stuff inside the behavior stack still being initialized when the actor instance is being constructed
ilhadad
@ilhadad
It seemed to call the Initializing method.
Aaron Stannard
@Aaronontheweb
so what behavior is the actor in when the issue occurs?
initializing or ready
ilhadad
@ilhadad
Ready
Initializing is called and then it calls ready.
Aaron Stannard
@Aaronontheweb
we might have fixed the Become in the constructor bug then
and so ReceiveAny misses a message?
ilhadad
@ilhadad
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.
Aaron Stannard
@Aaronontheweb
ok, so it looks like the Receive<object> you set in the `Initialzing state is still there
because that's your own debug message showing up
ilhadad
@ilhadad
Oh yeah
I see that.
wierd.
Aaron Stannard
@Aaronontheweb
I'm wondering if this did something funny to the first behavior
ilhadad
@ilhadad
So should I just call Initializing from the constructor?
just to test?
Aaron Stannard
@Aaronontheweb
like it basically did INITIALIZING + READY --> your behaviuor
give it a try
ilhadad
@ilhadad
ok
Aaron Stannard
@Aaronontheweb
calling Become twice is essentially what's happening here
not sure what our test coverage is for that
ilhadad
@ilhadad
That was it!!!!
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.
Aaron Stannard
@Aaronontheweb
filed #1849 for you @ilhadad
joonhwan
@joonhwan
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)
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
joonhwan
@joonhwan
@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.
joonhwan
@joonhwan
@Aaronontheweb It worked. now I have
```
akka {
remote {
watch-failure-detector {
implementation-class = ""Akka.Remote.DeadlineFailureDetector,Akka.Remote""
acceptable-heartbeat-pause = 5 s
}
}
}
configuration and before transport failure detection, remote watch recognized the unplugged remote actor system works as I want.
to11mtm
@to11mtm
@Horusiath : Thanks, I didn't notice that one before!
hmm... If I do this at home, I could put a fork up... >_>
Kris Schepers
@schepersk
@Horusiath did you have time to get around reproducing the issue in my sample?
Bartosz Sypytkowski
@Horusiath
@schepersk yes, I think I'm able to reproduce it, however I need to check it against current dev branch (I think we may had this issue already fixed, just not released yet)
Kris Schepers
@schepersk
@Horusiath owkay, thanks! Keep me in the loop please.. Otherwise I'll have to come up with plan B :smile:
Pavel Knorr
@knorrus
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?
Kris Schepers
@schepersk
@knorrus Good question, I would also like to see what the specialists have to say about this. For the moment I'm copying the whole akka section in every transform file, applying the changes for that environment and using the xdt:Transform="Replace" as transform option.
Pavel Knorr
@knorrus
@schepersk I see, but for me it look weird to copy ~200 rows of HOCON to change persistence.journal.postgresql.connection-string and remote.helios.tcp