Is there some way to see how messages an actor has queued?

[jdebuhr]

As the topic suggests,

Is there some way to determine how many messages are in an actor queue?

I have a project where I am writing to 6 different files concurrently. I have created an actor for the writing to these files and I spawn the actor to how ever many files I need to write to ( in this case 6). When I stop the test process and  the program returns to idle, I want to close the data files and file references. when I do this I get an error (I don't have the specifics of the error which I can get again), but if I do not close the file/reference I don't get the error.

What I would like to do is be able to check the message queue, if there are still messages waiting, then don't close the reference until all are processed, then close.

[CaseyLamers1]

How about having a method in your file writing actor that is "close file" and then have the actor that sends the data tell the file write to close the file.  The file writer wouldn't have to know when the data was done, just accept the close file command.  No need to count messages.  This assumes that your data senders know when they are done. 

If you have multiple senders writing to a single file you could have them be launched by a controlling actor that they each tell that they are done and then that controlling actor launched the file writing actor and passes the queue to the data senders and closes the file when all senders report that they are done.

[MattP]

You could also have the close file message be a lower-priority message than your write messages.  In this way, the close file message would only be processed if at that moment there were no pending write messages waiting. 

[jdebuhr]

Thanks for the ideas.. I have tried a couple of thoise or similar but will revisit them and see where the issue is truly residing

[Daklu]

The solution depends on what kind of error you're getting, but there are a couple things that come to mind from reading your post.

1.  The message queue is a transport mechanism, not a job queue.  I don't believe you should ever need to inspect the pending messages or the message queue (except to see if it's still alive.)  I've found it works best when the message handling loop pops messages off the queue as fast as they arrive.  If you need a job queue, implement that separately inside your actor.

2.  It sounds like you may not have clearly defined the responsibilities of your actors.  When I write actors that save data to disk, the File I/O actor is the only actor that has the file refnum.  No other actor knows, or cares, whether or not the file is open.  They just send the data.  The File I/O actor handles all the details.

Depending on the application's needs, sometimes my File I/O actor will open a file once and write to it continuously as data arrives.  The saves the overhead of opening/closing the file, but also runs the risk of losing all the data.  (If the file isn't closed correctly due to system crash, etc.)  Sometimes my File I/O actor will hold the data in memory until a "big enough" chunk of data has been collected, then it will open the file, write the data, and close it.

[AristosQueue (NI)]

Checking the message queue is a guaranteed way to introduce race conditions in your code. If your receiver happens to get a little bit ahead of your sender, it checks the queue, it's empty, so it shuts down -- and a microsecond later a new message enters the queue. This was a main item on my list to shoot down when designing the AF -- to make the message queue as opaque as possible to actors so that such code could not be written. I'm sure there's some clever way you could hack around the safeguards, but if you bring that way to my attention, I'll give some thought about how to fix it as a bug. 🙂

As Casey said earlier, include a message in your data stream that is the signal to close the file. And don't forget to close the file if you get a Stop message before that Close message arrives. 🙂

[jdebuhr]

Fixed it...

Casey, I did have a boolean I would set in the Actor if I have opened a file or closed it. The problem was somewhere along the way I never fully implemented that boolean logic. When I looked at the code again today it became apparent to me that this is where the issue was.

So I had everything done the way I wnated but that one little piece got overlooked ( probably when I got pulled off of this to something else) at any rate.. all is good and working now

[AristosQueue (NI)]

Good to hear. 🙂