LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Hi Team,

Background:
We placed a brx on server and executed via a program. The BRX creates a brs and brd for every run. The brd points to other temporary brds located in the same server.

Issue:
While importing the brs and viewing the data, some of the node outputs show the count of data they contain but do not show the data. They appear as blank node outputs as shown in the attached image.
Also, the blank node outputs appear in different nodes each time we run. Please help us out!

Lavastorm_BlankNodes_WithData.jpg

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: rboccuzzi

I believe what I am seeing here, the controller is configured to execute the graph using streaming. This means that in some cases, the data will not be available between nodes, as the data is not cached to disk, but streamed directly from one node to another. If you desire all the data to be available, you will need to insure that the controller is operating in file mode instead of streaming. The property is ls.brain.controller.scheduler, and it probably is currently set to "default" or "streaming", and you will want to change that to "non-streaming"

Cheers
Rich

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Thanks a lot Rich. After making the change it works great!

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Hi Rich,

After I made a change to the scheduler, I had a space issue with the amount of brd files getting generated. Then I switched back to default mode.
Is there a way to overcome the space issue while using "non-streaming" without altering the disk space?

Thanks in advance,
Bharath

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: rboccuzzi

Unfortunately, those are tied together. The reason you get to see the intermediate data between the nodes is because we cache the data (on the disk). So any solution that would help free up disk space, such as going into Preferences, on the Execution tab, and changing the Temp File management to Aggressive. This will clean up your temp files when you don't need them, but similar to the first post, you will then not have data between the nodes to click on.

Cheers
Rich

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: snbkumar

Thanks Rich. I now understand your point that "More the files being stored on disk, better it is for debugging but greater disk usage". We will look into implementing your solution of setting Temp File management to Aggressive and see how that works for us.

Thing is, even though the nodes are available we sometimes find error handling as a tedious process as the errors are sometimes complicated. Can you please provide a link/document that mentions all errors and its suggested solutions. (Similar to oracle documentation). This will greatly help us while using Lavastorm.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: rboccuzzi

Unfortunately, there isn't currently a document that describes all the errors you may encounter, yet. We have a feature request in to overhaul the error system to provide codes as part of the error messages, which will allow us to build up a repository of easily reference-able error messages. As many nodes are developed to interact with other systems and applications, and we provide a method for throwing errors, much like a standard programming language, such that any customer developing nodes could use, we probably won't have an all encompassing system error numbering system, but will endeavor to ensure that the frequent core errors will be captured by this feature.

Cheers
Rich