On 1/4/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > i could reproduce the problem easily so i don't need your data anymore, > thanks. > i'll keep you posted...
question - do you have any feeling for what the problem might be? i've spent the last couple of days trying to pin it down and haven't had much luck. i've used ij to examine the node_data value for the root node inside derby, and it doesn't look malformed. i've stepped through with a debugger but been stymied when Serializer descends into DataInputReader (as i don't have the sun jdk sources, don't know if they're available, and couldn't get jswat to decompile rt.jar). my current working hypothesis is that there's a bug in the stream implementation that derby's handing to me via ResultSet.getBinaryStream(). i find those classes extremely confusing tho, so following what's going on inside them is extremely slow going. anyway, every day that i don't get this problem solved is a day our production service is down. so if anybody has ideas of what might be happening, please share - maybe it will be the jolt i need to find the problem and make a fix :) (to summarize the problem - when i add a large number of nodes to the root node, save the session and close the repository, then try to re-open the repository, a premature EOF exception is thrown when deserializing the root node state loaded from the derby PM, specifically when reading the qname of the 1180th child node.)
