Remote client disconnection detection
202 views
Skip to first unread message
goldfreak
Oct 27, 2010, 10:06:54 AM10/27/10
to Akka User List
In the Akka tutorial, a chat server is demonstrated.
To logout, the client sends the Logout message. And then the
SessionManagement trait removes the client from the sessions.
However, if the client forgets to send the logout, or crashes before
sending the logout message, the session is never removed from the
list, leaking memory.
Is there a way to make this more fault tolerant? to detect when the
client disconnects
From the Remote Objects guide, it seems that I can subscribe to the
RemoteServer events and listen for:
case class RemoteServerClientConnected(server: RemoteServer) extends
RemoteClientLifeCycleEvent
case class RemoteServerClientDisconnected(server: RemoteServer)
extends RemoteClientLifeCycleEvent
but in those events I am not receiving the client so I can not tell
which one disconnected.
To logout, the client sends the Logout message. And then the
SessionManagement trait removes the client from the sessions.
However, if the client forgets to send the logout, or crashes before
sending the logout message, the session is never removed from the
list, leaking memory.
Is there a way to make this more fault tolerant? to detect when the
client disconnects
From the Remote Objects guide, it seems that I can subscribe to the
RemoteServer events and listen for:
case class RemoteServerClientConnected(server: RemoteServer) extends
RemoteClientLifeCycleEvent
case class RemoteServerClientDisconnected(server: RemoteServer)
extends RemoteClientLifeCycleEvent
but in those events I am not receiving the client so I can not tell
which one disconnected.
Jonas Bonér
Oct 27, 2010, 11:57:59 AM10/27/10
to akka...@googlegroups.com
That is a good point. Would be great to get the client info as part of the listener callback on disconnect.
--
Jonas Bonér
work: http://akkasource.org
code: http://github.com/jboner
blog: http://jonasboner.com
twtr: @jboner
Don't know if that is possible to get through Netty.
Open a ticket.
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--
Jonas Bonér
work: http://akkasource.org
code: http://github.com/jboner
blog: http://jonasboner.com
twtr: @jboner
Jonas Bonér
Oct 27, 2010, 4:30:01 PM10/27/10
to akka...@googlegroups.com
Thanks for the ticket. We'll try to get it done fast.
Jonas Bonér
Oct 31, 2010, 2:00:22 AM10/31/10
to akka...@googlegroups.com
Fixed in master now.
Here is the new API:
Here is the new API:
√iktor Klang
Oct 31, 2010, 6:25:29 AM10/31/10
to akka...@googlegroups.com
Ah, nice Jonas, I was thinking about how to solve that earlier, just piping out the address is a sensible choice.Viktor Klang,
Code Connoisseur
Work: www.akkasource.com
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Code Connoisseur
Work: www.akkasource.com
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Paul Pacheco
Oct 31, 2010, 8:16:13 AM10/31/10
to akka...@googlegroups.com
Thank you Jonas,
But I think there is still something missing. In the chat example, you identify the sessions by username, yet these messages give you the InetSocketAddress. This is might be me being an akka n00b, but it is not obvious how to link the two. When you receive a message, there needs to be a way to tell what InetSocketAddress the message came from. AFAIK, you have the sender object, but I don't know how to get the InetSocketAddress from the sender ActorRef. Otherwise, you still can not resolve the memory leak in the chat tutorial example.
On a somewhat related note, I think would it would be useful is if there was a way to associate objects with the session. In a web server, you can associate random objects with setAttribute on the HttpSession object. This would help you not having to maintain a singleton Map with data related to each session, and avoid unnecessary locking. So rather than passing the InetSocketAddress to the listener and the message handler, both of them could receive a "Session" object through which you could get the InetSocketAddress, as well as any user attribute.
√iktor Klang
Oct 31, 2010, 8:27:22 AM10/31/10
to akka...@googlegroups.com
If the channel is closed, all actors on that channel is unreachable.
Jonas Bonér
Oct 31, 2010, 8:28:57 AM10/31/10
to akka...@googlegroups.com
How would I know? When a client disconnects the only think I have is
the host and port.
You would have to build the application in the way that for example
the messages in which a client connects with contains its host and
port (which is to be found in the self.homeAddress field) and then you
need to do the mapping.
Also you do have both the connect and disconnect life-cycle events to
hook into to do the mapping.
What are your suggestion on what we could add to solve the problem in
an easier way?
the host and port.
You would have to build the application in the way that for example
the messages in which a client connects with contains its host and
port (which is to be found in the self.homeAddress field) and then you
need to do the mapping.
Also you do have both the connect and disconnect life-cycle events to
hook into to do the mapping.
What are your suggestion on what we could add to solve the problem in
an easier way?
Paul Pacheco
Oct 31, 2010, 8:47:43 AM10/31/10
to akka...@googlegroups.com
Could the sender object in this case be a TypedActor? I dont know if that can be done without breaking the rest of akka. But if it was that way, then the sender object could have methods like: "getClientAddress" and "getAttribute"
It would be up to the application to cast the server object to something like "RemoteSender" which would have these methods.
The same RemoteSender could be passed to the RemoteServerClientDisconnected and friends. This would also have the interesting feature of allowing the server to send something to the client without the client sending anything to the server.
This would also allow me to create an actor per session, and associate it with the session painlesly, and stopping it when the client disconnects.
goldfreak
Oct 31, 2010, 9:43:16 AM10/31/10
to Akka User List
Another idea is to have a third type of remote actor, a session bound
remote actor:
With this, instead of registering an actor, you would register a
function that creates an actor, for example:
RemoteServer.register("myactor", () => actorOf[MyActor] )
every time a client connects, this function would be called to create
an actor for that session, when the client disconnects, your actor
would be stopped. If you want to keep state for the session, you would
just keep it as attributes of your actor. If you want to do some
initialization/cleanup, you would use the init() and postStop
callbacks as usual. All messages from the clients would be forwarded
to the session actor.
This would work for both typed and untyped remote actors, and to the
clients it would look just like any other server managed remote actor.
Maybe, instead of registering a function, you could set up a
supervisor to manage the instances, but tie the actors to the
sessions.
This would be like client managed actors meet server managed actors,
where the lifecycle of the actors is tied to the session, yet the
server has control over what the clients can do.
On Oct 31, 7:47 am, Paul Pacheco <paulp...@gmail.com> wrote:
> Could the sender object in this case be a TypedActor? I dont know if that
> can be done without breaking the rest of akka. But if it was that way, then
> the sender object could have methods like: "getClientAddress" and
> "getAttribute"
>
> It would be up to the application to cast the server object to something
> like "RemoteSender" which would have these methods.
>
> The same RemoteSender could be passed to the RemoteServerClientDisconnected
> and friends. This would also have the interesting feature of allowing the
> server to send something to the client without the client sending anything
> to the server.
>
> This would also allow me to create an actor per session, and associate it
> with the session painlesly, and stopping it when the client disconnects.
>
>
>
>
>
>
>
> On Sun, Oct 31, 2010 at 7:28 AM, Jonas Bonér <jo...@jonasboner.com> wrote:
> > How would I know? When a client disconnects the only think I have is
> > the host and port.
> > You would have to build the application in the way that for example
> > the messages in which a client connects with contains its host and
> > port (which is to be found in the self.homeAddress field) and then you
> > need to do the mapping.
> > Also you do have both the connect and disconnect life-cycle events to
> > hook into to do the mapping.
> > What are your suggestion on what we could add to solve the problem in
> > an easier way?
>
> > >>> >>> akka-user+...@googlegroups.com<akka-user%2Bunsubscribe@googlegroups .com>
> > .
> > >>> akka-user+...@googlegroups.com<akka-user%2Bunsubscribe@googlegroups .com>
> > .
> > .
> > .
> > .
remote actor:
With this, instead of registering an actor, you would register a
function that creates an actor, for example:
RemoteServer.register("myactor", () => actorOf[MyActor] )
every time a client connects, this function would be called to create
an actor for that session, when the client disconnects, your actor
would be stopped. If you want to keep state for the session, you would
just keep it as attributes of your actor. If you want to do some
initialization/cleanup, you would use the init() and postStop
callbacks as usual. All messages from the clients would be forwarded
to the session actor.
This would work for both typed and untyped remote actors, and to the
clients it would look just like any other server managed remote actor.
Maybe, instead of registering a function, you could set up a
supervisor to manage the instances, but tie the actors to the
sessions.
This would be like client managed actors meet server managed actors,
where the lifecycle of the actors is tied to the session, yet the
server has control over what the clients can do.
On Oct 31, 7:47 am, Paul Pacheco <paulp...@gmail.com> wrote:
> Could the sender object in this case be a TypedActor? I dont know if that
> can be done without breaking the rest of akka. But if it was that way, then
> the sender object could have methods like: "getClientAddress" and
> "getAttribute"
>
> It would be up to the application to cast the server object to something
> like "RemoteSender" which would have these methods.
>
> The same RemoteSender could be passed to the RemoteServerClientDisconnected
> and friends. This would also have the interesting feature of allowing the
> server to send something to the client without the client sending anything
> to the server.
>
> This would also allow me to create an actor per session, and associate it
> with the session painlesly, and stopping it when the client disconnects.
>
>
>
>
>
>
>
> On Sun, Oct 31, 2010 at 7:28 AM, Jonas Bonér <jo...@jonasboner.com> wrote:
> > How would I know? When a client disconnects the only think I have is
> > the host and port.
> > You would have to build the application in the way that for example
> > the messages in which a client connects with contains its host and
> > port (which is to be found in the self.homeAddress field) and then you
> > need to do the mapping.
> > Also you do have both the connect and disconnect life-cycle events to
> > hook into to do the mapping.
> > What are your suggestion on what we could add to solve the problem in
> > an easier way?
>
> > On 31 October 2010 13:16, Paul Pacheco <paulp...@gmail.com> wrote:
> > > Thank you Jonas,
> > > But I think there is still something missing. In the chat example, you
> > > identify the sessions by username, yet these messages give you the
> > > InetSocketAddress. This is might be me being an akka n00b, but it is not
> > > obvious how to link the two. When you receive a message, there needs to
> > be a
> > > way to tell what InetSocketAddress the message came from. AFAIK, you have
> > > the sender object, but I don't know how to get the InetSocketAddress from
> > > the sender ActorRef. Otherwise, you still can not resolve the memory leak
> > in
> > > the chat tutorial example.
> > > On a somewhat related note, I think would it would be useful is if there
> > > was a way to associate objects with the session. In a web server, you can
> > > associate random objects with setAttribute on the HttpSession object.
> > This
> > > would help you not having to maintain a singleton Map with data related
> > to
> > > each session, and avoid unnecessary locking. So rather than passing the
> > > InetSocketAddress to the listener and the message handler, both of them
> > > could receive a "Session" object through which you could get the
> > > InetSocketAddress, as well as any user attribute.
>
> > > On Sun, Oct 31, 2010 at 5:25 AM, √iktor Klang <viktor.kl...@gmail.com>
> > > Thank you Jonas,
> > > But I think there is still something missing. In the chat example, you
> > > identify the sessions by username, yet these messages give you the
> > > InetSocketAddress. This is might be me being an akka n00b, but it is not
> > > obvious how to link the two. When you receive a message, there needs to
> > be a
> > > way to tell what InetSocketAddress the message came from. AFAIK, you have
> > > the sender object, but I don't know how to get the InetSocketAddress from
> > > the sender ActorRef. Otherwise, you still can not resolve the memory leak
> > in
> > > the chat tutorial example.
> > > On a somewhat related note, I think would it would be useful is if there
> > > was a way to associate objects with the session. In a web server, you can
> > > associate random objects with setAttribute on the HttpSession object.
> > This
> > > would help you not having to maintain a singleton Map with data related
> > to
> > > each session, and avoid unnecessary locking. So rather than passing the
> > > InetSocketAddress to the listener and the message handler, both of them
> > > could receive a "Session" object through which you could get the
> > > InetSocketAddress, as well as any user attribute.
>
> > > wrote:
>
> > >> Ah, nice Jonas, I was thinking about how to solve that earlier, just
> > >> piping out the address is a sensible choice.
>
> > >> On Sun, Oct 31, 2010 at 7:00 AM, Jonas Bonér <jo...@jonasboner.com>
> > wrote:
>
> > >>> Fixed in master now.
> > >>> Here is the new API:
>
> >http://doc.akkasource.org/remote-actors-scala#Remote%20Actors%20(Scal...
>
> > >> Ah, nice Jonas, I was thinking about how to solve that earlier, just
> > >> piping out the address is a sensible choice.
>
> > >> On Sun, Oct 31, 2010 at 7:00 AM, Jonas Bonér <jo...@jonasboner.com>
> > wrote:
>
> > >>> Fixed in master now.
> > >>> Here is the new API:
>
>
> > >>> On 27 October 2010 22:30, Jonas Bonér <jo...@jonasboner.com> wrote:
> > >>> > Thanks for the ticket. We'll try to get it done fast.
>
> > >>> > On 27 October 2010 17:57, Jonas Bonér <jo...@jonasboner.com> wrote:
> > >>> >> That is a good point. Would be great to get the client info as part
> > of
> > >>> >> the
> > >>> >> listener callback on disconnect.
> > >>> >> Don't know if that is possible to get through Netty.
> > >>> >> Open a ticket.
>
> > >>> On 27 October 2010 22:30, Jonas Bonér <jo...@jonasboner.com> wrote:
> > >>> > Thanks for the ticket. We'll try to get it done fast.
>
> > >>> > On 27 October 2010 17:57, Jonas Bonér <jo...@jonasboner.com> wrote:
> > >>> >> That is a good point. Would be great to get the client info as part
> > of
> > >>> >> the
> > >>> >> listener callback on disconnect.
> > >>> >> Don't know if that is possible to get through Netty.
> > >>> >> Open a ticket.
>
> > .
> > .
> > >>> For more options, visit this group at
> > >>>http://groups.google.com/group/akka-user?hl=en.
>
> > >> --
> > >> Viktor Klang,
> > >> Code Connoisseur
> > >> Work: www.akkasource.com
> > >> Code: github.com/viktorklang
> > >> Follow: twitter.com/viktorklang
> > >> Read: klangism.tumblr.com
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Akka User List" group.
> > >> To post to this group, send email to akka...@googlegroups.com.
> > >> To unsubscribe from this group, send email to
> > >> akka-user+...@googlegroups.com<akka-user%2Bunsubscribe@googlegroups .com>
> > >>>http://groups.google.com/group/akka-user?hl=en.
>
> > >> --
> > >> Viktor Klang,
> > >> Code Connoisseur
> > >> Work: www.akkasource.com
> > >> Code: github.com/viktorklang
> > >> Follow: twitter.com/viktorklang
> > >> Read: klangism.tumblr.com
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "Akka User List" group.
> > >> To post to this group, send email to akka...@googlegroups.com.
> > >> To unsubscribe from this group, send email to
> > .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/akka-user?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Akka User List" group.
> > > To post to this group, send email to akka...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > akka-user+...@googlegroups.com<akka-user%2Bunsubscribe@googlegroups .com>
> > >>http://groups.google.com/group/akka-user?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Akka User List" group.
> > > To post to this group, send email to akka...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/akka-user?hl=en.
>
> > --
> > Jonas Bonér
>
> > work:http://akkasource.org
> > code:http://github.com/jboner
> > blog: http://jonasboner.com
> > twtr: @jboner
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Akka User List" group.
> > To post to this group, send email to akka...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > akka-user+...@googlegroups.com<akka-user%2Bunsubscribe@googlegroups .com>
> > >http://groups.google.com/group/akka-user?hl=en.
>
> > --
> > Jonas Bonér
>
> > work:http://akkasource.org
> > code:http://github.com/jboner
> > blog: http://jonasboner.com
> > twtr: @jboner
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Akka User List" group.
> > To post to this group, send email to akka...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Jonas Bonér
Nov 1, 2010, 3:19:09 AM11/1/10
to akka...@googlegroups.com
I like this idea. But I have not had time to think about how it would
be implemented.
Would like to get it into 1.0 I think (if not too much and intrusive).
be implemented.
Would like to get it into 1.0 I think (if not too much and intrusive).
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
Jonas Bonér
Nov 1, 2010, 3:35:07 PM11/1/10
to akka...@googlegroups.com
It would be great if you could add a ticket outlining the idea.
Thanks.
Thanks.
goldfreak
Nov 1, 2010, 6:36:55 PM11/1/10
to Akka User List
Ticket created.
Just to drop a quick note: These session bound remote actors become
very compelling when combined with FSM. Sessions would go from
"connected" to "authenticated" to whatever application specific state
are.
On Nov 1, 2:35 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> It would be great if you could add a ticket outlining the idea.
> Thanks.
>
> On 1 November 2010 08:19, Jonas Bonér <jo...@jonasboner.com> wrote:
>
>
>
>
>
>
>
> > I like this idea. But I have not had time to think about how it would
> > be implemented.
> > Would like to get it into 1.0 I think (if not too much and intrusive).
>
> ...
>
> read more »
Just to drop a quick note: These session bound remote actors become
very compelling when combined with FSM. Sessions would go from
"connected" to "authenticated" to whatever application specific state
are.
On Nov 1, 2:35 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> It would be great if you could add a ticket outlining the idea.
> Thanks.
>
> On 1 November 2010 08:19, Jonas Bonér <jo...@jonasboner.com> wrote:
>
>
>
>
>
>
>
> > I like this idea. But I have not had time to think about how it would
> > be implemented.
> > Would like to get it into 1.0 I think (if not too much and intrusive).
>
>
> read more »
Jonas Bonér
Nov 2, 2010, 3:35:00 PM11/2/10
to akka...@googlegroups.com
On 1 November 2010 23:36, goldfreak <paul...@gmail.com> wrote:
> Ticket created.
>
> Just to drop a quick note: These session bound remote actors become
> very compelling when combined with FSM. Sessions would go from
> "connected" to "authenticated" to whatever application specific state
> are.
> Ticket created.
>
> Just to drop a quick note: These session bound remote actors become
> very compelling when combined with FSM. Sessions would go from
> "connected" to "authenticated" to whatever application specific state
> are.
Sounds interesting.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
goldfreak
Nov 5, 2010, 2:58:15 PM11/5/10
to Akka User List
I should have done this before.
I case anyone looks at this thread and wants to follow, here is the
link to the ticket
http://www.assembla.com/spaces/akka/tickets/504-add-session-bound-server-managed-actors
On Nov 2, 2:35 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> ...
>
> read more »
I case anyone looks at this thread and wants to follow, here is the
link to the ticket
http://www.assembla.com/spaces/akka/tickets/504-add-session-bound-server-managed-actors
On Nov 2, 2:35 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
>
> read more »
goldfreak
Nov 14, 2010, 7:21:03 PM11/14/10
to Akka User List
Created a patch for this in here:
git://github.com/paulpach/akka.git
you register a session bound actor like this:
server.registerPerSession("untyped-session-actor-service",
actorOf[RemoteStatefullSessionActorSpec])
For every client that connects and sends a message to the "actor", the
actorOf[...] function is called so a new actor is created and invoked.
When the client disconnects the actor is stopped.
Please offer criticism so I can make it merge material.
In particular, I am not very clear what the difference between channel
Opened and Connected is, as well as Closed/Disconnected, so I am
unsure as to in which one should the actors be stopped.
On Nov 5, 12:58 pm, goldfreak <paulp...@gmail.com> wrote:
> I should have done this before.
>
> I case anyone looks at this thread and wants to follow, here is the
> link to the tickethttp://www.assembla.com/spaces/akka/tickets/504-add-session-bound-ser...
> ...
>
> read more »
git://github.com/paulpach/akka.git
you register a session bound actor like this:
server.registerPerSession("untyped-session-actor-service",
actorOf[RemoteStatefullSessionActorSpec])
For every client that connects and sends a message to the "actor", the
actorOf[...] function is called so a new actor is created and invoked.
When the client disconnects the actor is stopped.
Please offer criticism so I can make it merge material.
In particular, I am not very clear what the difference between channel
Opened and Connected is, as well as Closed/Disconnected, so I am
unsure as to in which one should the actors be stopped.
On Nov 5, 12:58 pm, goldfreak <paulp...@gmail.com> wrote:
> I should have done this before.
>
> I case anyone looks at this thread and wants to follow, here is the
>
> read more »
Paul Pacheco
Nov 17, 2010, 8:59:18 AM11/17/10
to Akka User List
Any input on the patch?
Currently, the patch implements the session actors as a Map inside a ChannelLocal variable on the RemoteServerHandler.
Another approach could be to not have the RemoteServerHandler as Sharable, so a new RemteServerHandler is instantiated per channel. The Map would be kept as just an attribute inside it. This would be more in the spirit of "share nothing". Would you prefer this approach?
If the patch looks good, I will also add spring integration for this feature.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
√iktor Klang
Nov 18, 2010, 9:01:42 AM11/18/10
to akka...@googlegroups.com
I'll try to find time to look at the code today. Been horribly busy this weekWork: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
√iktor Klang
Nov 18, 2010, 9:37:30 AM11/18/10
to akka...@googlegroups.com
Alright, added code review in your code on github :-)
Paul Pacheco
Nov 18, 2010, 1:14:38 PM11/18/10
to akka...@googlegroups.com
thank you.
Will push fixes soon.
Paul Pacheco
Nov 18, 2010, 11:49:31 PM11/18/10
to akka...@googlegroups.com
Viktor,
Check now, I cleaned up the stuff you suggested and a little more.
Reply all
Reply to author
Forward
0 new messages