On 1/10/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
> can you post those stack traces? that will probably help to find out
> what could have caused the problem.
the stack trace is:
2006-01-09 14:42:53,882 ERROR [ObservationManagerFactory] Synchronous EventConsu
mer threw exception.
java.lang.ThreadDeath
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1221)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1181)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.osaf.cosmo.jackrabbit.query.TextCalendarTextFilter.doFilter(TextC
alendarTextFilter.java:114)
at org.apache.jackrabbit.core.query.lucene.NodeIndexer.addBinaryValue(No
deIndexer.java:288)
at org.apache.jackrabbit.core.query.lucene.NodeIndexer.addValue(NodeInde
xer.java:219)
at org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDoc(NodeInd
exer.java:158)
at org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDocument(No
deIndexer.java:112)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.createDocument(Se
archIndex.java:389)
at org.apache.jackrabbit.core.query.lucene.SearchIndex$2.next(SearchInde
x.java:247)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.update(MultiIndex.
java:298)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.updateNodes(Searc
hIndex.java:234)
at org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:2
71)
at org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(Ev
entConsumer.java:246)
at org.apache.jackrabbit.core.observation.ObservationManagerFactory.disp
atchEvents(ObservationManagerFactory.java:220)
at org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(
EventStateCollection.java:413)
at org.apache.jackrabbit.core.state.SharedItemStateManager.store(SharedI
temStateManager.java:575)
at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalIt
emStateManager.java:344)
at org.apache.jackrabbit.core.state.TransactionalItemStateManager.update
(TransactionalItemStateManager.java:276)
at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalIt
emStateManager.java:306)
at org.apache.jackrabbit.core.state.SessionItemStateManager.update(Sessi
onItemStateManager.java:260)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1153)
at org.apache.jackrabbit.webdav.simple.DavResourceImpl.addMember(DavReso
urceImpl.java:508)
at org.apache.jackrabbit.server.AbstractWebdavServlet.doPut(AbstractWebd
avServlet.java:511)
at org.osaf.cosmo.dav.CosmoDavServlet.doPut(CosmoDavServlet.java:195)
the relevant line in TextCalendarTextFilter is:
InternalValue[] values = data.getValues();
where data is a PropertyState passed into the doFilter() method. the
full source is at
<http://svn.osafoundation.org/server/cosmo/trunk/src/main/java/org/osaf/cosmo/jackrabbit/query/TextCalendarTextFilter.java>.
> if you see OutOfMemoryExceptions this might be due to:
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/5026
yeah, now that i'm using queries more often, i need to update to bring
in that memory leak fix. still, we've observed that in production the
whole shebang (cosmo + tomcat + jackrabbit + derby) requires a pretty
beefy amount of memory for normal operation. in production we use
jrockit on linux with 400m heap and a lot of gc tweaks, whereas this
problem occurred on a dev box running sun on os x with no JAVA_OPTS.
> there is a configuration parameter that controls how long the volatile
> part of the index is held in memory: volatileIdleTime
> per default the volatile index is written to disk after 3 seconds.
doesn't sound like that has any bearing on this problem, then.
> if you want to rebuild the index you have to shutdown jackrabbit and
> delete the index manually and then restart. it is not possible to
> re-index a workspace while it is in use.
okay, thanks.
