With current eXist versions you have to find a compromise between query speed and update costs: storing all documents into a single collection results in fast queries. The drawback is that removing or replacing documents can become really slow! On the other hand, using one collection per document would guarantee that document updates run in linear time, but the query overhead would be considerable.
So if you need reasonable fast updates, the recommendation is to keep the number of documents in one collection below 2000 or so. Otherwise, if you never delete documents, you can easily store some 100,000 docs into one collection.
We plan to redesign the current index organization in the coming months.
Probably you use the default installed java version, gnu classpath/gjc. We recommend the Sun JVM, but JVMs of other vendors should work as well
Search for "gjc" in the errormessages:
java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(libgcj.so.70) at java.io.ObjectInputStream.read(libgcj.so.70 ) at java.io.InputStream.skip(libgcj.so.70) at com.izforge.izpack.installer.Unpacker.run(Unpacker.java:425) at java.lang.Thread.run(libgcj.so.70)
or
12 Aug 2008 16:34:31,161 [P1-9] WARN (ServletHandler.java [handle]:629) - Error for /exist/logo.jpg java.lang.NoClassDefFoundError: org.apache.cocoon.reading.ImageReader at java.lang.Class.initializeClass(libgcj.so.81) at java.lang.Class.newInstance(libgcj.so.81)
or
Exception in thread "main" java.lang.InternalError: unexpected exception during linking: java.lang.ClassNotFoundException: javax.swing.JFrame at 0x004f8ca3: java.lang.Throwable.Throwable(java.lang.String) (/usr/lib/./libgcj.so.3) at 0x004ebb1e: java.lang.Error.Error(java.lang.String) (/usr/lib/./libgcj.so.3) at 0x004f9086: java.lang.VirtualMachineError.VirtualMachineError(java.lang.String) (/usr/lib/./libgcj.so.3)
ant can help you out to determine the java version:
ant -diagnostics | grep java.vm
or
build.sh diagnostics | grep java.vm
results in
java.vm.version : 1.5.0_13-119 java.vm.vendor : Apple Inc. java.vm.name : Java HotSpot(TM) Client VM java.vm.specification.name : Java Virtual Machine Specification java.vm.specification.vendor : Sun Microsystems Inc. java.vm.specification.version : 1.0 java.vm.info : mixed mode
There are indeed limitations regarding the functionality of the "validation:" functions, due to restrictions of tomcat. These are very vague.
The war files are tested and should work. Be sure that tomcat is not setup with the "SecurityManager" enabled (we should work this out) and that (for older versions of tomcat) all relevant XML jar files (xerces, resolver, xalan) have been installed in the 'endorsed' directory.
For more information check our documentation.
Probably you see something like
while the exception reads like:
The solution is to re-sign the jar files:
build.sh -f build/scripts/jarsigner.xml jnlp-unsign-all jnlp-sign-all
If your db instance crashed (e.g. by running out of memory or other fatal errors), eXist will usually trigger an automatic recovery run, which should restore the database into a consistent state.
However, it sometimes happens that the recovery fails or you start seeing fatal exceptions in the logs, even though the recovery completed normally. In this case, it might be necessary to restart with a clean environment (which is also important when debugging an error).
Before cleaning the db, you need to create a backup of your data. For older eXist versions, use the Java admin client to create a backup. Since version 1.2.1, eXist also provides a check and export tool, which has the advantage that it will test your db for errors before running the export.
If you have problems to even start the db, try removing all .log files from the webapp/WEB-INF/data directory.
Stop the database instance if you have not already done so and remove all files from the webapp/WEB-INF/data directory. eXist will recreate those files the next time it is started.
Restart eXist. The db should now be empty and you can restore the previously created backup using the Java admin client.