Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 14 21:02
    Aaronontheweb synchronize #3975
  • Oct 14 21:02
    Aaronontheweb opened #3975
  • Oct 14 20:11
    IgorFedchenko commented #3973
  • Oct 14 20:10
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 19:42
    IgorFedchenko edited #3973
  • Oct 14 18:08
    Aaronontheweb commented #3937
  • Oct 14 17:27
    Aaronontheweb commented #90
  • Oct 14 17:26
    Aaronontheweb commented #90
  • Oct 14 17:25
    Aaronontheweb assigned #90
  • Oct 14 17:16

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • Oct 14 17:16
    Aaronontheweb closed #3974
  • Oct 14 17:16
    Aaronontheweb milestoned #3974
  • Oct 14 16:05
    jackowild opened #90
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
Голодный Монстр
@Kalinin_Aleks_twitter
So I should do subscribe to DisassociatedEvent
Arjen Smits
@Danthar
The log shows the fact that you Disassociated. Internally this is communicated via the EndpointDisassociatedException exception. My guess is that you are getting this on the sender side ?
Thickar
@Thickar
Hi there, I want to connect an SQLDateReader object as source Enum for Akka streams source, but i cant figure out how! could any one help?
Ralf
@Ralf1108
is it possible to check if there are messages in the stash?
Maxim Cherednik
@maxcherednik
why do you want to do this? :)
Ralf
@Ralf1108
because i am a little confused :D
i have an actor... which gets a message. the actor is changing state and start processing stuff. because the original message can not be answered yet I stash it
when the processing is finished then all messages are unstashed and actor switches back to orginal state
now the original message can be answered
this works
but i also added passivation to the actor
so if the passivate message arrives during processing .. the passivate message will be handled and actor is shutdown
the orginal sender wont get a nice repsonse.. but instead could deathwatch the actor :-(
so if i could check if there are currently stashed messages i would also stash the passivate message... that should work
does this makes sense?
i could keep track of stashed messages count by myself. wondered if the count or "not empty stash" could be checked
maybe using reflection :P
Maxim Cherednik
@maxcherednik
just thinking what I would do
what is this passivation message? what do you mean by this?
Arjen Smits
@Danthar
Its a pattern
Ralf
@Ralf1108
yes, i implemented it like this.
parent sent passivate to child and stops forwarding messages to child
child stops it self when nothing doing anything else
parent gets informed via deathwatch
Arjen Smits
@Danthar
@Ralf1108 what you can do. Is once you receive the passivate message
unstash all messages, then send the passivate message to yourself again. Basically forward it. Because you also change the state of your actor (switching from processing to the other state).
You could have the passivate message be handled differently
so if your in processing and receive a passivate. Unstash and forward passivate message to yourself
then all stashed messages get handled
Ralf
@Ralf1108
i get the idea
Arjen Smits
@Danthar
:+1:
Ralf
@Ralf1108
i think it would be enough to just stash the passivate message when in the processing state
Arjen Smits
@Danthar
thats also possible.
Ralf
@Ralf1108
when processing is finished... unstash all moves original message first and then passivate message into mailbox
so normal workflow occurs
thx guys for helping out !!! :+1:
Arjen Smits
@Danthar
np
@maxcherednik passivate is a pattern used to reduce the amount of idle actors in your topology
imagine you have an actor per user in your system
and your routing messages to those user actors
you would have an coordinator as the parent of those user actors
which receives user messages and forwards them to the correct actor
then, depending on a strategy of your own making
for example a timeout
lets say that once a user actor has not seen a message in X amount of time
you want to stop it, so its state is unloaded from memory
the coordinator sends a passivate message to the user actor and starts buffering messages for that actor
actor stops, deathwatch notifies the coordinator
if the coordinator receives messages for that user again
it starts up the actor again