As per title, I am having problems at DMN simulator online Camunda DMN-Simulator, when I try to execute any input, of any table, with any hit policy, it always returns this same error.
I am trying to learn how to use DMN and I am making this exercise, but this error does not allow me to debug.
I also include the file, if anyone is interested in recreating this error
[simulation.dmn|attachment]
(upload://iIPF3PPO7Ziy2Pq0wwj1xavcYnL.dmn) (23.4 KB)
same error here!
19 lines are ok, one more = crash
20 lines error, remove ANY field or input = ok
Same error, can provide sample. In our files it seems to happen when a 10th rule is added to a table. Can provide the xml file on demand, cannot upload here for some reason.
Please do send along the Model.
Can you also explain when exactly the error occurs? During deployment or during evaluation?
Dear Niall, thx for your quick reply. Find attached the simplest way to reproduce the error. sample_ok.dmn contains 9 rules in the table and works. sample_nok.dmn contains a 10th rule of the same form as the previous 9, and crashes the service.
sample_ok.dmn (19.4 KB)
sample_nok.dmn (20.9 KB)
Hi Niall, could you reproduce this issue?
I’m encountering the same issue, the DMN crashes with the 10th rule no mather the hit policy.
Hi everyone (@Michele_Mengascini, @mbuholzer, @kaYcee, @DeM0N) - I don’t have a fix for the DMN Simulator, but that particular simulator is older and there’s been some discussion of discontinuing it. There is a very nice community project for testing DMNs that may not have the same limitations as the current DMN Simulator. I’d recommend checking it out and seeing if it helps with your testing needs: GitHub - camunda-community-hub/camunda-dmn-tester: Project to test (Camunda)-DMN Tables.
Hi @nathan.loding , thx for your reply! The thing is, the simulator used to work absolutely fine until recently, maybe a couple of weeks ago. Most likely, the error was introduced during a recent patch or change in infrastructure settings. The nature of the problem seems to point to some issues with memory management, since the number of rules processed before the service breaks seems quite arbitrary.