EXSLT：没有更多可用的 DTM ID
我一整天都在寻找这个问题的答案。 我正在为中等大小的 XML 文档（~1.5MB，~1000 个元素）创建样式表，这给我带来了很多麻烦。它是关于为不同的加工厂设备创建事件时间线图。 XML 通过 SAP MII QueryTempalte 生成，采用 /Rowsets/Rowset/Row 格式。所有这些数据均以 /Equipments/Equipment/Event 格式处理并存储在本地节点集中。 然后，该节点集被处理为 HTML，然后在浏览器中呈现。 现在，我开始遇到一些麻烦了。我可以轻松地提取过去 5 天的数据，这会从 MII 中获取大约 900 行数据，并处理为我的节点格式，从而得到略低于 900 行的数据。但当我从 MII 获取 1017 行时，样式表将仅呈现大约一半，然后停止并出现“没有更多 DTM ID 可用”异常。 现在，MII 服务器仅运行 JDK 1.5.x，我读到，这可能是一个问题 - 唯一的问题是，我对此无能为力。 所以现在我在这里问：有没有办法优化我的代码？我已附加一些 XSL 链接和示例 XML。
XSL：http://pastie.org/1566517 XML 示例：http://pastie.org/1566522
现在，示例 XML 可能不会产生任何“有趣”的视觉效果结果，并且将无法复制该错误。但如果有人能发现明显的优化，我很想知道:) 我一直在想，替换/移动 startOffset、endOffset 等的计算会很好，但我不知道如何做。
希望有人能帮助我！ :)
I've been searching for an answer to this problem all day long.
I'm creating a stylesheet for a moderate-sized XML document (~1.5MB, ~1000 elements), which is giving me a lot of trouble. It's about creating an event-time line graph for different processing plant equipments.
The XML is generated through the SAP MII QueryTempalte thingy, and is in an /Rowsets/Rowset/Row-format. All this data is processed and stored in a local node-set, in a /Equipments/Equipment/Event format.
This node-set is then processed into HTML, and then rendered in the browser.
Now, I'm starting to run into some trouble. I can easily pull data for the past 5 days, which result in ~900 rows of data from MII, and is processed to my node-format, resulting in just under 900 rows. But the second i hit 1017 rows fetched from MII, the stylesheet will only render about half-ways, and then stops and the "No more DTM IDs are available" exception.
Now, the MII server only runs JDK 1.5.x, and I've read, that that might be a problem - only thing is, I can't do anything about that.
So now I'm asking here: Is there a way to optimize my code?? I've attached some links for my XSL and a sample XML.
XSL: http://pastie.org/1566517
Samlpe XML: http://pastie.org/1566522
Now, the sample XML might not yield any "fun" visual results, and won't be able to replicate the error. But if anyone could spot an obvoius optimization, I'd love to know :)
I've been thinking, that it would be nice to replace/move the calculations for startOffset, endOffset, etc, but i can't figure out how.
Hope someone can help me! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
后续
我们也在不同的应用程序中遇到了这个问题，错误的基础是相同的。正如上面提到的，根本问题是 Apache 项目 xalan 的限制 用于处理xslt 文档。该限制虽然很少触发，但由于耗尽了 65535（16 位）DTM id 的最大数量而导致。在上述应用程序中，显然，通过使用 SAP 中的资源分配效率功能可以避免这种情况，但这不适用于其他应用程序，例如我们正在使用的应用程序。
更改 Xalan
总之，65K DTM id 限制已经存在了一段时间（大约 2003 年），已修补，然后在 2.7 分支中丢失了该修补程序。当前最新版本2.7.2存在此问题。在最基本的层面上，文档 ID 是一个 32 位整数。修复方法是更改源代码，增加为 DTM 预留的位数。可以在此处查看更全面的讨论。建议的破解是将节点位数更改为 12，从而将 DTM 的位数增加到 20，将 DTM 总数增加到 1048576。步骤
IDENT_DTM_NODE_BITS的行来解压并修改 src/org/apache/xml/dtm/DTMManager.java 。A Followup
We also encountered this problem with a different application, the basis of the error is the same. As alluded to above the fundamental problem is a limitation of the xalan, Apache project for processing xslt documents. The limitation, though triggered rarely, results from exhausting the maximum number of 65535 (16 bits worth of) DTM ids. In the above application, this is avoided, apparently, by using a resource allocation efficiency feature in SAP, but this will be inapplicable to other applications such as the one we were are using.
Changing Xalan
In summary, the 65K DTM id limitation has been around for a while (ca 2003), was patched, and then lost the patch in the 2.7 branch. The current, latest version of 2.7.2 has this problem. At its most basic level, a document id is a 32-bit integer. The fix is a source code change that increases the number of bits set aside for DTM. A more thorough discussion can be viewed here. The suggested hack is to change the number of node-bits to 12 thus increasing that for DTM to 20 increasing total DTM to 1048576. The steps are
IDENT_DTM_NODE_BITS.知道这个问题已经很老了，但我自己也遇到了同样的问题，对于那些也发现这个问题的人来说，似乎有一个 SAP 注释详细说明了 JVM 补丁，可以解决这个问题：
Note#1604623
https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1604623
注释中的修复之一是：
Know this question is old but just hit the same question myself, for those who also find this issue looks like there is a SAP Note detailing a JVM patch which may resolve this:
Note#1604623
https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1604623
One of the fixes in the note is: