BRX Failing but returning a RunExitCode of 0
Originally posted by: Carl_Morris
Hi,
I am calling a graph using the 'Execute BRX' node, everything within the BRX graph runs succesfully and it gives a RunExitCode of 0, but there is a red cross over the node upon completion. When I look at the error log, I can see a warning for 'Node reported the following messages to stderr: R6025 - pure virtual function call', this is all the messages I can see.
Why would the node be failing, if I am receiving a successful exit code? Is there anywhere else I can look?
This is being run through automation and I have other graphs running fine using the Execute BRX node.
Thanks,
Carl
Hi,
I am calling a graph using the 'Execute BRX' node, everything within the BRX graph runs succesfully and it gives a RunExitCode of 0, but there is a red cross over the node upon completion. When I look at the error log, I can see a warning for 'Node reported the following messages to stderr: R6025 - pure virtual function call', this is all the messages I can see.
Why would the node be failing, if I am receiving a successful exit code? Is there anywhere else I can look?
This is being run through automation and I have other graphs running fine using the Execute BRX node.
Thanks,
Carl
-
Originally posted by: Carl_Morris
I have loaded the latest BRS for both graphs, the one calling the graph and the one that is then run, and the only errored node is the 'Execute BRX' one.
I have attached a screenshot showing the BRX output and the RunExitCode.
Error_Issue_Screenshot.PNG
I was expecting something to have failed in the graph called by the BRX but cannot find anything.
Carl -
Originally posted by: Carl_Morris
The graph that the BRX runs looks fine, when the BRS is loaded. All the nodes appear with a green tick over them and the very last node writes a entry to my log table, as expected.
All the parameters are passed correctly into the graph and the outputs are as expected. -
Originally posted by: gmullin
The final node in your main graph (the one the BRX node runs) writes data to a table? What database is it? As a test, can you disable the node that writes to the table and compile the BRX again and try it? I think the Pure Virtual Call error might be coming from whatever driver you use to write to your database, so trying to isolate if that is it. I saw this error before when somebody was writing to a Redshift database, ultimately the driver needed to be updated.
It might be best to continue this outside of the forum, can you send the results of the test to Technical Support? -
Originally posted by: Carl_Morris
I had sent an email but I appear to have resolved the issue.
It seems that I need to add a link between the clocks on the 'Execute BRX' node and the preceding one, in my example a filter. Once this is added it completes successfully.
I found this out because the graph ran fine when not using Automation, but when I had the graph scheduled it failed. I remembered having a similar issue, so thought I would try linking the clocks.
Do you know why this would make a difference when the graph is scheduled? -
Originally posted by: gmullin
I'm thinking since you are running the BRX node inside a Logistics Manager job that because its a BRX (it will execute whatever it can first) its trying to start it a bit too early, i.e. before the Filter node. It should not do that but if it is, the clocking to it probably explicitly told it to wait until the Filter had set up the parameters. -
Originally posted by: Carl_Morris Originally posted by: stonysmith
We are using 6.1.3. Adding a clock has resolved the issueWhich version of LAE are you using? I vaguely remember an issue before 6.1.2 where implicit clocks didn't always work as expected.
Originally posted by: gmullin
Thanks for the explanation, I will remember this for next time and always add a clock, just to make sure.I'm thinking since you are running the BRX node inside a Logistics Manager job that because its a BRX (it will execute whatever it can first) its trying to start it a bit too early, i.e. before the Filter node. It should not do that but if it is, the clocking to it probably explicitly told it to wait until the Filter had set up the parameters.
Please sign in to leave a comment.
Comments
9 comments