A solution to error 1527 with network endpoint actors

[lowestpass]

This subject came up during gdevcon NA last week, and I was encouraged to share the solution I've come up with to a common problem.

The problem

When sending actor messages via network endpoint actors (most typically to an RT target), any classes that are part of the message data must already be loaded into memory on the remote system. Being built into the executable isn't enough, they have to actually have been loaded. If they haven't been, then when network endpoint actor attempts to unflatten the message it returns error 1527.

The typical solution that I've seen to this is to drop class constants somewhere on the block diagram. I haven't liked this solution very much though. In part because it becomes a huge mess of class constants if the application is large enough. And in part because sometimes I forget to do this step during development, and only realize my error once I actually deploy. Then at that point it can be hard for me to figure out exactly which class isn't getting loaded.

My solution

I've created a pre-build action that creates a list of all classes that are part of Always Include and saves it to a file. That file also gets included in the build. On startup the application reads that file and loads all of the listed classes. Then during development I just have to make sure that all my new classes are part of a Always Include folder, and everything ends up working like it should.

 

Load Classes

Has anybody else done something similar? Or are there any other solutions that people like?

[Quiztus2]

had the error sometimes, now I have an explanation, thanks.

[StevenHowell]

AWESOME!!!! I will have to try this, this has been one issue that has kept me from using the Network Endpoint Actors with cRIO. 

As you said if the application is large enough,  this becomes a problem on the block diagram and is easy to forget to add them in the first place. 

On all of my cRIO deployments, I like to have SQLite databases for all of the configuration data and logging. 

It might be possible to add a database for this function and not have to worry about the Always Included. Keep a lookup table of the classes to load in the database, that is in the initialization of the endpoint actor to read from the database the class and location. 

At that point, you would be able to dynamically add and remove messages much easier than having to rebuild the executable each time. 

Might be worth a shot.