This doesn't sound like a limit with the number of nodes. Rather, it
sounds like a limit with the number of unique string indexes, perhaps for
attribute values?
There is certainly a limit to the number of unique element names... 32K (16
bits), and the number of unique namespaces is limited to 1023 (10 bits). I
wouldn't think that this would be a problem.
This is more likely a bug with a trick done with attribute values where a
negative value is used to indicate that the value lives in another table?
-scott
Joseph_Kesselman
@lotus.com To: [EMAIL PROTECTED]
cc: (bcc: Scott Boag/CAM/Lotus)
07/17/01 11:28 Subject: Re: String indexoutof range
exception
AM
Please respond
to xalan-dev
The DTM model can indeed run out of space if a source document is too
large. Currently we allocate 20 bits for node addressing, so we can handle
about a million nodes. Beyond that we'll fail, probably nondiagnostically.
We're considering increasing that, though doing so will impose tighter
limits on how many documents a given DTMManager can keep track of
simultaneously. We could remove the restriction by switching to longs as
our basic node ID type, but that would increase storage and processing
The size of _text_ nodes shouldn't be a problem... I think.
Could you show us a complete stack trace of the exception, so we can
investigate where the problem is occurring?
- String indexoutof range exception Gerry McDonough
- Re: String indexoutof range exception Myriam_Midy
- Re: String indexoutof range exception Joseph_Kesselman
- RE: String indexoutof range exception Gerry McDonough
- RE: String indexoutof range exception Scott_Boag
- RE: String indexoutof range exception Myriam_Midy
- RE: String indexoutof range exception Gerry McDonough
- RE: String indexoutof range exception Joseph_Kesselman
- RE: String indexoutof range exception Gerry McDonough
