Java WebSockets | Sending a message to a specific user

[Marc Binz]

Hey there folks,

After spending a couple of days trying to understand Akka and the way websockets in Play work, I still don't really get it.

I want to implement them using Actors not Streams.

Every example I can find only shows how to handle messages coming from the client, but isn't the purpose of a websocket more likely related to server-side updates?

(At least that is what I want to use them for)

So I know Akka uses a unique path for each Actor. But Play uses a "random" id (e.g. $a, $b, $c, ...) within that path so it looks like "akka://application/user/*/flowActor" where * is the random part.

Therefore in my eyes it is not possible to use the actorSystem.actorSelection method to identify the Actor(s) for a specific user.

One rather obvious solution for the problem would be to introduce some kind of registry that stores the ActorRefs based on the users uuid, yet this doesn't seem like a really Akka-like way of doing things. Another way would be to make use of a ManagerActor storing all WebsocketActors as named (user uuid) children.

So my main problem is not to find a solution to the problem, but rather the "best practice".

I mean there must be one, right?

I thought of something like using the actorSystem.actorSelection with a path like "akka://application/user/<uuid>/*/flowActor".

That way a user can have multiple open connections (for each tab, browser, device).

This seems like a good way to go, yet I don't know how to implement exactly that.

I'm hoping there is somebody who can help me with this problem (at best giving me some inside on a good implementation).

Looking forward to a response.

Thanks,

Marc

[Will Sargent]

You can work with Akka actors and streams and have them talk to each other.  See the example:

https://github.com/playframework/play-scala-websocket-example/tree/2.6.x/app/actors

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/9c025bba-a244-4f3f-958a-ff73e3578431%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TC]

Hi, I have a similar question about retrieving actor references. After reading: https://www.playframework.com/documentation/2.6.x/JavaWebSockets#Handling-WebSockets-with-actors it is not clear to me how to get an ActorRef to the Actor that is created so that I can send messages to it. The stock example connects a flow directly to the web socket, I am trying to use an Actor.

My ultimate use case is that I want to send a message to all open web sockets from the action method of a rest end-point.

On Tuesday, January 16, 2018 at 7:24:43 PM UTC-5, Will Sargent wrote:

You can work with Akka actors and streams and have them talk to each other.  See the example:

https://github.com/playframework/play-scala-websocket-example/tree/2.6.x/app/actors

On Mon, Jan 8, 2018 at 2:30 AM, Marc Binz <bin...@gmail.com> wrote:

Hey there folks,

After spending a couple of days trying to understand Akka and the way websockets in Play work, I still don't really get it.

I want to implement them using Actors not Streams.

Every example I can find only shows how to handle messages coming from the client, but isn't the purpose of a websocket more likely related to server-side updates?

(At least that is what I want to use them for)

So I know Akka uses a unique path for each Actor. But Play uses a "random" id (e.g. $a, $b, $c, ...) within that path so it looks like "akka://application/user/*/flowActor" where * is the random part.

Therefore in my eyes it is not possible to use the actorSystem.actorSelection method to identify the Actor(s) for a specific user.

One rather obvious solution for the problem would be to introduce some kind of registry that stores the ActorRefs based on the users uuid, yet this doesn't seem like a really Akka-like way of doing things. Another way would be to make use of a ManagerActor storing all WebsocketActors as named (user uuid) children.

So my main problem is not to find a solution to the problem, but rather the "best practice".

I mean there must be one, right?

I thought of something like using the actorSystem.actorSelection with a path like "akka://application/user/<uuid>/*/flowActor".

That way a user can have multiple open connections (for each tab, browser, device).

This seems like a good way to go, yet I don't know how to implement exactly that.

I'm hoping there is somebody who can help me with this problem (at best giving me some inside on a good implementation).

Looking forward to a response.

Thanks,

Marc

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[Jülide Meyer]

I'm using distributed publish and subscribe with akka cluster. 

This pattern provides a mediator actor, akka.cluster.pubsub.DistributedPubSubMediator, that manages a registry of actor references and replicates the entries to peer actors among all cluster nodes or a group of nodes tagged with a specific role.

https://doc.akka.io/docs/akka/2.5/distributed-pub-sub.html

It's very flexible and you can scale it with several play instances.