Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-3089

HHH-2166 - Long "in" lists in queries results in a Java stack overflow exception.

    XMLWordPrintable

    Details

    • Affects:
      Release Notes
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      the workaround for this issue is something like JBPAPP-3105, just pick it from there, but please note that the limit of this issue is between 9,000 and 10,000, based on your JVM, not 1000
      ---------------
      substitue named-parameterS of clause in by: in(1000-elements) or in(1000-elements) or... if necessary, only if collection.size()>1000.

      If collection.size()>1000 I use regular expression to manipulate original query and get a new query.
      Named-parameters of in clause are replaced by new ins clauses that support 1000 elements each in.

      Example 1 (in):
      entity.identifier in (1,2,3,...,1001) is replaced by entity.identifier in (1,2,3,...,1000) or in (1001)

      Example 1 (not in):
      entity.identifier not in (1,2,3,...,1001) is replaced by not(entity.identifier in (1,2,3,...,1000) or in (1001))

      Show
      the workaround for this issue is something like JBPAPP-3105, just pick it from there, but please note that the limit of this issue is between 9,000 and 10,000, based on your JVM, not 1000 --------------- substitue named-parameterS of clause in by: in(1000-elements) or in(1000-elements) or... if necessary, only if collection.size()>1000. If collection.size()>1000 I use regular expression to manipulate original query and get a new query. Named-parameters of in clause are replaced by new ins clauses that support 1000 elements each in. Example 1 (in): entity.identifier in (1,2,3,...,1001) is replaced by entity.identifier in (1,2,3,...,1000) or in (1001) Example 1 (not in): entity.identifier not in (1,2,3,...,1001) is replaced by not(entity.identifier in (1,2,3,...,1000) or in (1001))

      Description

      This will be a problem in the Hibernate 3.2.4 in the EAP as the NodeTraverser still uses recursion.

      Description from related JIRA:
      =========================
      With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like

      where x in (:x)

      or a manually constructed

      where x in (1,2,3 .....)

      can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.

      The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.

      The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
      =========================

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                stliu Strong Liu
                Reporter:
                sjmenden Samuel Mendenhall
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: