0

I'm using Orbeon Forms 3.8.0.201005141856 CE.

Orbeon throws a stackoverflow error when there are too many models on the page. During the initialization a xforms-rebuild is done on the main model, which in turn launches rebuild/revalidate/recalculate on every model.

If there are too many models, it never finishes because of a stack overflow.

I can understand that there is some recursivity, maybe the first model is not finished validating unless all the other are too, but the stack is like this:

the first few lines are random, these are the methods being actually called at the moment it overflows, the rest is an endless loop of:

org.orbeon.oxf.xforms.xbl.XBLContainer synchronizeAndRefresh XBLContainer.java 696 org.orbeon.oxf.xforms.xbl.XBLContainer endOutermostActionHandler XBLContainer.java 669 org.orbeon.oxf.xforms.XFormsModel rebuildRecalculateRevalidateIfNeeded XFormsModel.java 1120 org.orbeon.oxf.xforms.xbl.XBLContainer rebuildRecalculateRevalidateIfNeeded XBLContainer.java 723 org.orbeon.oxf.xforms.xbl.XBLContainer rebuildRecalculateRevalidateIfNeeded XBLContainer.java 733 org.orbeon.oxf.xforms.xbl.XBLContainer rebuildRecalculateRevalidateIfNeeded XBLContainer.java 733 org.orbeon.oxf.xforms.xbl.XBLContainer rebuildRecalculateRevalidateIfNeeded XBLContainer.java 733

Maybe some levels of recursivity could be avoided here ?

Anyway, I doubt I can get a fix for that. But maybe I can fix something on my forms. And I'd like to confirm that it is a too many models problems.

My case is a little special as my forms are constructed on the fly, without information on the data that will be used. With a little simplification it looks like this (this is only pseudo code to give an idea).

I have template defining the possible data, there can be severa templates, each can containing several attributes.

<!-- This defines data templates, known at form creation -->
<xf:instance>
  <templates>
    <template id="template_1">
      <attribute id="attribute_1_1" type="string" />
      <attribute id="attribute_1_2" type="date" />
    </template>
    <template id="template_2">
      <attribute id="attribute_2_1" type="int" />
      <attribute id="attribute_2_2" type="dateTime" />
    </template>
  </templates>
</xf:instance>

Then the data. There can be multiple objects, each one uses one of the template above. It can contain attributes from the template, but maybe not all of them. It can also contain attributes not from the template that will be ignored. There can be several objects using the same template. There can be templates that are unused by any object.

<!-- This is the data, unknown at form creation -->
<xf:instance id="objects">
  <data>
    <object template="template_1">
      <attribute name="attribute_1_1">value</attribute>
      <attribute name="unknownAttribute">value</attribute>
    </object>
    ...
  </data>
</xf:instance>

Now for displaying:

<!-- Repeat on objects -->
<xf:repeat nodeset="instance('objects')/object">

  <!-- A XBL that can display a template from its template definition node
  <fr:templateDisplay template="instance('templates')/template[@id = ./@template]" />
</xf:repeat>

The XBL itself does the same thing at the template level:

<xbl:binding id="templateDisplay" />
  <xbl:implementation>
    <xf:model>
      ...
    </xf:model>
  </xbl:implementation>

  <xbl:template>
    <!-- A repeat on the attribute definition of the attributes -->
    <xf:repeat>
      <!-- A XBL that changes its control depending on datatype -->
      <fr:genericInput type="" data=""/>
    </xf:repeat>
  <xbl:template>
</xbl:binding>

The genericInput XBL contains different kind on input depending on the datatype, it can be with different @type on the bind, it can be simple xbl, it can be a datepicker, etc. It can be read-write/readonly, it can be single/multivalued.

The problem is that if I have a template containing 5 attributes, it generates (at least) 6 XBL by object, and thus, 6 models to rebuild.

In the beginning I could manage 20 objects before crashing. I also had a localization xbl used by all other xbl (so at least 12 xbl/models by object), I removed that and some other stuff, and I'm up to 60 objects before crashing, but the goal would be 200.

I thought of maybe using xsl in my xbl to try to remove the genericInput. But I'm not familiar with XSL and I'd like to be sure it would lead to an improvment.

Or is it possible to filter these rebuild and have a still functionning form ? A way to make them less recursive ?

Or maybe I'm wrong and it's not a number of models issue ?

Any hint would be appreciated.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
user2739975
  • 85
  • 11
  • Hard to say, since this is on an old version of Orbeon Forms. You can create infinite loop in forms, and there might be bugs in the implementation causing an infinite loop. I am not aware of any of the latter existing in the latest version, so if at all possible I would recommend upgrading to a recent version of Orbeon Forms. If not possible, you would be left with the painful exercise of simplifying your form up to the point when it works, so to pinpoint exactly what is causing the problem, whether it reveals a bug in Orbeon Forms 3.8 or a problem with your form. – avernet Sep 18 '13 at 23:14
  • It's not an infinite loop, neither in the form or the engine, it's just a huge loop in the engine that gets too big if there are too many objects. I managed to remove the model from my final xbl in this specific case. But I may need it in other cases and I'll have to find another solution. – user2739975 Sep 23 '13 at 08:40
  • If it isn't a problem of infinite loop, you might want to try to increase the stack size. See: http://stackoverflow.com/a/3700576/5295. You'll let us know if this works for you. – avernet Sep 23 '13 at 17:18

0 Answers0