我一整天都在寻找这个问题的答案。 我正在为中等大小的XML文档（~1.5MB，~1000个元素）创建样式表，这给我带来了很多麻烦。它是关于为不同的加工厂设备创建事件 - 时间线图。 XML是通过SAP MII QueryTempalte thingy生成的，并且采用/ Rowsets / Rowset / Row格式。所有这些数据都以/设备/设备/事件格式处理并存储在本地节点集中。 然后将此节点集处理为HTML，然后在浏览器中呈现。 现在，我开始遇到麻烦了。我可以轻松地提取过去5天的数据，从而导致来自MII的约900行数据，并被处理为我的节点格式，导致不到900行。但第二个我从MII获取了1017行，样式表只会渲染大约一半，然后停止并且“没有更多的DTM ID可用”异常。 现在，MII服务器只运行JDK 1.5.x，我读过，这可能是一个问题 - 唯一的问题是，我对此无能为力。 所以现在我在这里问：有没有办法优化我的代码？我为我的XSL和示例XML附加了一些链接。
XSL：http://pastie.org/1566517 Samlpe XML：http://pastie.org/1566522
现在，示例XML可能不会产生任何“有趣”的可视结果，并且无法复制错误。但如果有人能发现obvoius优化，我很想知道:) 我一直在想，替换/移动startOffset，endOffset等的计算会很好，但我无法弄清楚如何。
希望有人可以帮助我！ ：）答案 0 :(得分：5)
我们也遇到了这个问题与不同的应用程序，错误的基础是相同的。如上所述，基本问题是xalan, Apache project处理 xslt 文档的限制。虽然这种限制很少被触发，但是由于耗尽了最大数量的65535（16位）DTM ID。在上面的应用程序中，显然可以通过在SAP中使用资源分配效率功能来避免这种情况，但这将不适用于其他应用程序，例如我们正在使用的应用程序。
总之，65K DTM id限制已经存在了一段时间（ca 2003），经过修补，然后丢失了 2.7 分支中的补丁。目前最新版本的2.7.2存在这个问题。在最基本的级别，文档ID是32位整数。修复是源代码更改，增加了为DTM留出的位数。可以查看更全面的讨论here。建议的hack是将节点位数更改为12，从而将DTM的数量增加到20，将总DTM增加到1048576.步骤
IDENT_DTM_NODE_BITS的行来解压缩并修改src / org / apache / xml / dtm / DTMManager.java。答案 1 :(得分：2)
知道这个问题已经过时了，但我自己也遇到了同样的问题，对于那些也发现这个问题的人来说，似乎有一个SAP Note详细说明了可以解决这个问题的JVM补丁：
请注意＃1604623
https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1604623
说明中的一个修正是：
改进了XSLT转换的资源消耗。我们修好了 XSLT处理中的资源泄漏将导致错误 对于使用的复杂XSL，“DTMException：不再有DTM ID可用” （递归）模板。问题的原因是，那 处理步骤的中间结果存储在DTM和 DTM的数量限制为65536。
通过此更改，有一个新的系统属性 “com.sap.jvm.xsltc.enableResourceOptimization”。如果这个属性是 设置为“true”，XSLT编译器将发布中间结果和 因此需要更少的资源。处理复杂的XSL应该 有可能。请注意，默认情况下不会设置此系统属性。