Error Handling in messaging systems

[Daklu]

What you are describing sounds like a Publisher/Subscriber paradigm

 

I think of publish/subscibe (and Observers) as subsets of the event-announcement strategy.  (I'd rather just call it "event based programming," but people tend to confuse that with User Events and Event Structures in LV.)  In particular, publish/subscribe implies (to me) the ability to add and remove yourself from a list of subscribers during runtime and choosing a subset of an actor's messages to subscribe to.  Publish/subscribe is a form of event-announcement, but there are other ways to implement it as well.

 

 

Is this how the Actor Framework works?

 

No.  The AF (and any messaging framework worth its salt) doesn't restrict its users to a single paradigm, but allows them to create the kind of messaging protocol they need to solve the problem.  The requirement for synchronous query-response, asynchronous query-response, or event-announcement messages is determined by how you define and implement your actor.  It has nothing to do with the messaging system itself.

[drjdpowell]

You are correct that if one of the Exited messages fails to arrive then the UI loop will never shut down.  That's exactly what I want to happen.  Putting a timeout in the UI loop permits a resource leak--Loop 1 can continue operating after the rest of the application has been shut down.  By not using a timeout any errors in my shutdown logic are immediately apparent.  Fail early, fail often.  The hardest bugs to fix are those I don't know about.

 

Well, timing out would be an error, and one could handle that error in multiple ways: log error and shutdown anyway, display error to User and wait for input, trigger hardware emergency safe mode.  My point is that one’s code may require awareness about something, that is supposed to happen, not happening in a reasonable time.  It’s obvious how to do that with synchronous command-response, but not so clear if one is staying fully asynchronous.

 

I’m thinking of creating a “helper” VI for my framework that can be configured to wait for a message.  If it receives the message within the designated time it just forwards the message to its caller and shuts down; otherwise it sends a "timed-out” message instead.  That way the calling loop can send a command that it expects a reply to, and execute code to handle the case that the reply never comes, while remaining fully asynchronous and unblocked.  

[Daklu]

Well, timing out would be an error, and one could handle that error in multiple ways: log error and shutdown anyway, display error to User and wait for input, trigger hardware emergency safe mode.  My point is that one’s code may require awareness about something, that is supposed to happen, not happening in a reasonable time. It’s obvious how to do that with synchronous command-response, but not so clear if one is staying fully asynchronous.

 

Sure, there are ways to implement similar functionality using synchronous query-response messaging and timeouts.  My response was directed at the question of whether or not fully asynchronous actors still need a timeout on their message queue.  My answer remains, "no, I believe it is possible to always create a well-designed actor without putting critical code in the message handler's timeout case."

 

Implementing timeout behavior using synchronous query-response messages may very well be obvious (though the asynchronous solution is more obvious to me.)  What's less obvious is how to solve the other problems associated with synchronous messaging the developer encounters later.  If an actor has a behavior that requires some sort of event timeout, I prefer to implement that behavior in the actor using a metronome or watchdog loop--similar to the helper VI you describe above.

[drjdpowell]

If an actor has a behavior that requires some sort of event timeout, I prefer to implement that behavior in the actor using a metronome or watchdog loop--similar to the helper VI you describe above.

I made one yesterday. Here is the only public API method, “Send Message with Reply Timeout”, which is identical to my regular “Send Message” method but with a timeout input and an optional input for the Timeout message to send:

Works by an asynchronous call of a small “watchdog” that waits on the reply and returns either that reply or a timeout message. It then shutsdown.

 

I should add that this only works for a system where the address to send replies to can be attached to the original request message.  Hard to define a “reply timeout” without a defined reply.

 

— James