Re: [Exist-open] Database corruption - killed scheduled backup

[dthomason <dth...@ut...>]

Congrats on the eXist Solutions spinoff!

Ran into the same problem again after upgrading to 1.4.1dev:  node update
corrupts the database and halts automatic updates. Appears to be random, so
I don¹t have a test case. The replaced node in the resources is not large,
generally <100kB. Can¹t do much to control size as the node contains
narrative in its children. The collection of resources that is operated on
has about 400 resources. There is a collection of binary ³attachments² to
these resources that numbers ~15,000, but these are not operated on (only
put and get).

The node update expression is in cocoon flowscript (some processing details
are left out):
// get the node
var pipelineUtil = 
cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.Pipeline
Util);
var bizdata = { "dbdocumentURI" : dbdocumentURI };  //URI for cocoon
pipeline to xquery the db and return the node to be edited
var document = pipelineUtil.processToDOM(dbdocumentURI, bizdata);
cocoon.disposeObject("pipelineUtil");
... form processing for editing the node data ...
// convert returned form DOM object to xml string
var changedNode = DOMUtil.getSingleNode(document, pathString); // get the
node that contains edited data
var props = XMLUtils.createPropertiesForXML(true);  //no xml declaration
 // serialize the protocol node dom to a string
var docXML = XMLUtils.serializeNode(changedNode, props);
// build xupdate xml string
var xupdate = '<?xml version="1.0" encoding="UTF-8"?>\n';
xupdate += '<xu:modifications version="1.0"
xmlns:xu="http://www.xmldb.org/xupdate">\n';
// the location of the node is that is to be replaced. Can¹t easily do
xu:update because we don¹t know outright which children have been changed
xupdate += '<xu:replace select="/Root/Protocol_node[Protocol_no = \'' +
protocolno + '\']">\n';
xupdate += docXML;
xupdate += '</xu:replace>\n';
xupdate += '</xu:modifications>\n';
// get the RemoteCollection object using the xmlrpc interface
var colSrc = java.lang.String("xmldb:exist://" + dbServer + "/xmlrpc/" +
protocolCollection);
var col = Collection(DatabaseManager.getCollection(colSrc, dbUser,
dbPassword));
var service = col.getService("XUpdateQueryService", "1.0"); // get update
service
service.updateResource(director + ".xml", xupdate); // update


Many thanks for any insight.

on 2/3/11 2:25 AM, Wolfgang Meier at wol...@ex... wrote:

> It would be interesting to see the actual node update expressions which seem
> to be causing this. I guess the replaced node is rather large? Known indexing
> bugs in 1.4.0 might play a role here, so upgrading to 1.4.x could help.
> 
> As for the killed backup, I'm not sure why it stops. Again, the system task
> scheduling has changed in 1.4.x to make it more reliable.
> 
> Finally, the client should be able to restore from the zip unless the zip
> itself is incomplete or damaged.
> 
> Wolfgang
> 
>> Am 03.02.2011 09:06 schrieb "dthomason" <dth...@ut...>:
>> 
>> 
>>> Thanks in advance for any ideas.
>>> 
>>> Exist ver 1.4.0 on Xserve3,1 (quad core Intel) 24Gb OS 10.5....
>