Yes, this is a known limit. I thought that these days it would fail cleanly saying the limit had been exceeded, but it seems that's not the case on this path.

There's a pathological Apache application - I've forgotten which - that generates XML in which a new namespace prefix is allocated (for the same namespace URI) on every element instance. The Saxon NamePool can't handle that. I don't know if that's the situation here. (In fact, I think that example would hit a different limit, namely a maximum of 1024 prefixes per namespace URI).

Devising a workaround involves understanding why the application is using such a vast number of different namespace prefixes. Is it generating prefixes at random for a small and stable set of namespace URIs? If that's the case, then one could insert a SAX filter to normalize the prefixes (assuming they don't also appear in content). On the other hand, if the number of namespace URIs is also very large, then one might have to look at ways of using multiple Saxon instances to handle the workload.

Michael Kay
Saxonica


On 07/08/2011 21:55, Scott Robey wrote:
I have an application using Saxon HE (9.3.0.5j) and JAX-WS/JAXB. During stress testing, after the application has processed several thousand XML messages, the following exception gets thrown repeatedly, and the application becomes unable to process XML until the JVM is cycled.

java.lang.ArrayIndexOutOfBoundsException: -32768
    at net.sf.saxon.om.NamePool.allocateCodeForPrefix(NamePool.java:483)
    at net.sf.saxon.om.NamePool.allocate(NamePool.java:563)
    at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingContentHandler.java:405)
    at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:289)

I've looked at the NamePool source, and it appears that the NamePool object referenced by the Configuration object has a limitation of only being able to handle ~32000 different namespace prefixes throughout the life of the application. My question is: is this a known and accepted limitation of the Saxon XSLT processor? Is there any way I can work around the issue given that JAXB is creating the TransformerFactory, and I have no control over its lifecycle?

The following JUnit test demonstrates the problem. The test case fails consistently when using the Saxon processor, and the test case passes reliably when using the standard JDK's TransformerFactory.

  @Test
  public void testArrayIndexOutOfBoundsException() throws Exception {
    final long MAX = 33000;
    final String XML_TEMPLATE = "<ns%1$s:element xmlns:ns%1$s=\"urn:ns1\">test</ns%1$s:element>";
   
    TransformerFactory factory = TransformerFactory.newInstance();
    System.out.println("TransformerFactory: " + factory);
    for ( long i = 0; i < MAX; i++ ) {
      String xml = String.format(XML_TEMPLATE,  i);
      DOMResult result = new DOMResult();
      try {
        factory.newTransformer().transform(
          new StreamSource(new ByteArrayInputStream(xml.getBytes())), result);
      }
      catch ( Exception e ) {
        e.printStackTrace();
        Assert.fail("After: " + i + " iterations. " + e);
      }
    }
  }  

Any insight is appreciated.

thanks,
Scott



------------------------------------------------------------------------------ BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________ saxon-help mailing list archived at http://saxon.markmail.org/ saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help