- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
"Actors" in GAE/J
Mon, 2009-09-28, 16:29
I've been thinking about implementing an actor-like framework for use on GAE/J. I want this because I'm going to work on implementing a GAE app that is very well suited to message passing (It's a computer implementation of a card game similar to Magic The Gathering).
I wondered if anyone else was working on this and I'd be interest in any comments people have on my ideas below.
The basic idea is to have a central Queue that holds messages for all Actors (I'm not sure that's the best term, I don't think they don't actually count as actors). When a message is sent to an Actor:
a ! 'msg
The message would be added to the global Queue and not immediately executed. Any thread could then trigger the processing of messages:
MsgQueue.processMessages()
This would iterate over the message queue in much the same way the current actor implementation does checking with the receiver actor of each message to see if it can handle it (a.process.isDefinedAt(msg) or similar). If so the message is processed (a.process.apply(msg)). The Queue would do a single pass over all messages in the queue and then if any new messages have been added or if any messages have been processed, it will do it again. This will of course all occure in one thread. Once the message processing is done execution will return to the caller of processMessages(). It is just a normal function call (probably returning Unit).
The request processing pattern would be something like the following. Each session will have a actor accosiated with it.
1. Send messages to actors based on the information in the request. In my app's case this would be sending messages to the game rule engine telling it what actions the player is taking.
2. Call processMessages(). This allow the other actors to execute (the game engine actor for instance) and may also end up executing the session actor with reply messages from the core.
3. Extract data from the session actor and use that info to render the response. This process will also need to handle the case where the session actor did not get any reply. This could happen because the core actors had to send a message to a different session actor to get information and that actor has to wait to talk to it's client. (This would happen in a multi player environment)
This obviously is much more limited than real actors, but I think it could be really useful. The most noticable limitation is that it would not be possible to implement synchronous messages and the actor would need to return after every message it processes (Though I guess a Actor.react like construct could hide this).
If there is a need to process messages while there is no client request being processed, then a cron job (http://code.google.com/appengine/docs/java/config/cron.html) or the task cue (http://code.google.com/appengine/docs/java/taskqueue/) could be setup to do it periodic.
It should be pointed out that I'm not trying to get any concurrency out of this. I'm just trying create a clean message passing environment. Also I know there will be a need to locking will be needed because requests may be handled concurrent. I just didn't include it here because I thought it would confuse the issue (a lock on each actor and on the main Queue would probably be enough).
What do people think? Is this sane and/or useful?
-Arthur
I wondered if anyone else was working on this and I'd be interest in any comments people have on my ideas below.
The basic idea is to have a central Queue that holds messages for all Actors (I'm not sure that's the best term, I don't think they don't actually count as actors). When a message is sent to an Actor:
a ! 'msg
The message would be added to the global Queue and not immediately executed. Any thread could then trigger the processing of messages:
MsgQueue.processMessages()
This would iterate over the message queue in much the same way the current actor implementation does checking with the receiver actor of each message to see if it can handle it (a.process.isDefinedAt(msg) or similar). If so the message is processed (a.process.apply(msg)). The Queue would do a single pass over all messages in the queue and then if any new messages have been added or if any messages have been processed, it will do it again. This will of course all occure in one thread. Once the message processing is done execution will return to the caller of processMessages(). It is just a normal function call (probably returning Unit).
The request processing pattern would be something like the following. Each session will have a actor accosiated with it.
1. Send messages to actors based on the information in the request. In my app's case this would be sending messages to the game rule engine telling it what actions the player is taking.
2. Call processMessages(). This allow the other actors to execute (the game engine actor for instance) and may also end up executing the session actor with reply messages from the core.
3. Extract data from the session actor and use that info to render the response. This process will also need to handle the case where the session actor did not get any reply. This could happen because the core actors had to send a message to a different session actor to get information and that actor has to wait to talk to it's client. (This would happen in a multi player environment)
This obviously is much more limited than real actors, but I think it could be really useful. The most noticable limitation is that it would not be possible to implement synchronous messages and the actor would need to return after every message it processes (Though I guess a Actor.react like construct could hide this).
If there is a need to process messages while there is no client request being processed, then a cron job (http://code.google.com/appengine/docs/java/config/cron.html) or the task cue (http://code.google.com/appengine/docs/java/taskqueue/) could be setup to do it periodic.
It should be pointed out that I'm not trying to get any concurrency out of this. I'm just trying create a clean message passing environment. Also I know there will be a need to locking will be needed because requests may be handled concurrent. I just didn't include it here because I thought it would confuse the issue (a lock on each actor and on the main Queue would probably be enough).
What do people think? Is this sane and/or useful?
-Arthur
