Asynchronous Messaging explained as a coffee shop

[MattP]

Good to know.  We tested on some other machines here and it worked fine 'out of the box' when downloaded.

[AristosQueue (NI)]

Nice work, Matt.

[TailOfGon]

I have been playing with AF for one week now. I just downloaded the StarBuzz and I was amazed with what AF (and Matt) can do. Thank you for sharing

[Jed394]

Awesome example Matt. 

Thanks for putting this up.  I'm glad to see someone else using a varient lookup table approach to managing actors.  I am doing the same thing for a project and i was a little worried it was bad form. 

[MattP]

It has some issues, but it seemed useful for the first pass I posted.  For me, I keyed the lookup table off of the actor's enqueuer flattened to a string.  This works well if you know the enqueuer (and gives me a uniqeueness guarantee), but poses problems if you need to look it up (for example, based on the index of the multicolumn listbox that the user clicked on).  There's a possibility of the indices and the attribute to table to go out of sync.

I chose it because I needed to frequently remove actors from the middle of the list, and I couldn't be arsed to implement a linked list.

Not sure if it's good form, honestly.  If someone has a better approach, I'd love to hear about it.

[MattP]

TailOfGon wrote:

I have been playing with AF for one week now. I just downloaded the StarBuzz and I was amazed with what AF (and Matt) can do. Thank you for sharing

Mostly AF  .  Hope you find the example useful - I know the process of designing and building it opened my eyes quite a bit as to why things are the way they are, and also some good lessons learned for the next go-around. 

If you have the chance, try building it yourself, without using my version as a crib sheet.  You may find (as I did) that some of your initial design instincts don't lead to a good architecture.  That discovery process is something I don't know how to teach except by doing it.

[LVB]

Matt,

Thanks for the great example.  Examples like this are a great resource for the community.

I created a sequence diagram of your code using PlantUML.  See attached for the source file (text) and image.  Hopefully, this can clarify the interaction between actors.

What was the intention of the "Completed Orders Dispatcher" actor?  It is never sent any messages.  Just launched, and shutdown.

[MattP]

LVB wrote:

What was the intention of the "Completed Orders Dispatcher" actor?  It is never sent any messages.  Just launched, and shutdown.

That would be one of those rough edges I mentioned in the initial post 

Currently, it does absolutely nothing.  I included it with the initial intention of using the same 'Work Dispatcher' model for customers waiting in line, orders waiting to be made, and drinks waiting to be picked up.  Pretty quickly I found that it was much easier (and IMHO, a better coffee shop) to directly message the customer with their order, rather than leaving it in a queue.

My development process for this was first to instantiate actors, then make sure I could properly shut them all down, then start adding functionality and messages between them.  I've found that failure to do it that way tends to result in actors running wild, and uneditable code due to locked libraries.  (also I quickly got tired of having to close the project to kill all my actors, or using the debug fork to abort each one)

There's some more orphaned code in there as well, but generally more deeply hidden.

I'll be posting a revised version early next week with this and some other tweaks folks have sent to me.  For those who don't like waiting, grab it as I write it at http://bitbucket.org/pollockm.  No guarantees on quality if you grab from the depot, I may be in the middle of something.

Thanks for the diagram - it looks great!

[AristosQueue (NI)]

I did some refactoring to remove the variants. The variants were inelegant. In a proof of the value of private data, I just changed the StarBuzz.lvclass and it all worked. And then, because I just couldn't stand it, I modified two of the message classes for updating the status so that the name wasn't being transmitted... a message should only communicate the changed data, not the whole record. Since name didn't change when status did, I took it out.

Hope you don't mind, Matt.

My revisions are saved in LV 2011. Because I have my paths modified on my machine, when you unzip, it may search for the Actor Framework.

[MattP]

Don't mind at all - thanks for giving it a look.

I'll merge those changes in with the others once I digest them.