Getting information about an actor from its enqueuer?

[DMurrayIRL]

Is it possible to get any information about an actor from its enqueuer? Even, for example, the 'clone number'? If I launch a lot of actors of the same type, I'd like to have a simple way to distinguish between the different instances, for my own logging and message ID functionality. I know you can add your own ID parameter to the actor private data, but really what I'm looking for is some way of identifying an actor at the time I send it a message, so the enqueuer makes sense.

[BillMe]

There's a thread here that might help you.

[Oli_Wachno]

I would suggest a variant table holding enqueuers and corresponding Actor IDs (one of the options mentioned in the thread BillMe has referenced)

I'm using variant tables to implement abstract messaging, so far I had no performance issues.

But nevertheless, there has to be some pattern for the assignment of the IDs and some mechanisms to use them. So storing and retrieving them is IMHO just one part of a larger issue.

[DMurrayIRL]

Thanks guys, that thread is useful. I'm not even looking to do anything as complicated as you think; I just need a unique identifier for each Enqueuer that I can add to a message ID field for Asynchronous Request-Asynchronous Reply functionality. The Flatten to XML string turns out to be ideal, as I can use the value in the <Val></Val> field as the identifier.

[AristosQueue (NI)]

Just striaight up using the Enqueuer for an ID is also possible, without flattening it to a string. For a simple "request, asynch reply" setup, I just put the sender's Enqueuer in as part of the data.

DrJDPowell and Daklu both have some good ideas about addresses in their frameworks (you can find their posts in this forum) that you can borrow for the AF even if you cannot implement direclty.

For data association, I use a parallel array setup for some of my code -- one array is an array of Enqueuers, the other is the array of data associated with that Enqueuer.

[DMurrayIRL]

Yeah, I've been doing your first suggestion for a while now - including the enqueuer as part of the message data if I want the reply to go to the non-caller (i.e. launching) actor. I'm happy enough using the enqueuer as (effectively) the address of an actor.

What I'm doing here is different though - I send off a lot of parallel requests to actors, and include a unique message ID with each request. Then before I send the asynchronous replies back, I extract the message ID from the request data and send it back to the caller with the reply data. That means I can match up the requests and replies. So when I launch several actors of the same type, and send them messages of the same type, I also need a unique string ID for the actor. I could, I suppose, send the enqueuer back with the reply to do the matching I want, but I feel a single string message identifier is neater. The string ID is also easy to integrate with my own logging functionality as well.

[CaseyLamers1]

Is trying to keep track of replies from separate instances of hte same type of actor your main use case? In other words you launch 4 of "Actor A" to do 4 similar things but you use the data in unique ways? If that is true then I would give the 4 identical actors 4 different reply messages when you launch them. Each reply message would then do the action unique to that message. Then the caller doesn't need to know "who" it came from by lookingsomething up. It knows who it came from by what the reply message is.

[DMurrayIRL]

That may be an option. I'll try to give a brief overview of my use case. My first venture into some proper programming with AF is to take my standard test sequencers and try to parallelize sections of them as much as possible. So for example, say I have a section where I generate and save 200 x-y plots: previously I would just do each plot in sequence, but now with AF I want to launch 200 separate actors to do a single plot each. When a plot actor has its job done (or if there was an error), it sends an asynchronous reply back to the main test sequence actor. The replies are processed and verified by matching the message ID sent in the request with the message ID returned in the reply. (Obviously I have other code for storing message ID's before sending and saving/comparing the message IDs when they are returned, but I don't think that's relevant here). 

As regards your suggestion: The way my architecture has evolved over the last few weeks, I now only need one type of reply message for all my different test sequencer actor states and nested actors. Something else that's probably important here: on the main test sequencer actor core, I override it with a while loop + event case structure to handle the asynchronous replies from nested actors. So in this case, my architecture probably doesn't work well with extra reply message types. (Typing this out is actually clarifying a lot for me!) Possibly a different approach would be better though... feedback is certainly welcome.

[CaseyLamers1]

With 200 jobs you would not want to have different reply messages. Aside from doing the enqueuer matching I might ask if there is something unique and specific about the job that is known at spawning of that process. If so I would probably give the job an ID and include the ID in the response.

[AristosQueue (NI)]

I agree with Casey's guidance.