Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1448 in Handle Error

I'm getting this error in a Do.vi but I'm trying to track back where this problem is starting. It only happens during startup if I force a specific scenario which is the difference of letting the application initialize completely or polling it for information while starting. So, it is most likely "Bad" code but a race condition that is occurring during startup. Does anybody have a trick or suggestion on determining who called the message that made the Do.vi fail? This is a large application that runs on a cRIO with web services so it is not easy debug because of the time that it takes to restart the application.

 

Any suggestions would be greatly appreciated.

 

Thanks,
Eldon

0 Kudos
Message 1 of 11
(2,405 Views)

MGI's Monitored Actor can log messages and may have some error tracking (can't remember offhand). You should also be able to see (or log) messages that result in an error, so you can see which message is causing the issue, which should narrow things down considerably.

 

The Desktop Execution Trace Toolkit or Realtime Execution Trace Toolkit might help as well.

0 Kudos
Message 2 of 11
(2,383 Views)

Good afternoon, 

 

That specific 1448 error is a "bad typecast" error. It is happening in your DO vi because the actor class you are trying to send the message to does not recognize the message class being received. 

 

Check to make sure that whatever actor you are trying to send the message to has a concrete implementation of the method being called by the message class.

Appreciate constructive criticism, it is there to help you succeed.
0 Kudos
Message 3 of 11
(2,339 Views)

Thanks for responding. I'm well aware of the error and what is causing it. The problem is tracking it down. The application is not small, as stated previously, and at startup, there are hundreds of messages being sent to multiple child actors and the root actor.

Later,
Eldon

0 Kudos
Message 4 of 11
(2,320 Views)

Thanks for responding. I've looked at MGI's actor enhancement previously and it looks like a logical addon for debugging and tracing. Due to the size of the application and the past issues I have had implementing actor framework with web services on a cRIO, I'm not to keen on adding another layer of complexity to the project.

 

I was hoping that there was a way to trap the error in the root Actor Core.vi where the error is being detected and sent to the Error Handler.vi. On a cRIO, even though the VI is setup for debugging, it is not allowed and changing it to a non-entrant VI breaks the whole framework. Do you know if there is a way to probe the Actor class at that point to determine where the message is coming from? If so, I could write out some diagnostics information to the cRIO builtin message logging system.

 

Thanks,
Eldon 

0 Kudos
Message 5 of 11
(2,319 Views)

Probing the actor class isn't going to tell you where the message is coming from. Unless you are explicitly including some sender information in your messages, there is no way to tell where a message came from by looking at the receiving  actor - you need to catch it at the sender.

 

That said, if you have actors receiving messages and you have no idea where they're coming from, it seems like you should probably take a step back and rethink your design. When you launch the actor in question, what do you do with its queue? Are you using the scripted 'send messages' or your own message injection? 

 

A simple way to solve this is to protect your actors queue in another class - that class does nothing but provide an API for the messages that the actor is capable of processing.

 

That said, if you want a quick and dirty way of figuring out where the message is coming from, hack your copy of the AF enqueue (Make a backup copy of it somehow so you can revert it when you're done). Add some code to log the call chain, message class name, and queue ID of every message that gets sent, in addition to something that logs the queue id of every actor as it is launched. Then its just a matter of digging through the log to find the call chain of the offending message.

0 Kudos
Message 6 of 11
(2,313 Views)

@paul.r wrote:

 

That said, if you want a quick and dirty way of figuring out where the message is coming from, hack your copy of the AF enqueue (Make a backup copy of it somehow so you can revert it when you're done). Add some code to log the call chain, message class name, and queue ID of every message that gets sent, in addition to something that logs the queue id of every actor as it is launched. Then its just a matter of digging through the log to find the call chain of the offending message.


The MGI Monitored Actor does lots of this already and requires no hacking of core AF. It does require you to change your dependency from your top level object to be Monitored Actor instead of Actor, but you can always undo that when you're done if you don't need the Monitored Actor. They even include a utility to do this automatically (the Monitored Actor Switcher).

 

Do note that it does things from the *receiving* end, not the *sending* end. You'll be able to see all of your messages coming in to each actor, but it doesn't log the outgoing ones. I bet you could expand it to do so though, and that library would be a great place to start if you're expanding Actor monitoring.

0 Kudos
Message 7 of 11
(2,292 Views)

The things monitored actor already does aren't what TS needs - so, as mentioned it would be adding another layer of complexity, which wouldn't solve the problem. Swapping the entire actor inheritance hierarchy regularly may also introduce the 'deployment completed with errors' nightmare that comes with making large changes to RT based applications.

 

I don't see any way you can trace the sending of all messages without either wrapping up all AF enqueue calls in another method, modifying the AF enqueue, or using the DETT. 

0 Kudos
Message 8 of 11
(2,286 Views)

You're right. For some reason I had it in my head that Enqueue was an Actor method that you could override easily enough, but of course it's not. Brain fart.

0 Kudos
Message 9 of 11
(2,280 Views)

The error is occurring in the service that is responsible for logging errors that have occurred. These errors only occur if I am polling the cRIO during it's initialization phase. If I wait till after it is fully initialized, there are no errors. As I have said, there is a race condition that is occurring and I'm trying to track it down. The errors being generated during polling does not effect the initialization so nothing goes wrong. I would just like to get a hold of the actual error being sent to the log service. Unfortunately, the error being caught by Handle Error is coming from some place other than I thought.

 

Later,
Eldon

0 Kudos
Message 10 of 11
(2,276 Views)