thanks for the quick reply.
Martin Holz wrote:
Oliver Zeigermann <[EMAIL PROTECTED]> writes:
There still seem to be some bugs left, presumably mainly taken over from the reference implementation. We will do our best to further analyze and fix them.
FileResourceManager.saveState() fails for me sometimes,
because it tries to create a file in a nonexisting directory.
Could you give a stacktrace and/or any information under which circumstances this happens?
I did a simple put. Adding a e.printStackTrace at line 1406() gives the following output.
You are right. This exception should have been displayed in logging, but
ResourceManagerException can not handle nested exceptions to be comaptible with Java 1.3. Sorry :(
Need to fix this, but do not know how, maybe incorporating the stack trace in the message...
The work directory exists, but work/Thread-13-1066205894564-11
does not exist. I checked, that the directory does not exists using dir.exists(). Creating this directory will cure the problem
(or at least the syntoms).
This would only cure the symptom. The code on lines 441 and 442
> context = new TransactionContext(txId); > context.init();
ensure directories are created. It looks like the transaction has been cleared before there is a commit. Are you sure there is no other error before this one?
I could not reproduce the error, but do not think this is due to NFS and Linux, but my last resort will be to check it under this environment.
As a first approach, you might try to increase the timeout in line 117 as 2 seconds actually are far too little. Try 200 seconds to be on the save side. Maybe this helps:
> protected static final int DEFAULT_TIMEOUT_MSECS = 200000;
I am using Java 1.4.1 on a Suse Linux 8.2 / Intel Single CPU.
Both the work and the data directory live on the same partition,
which is mounted via NFS.
java.io.FileNotFoundException: /home/holz/slidedata/data/work/Thread-13-1066205894564-11/transaction.log (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:176) at java.io.FileOutputStream.<init>(FileOutputStream.java:131) at org.apache.slide.store.txfile.rm.impl.FileResourceManager$TransactionContext.saveState(FileRe sourceManager.java:1401) at org.apache.slide.store.txfile.rm.impl.FileResourceManager.commitTransaction(FileResourceManag er.java:561) at org.apache.slide.store.txfile.AbstractTxFileStoreService.commit(AbstractTxFileStoreService.ja va:180) at org.apache.slide.transaction.SlideTransaction.commit(SlideTransaction.java:347) at org.apache.slide.transaction.SlideTransactionManager.commit(SlideTransactionManager.java:230) at org.apache.slide.common.NamespaceAccessTokenImpl.commit(NamespaceAccessTokenImpl.java:462) at org.apache.slide.webdav.method.AbstractWebdavMethod.run(AbstractWebdavMethod.java:356) at org.apache.slide.webdav.WebdavServlet.service(WebdavServlet.java:201)
Finally a HeuristicMixedException is thrown and no more operations are possible, until I restart the webdav servlet.
A minor point, shouldn't you use File dir = new File(workDir,txId) instead of File dir = new File(workDir + "/" + txId) at line 11397 to make sure the program runs on Windows?.
Well, I actually developed the store on Windows. So it does run on Windows :)
Did you mean the "/" vs. "\" - this is no problem on Windows any more - or something else I was missing?
Would you say using ctor File(String, String) generally is better practice than concatenating paths using "/"? What if you have more than two paths to concat like in 1397:
> String statePath = workDir + "/" + txId + "/" + CONTEXT_FILE;
I am just wondering and discussing this issue, I do not try to defend my stuff...
I will come back to you when I have more information. For nowt hanks for you cooperation :)
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
