atom feed8 messages in net.sourceforge.lists.exist-openRe: [Exist-open] Stress testing eXist...
FromSent OnAttachments
Ubbo VeentjerMay 17, 2011 7:11 am.txt, .txt, .txt
Casey JordanMay 17, 2011 9:57 am 
Ubbo VeentjerMay 18, 2011 4:47 am.jmx
Wolfgang MeierMay 18, 2011 4:59 am 
Ubbo VeentjerMay 18, 2011 5:11 am 
Wolfgang MeierMay 18, 2011 9:02 am 
Ubbo VeentjerMay 18, 2011 12:23 pm 
Wolfgang MeierMay 19, 2011 2:09 am 
Subject:Re: [Exist-open] Stress testing eXist-1.4.1-rev14438
From:Wolfgang Meier (wolf@exist-db.org)
Date:May 19, 2011 2:09:19 am
List:net.sourceforge.lists.exist-open

2011-05-18 21:14:30,395 [P1-9] WARN  (DOMFile.java [getNodeValue]:2093) - btree error while reading node value org.exist.storage.btree.BTreeException: node 1.1.1.2.3 not found.    at org.exist.storage.dom.DOMFile.findValue(DOMFile.java:1337)    at org.exist.storage.dom.DOMFile.getNodeValue(DOMFile.java:2069)    at org.exist.storage.NativeBroker$14.start(NativeBroker.java:3088) [...]

does this means its uncritical, because its no Error?

This is uncritical if it happens due to dirty node references in a query. For example, if your query does process a node set, it may happen that some nodes in this set get removed by another thread. The query will then just skip those nodes. A problem only arises if the query needs to build a more complex result fragment and the node is removed in between. The generated fragment may then be inconsistent. Otherwise if you don't experience any other failures, I would say it is safe to ignore the warning.

In general, eXist does allow dirty reads unless you use the util:lock functions to keep an explicit lock on a node set.

Wolfgang

------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay