Our application running on linux environment is all of a sudden starting throwing below error . Can someone suggest whats the problem . Our user flow is trying to update local copy of files from Apache SVN
could you share the full stack trace? It could help in the analisys.
Usually this error means some IO or permissions problems of .svn/wc.db file. Could you check its permissions and whether it is readable? Not only .svn/wc.db should be readable/writable but also the directory where it resides (to create a journal file alongside with it) and also the temp directories: .svn/tmp and /tmp (or another directory if you have “java.io.tmpdir” JVM property set).
As I understand, the problem never happened before in your environment and since some moment it’s 100% reproducible, right? Do you have any idea what could have changed?
Issue is intermittent , during a day its reported for few set of users while at same time other users it works. Every user has its own dump of SVN workspace on which application is trying to bring update from SVN at login time.
svn: E200030: CANTOPEN
org.tmatesoft.sqljet.core.SqlJetException: CANTOPEN: error code is CANTOPEN at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileSystem.open(SqlJetFileSystem.java:188) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3003) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2782) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$9.runSynchronized(SqlJetEngine.java:475) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:471) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:213) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:264) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:259) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:4150) at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1512) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:38) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
Thanks for the stack trace! According to it, SVNKit/SQLJet tries to create a journal file and fails to do that for some reason (FileNotFoundException which can happen not only if the file is absent but also due to permissions problems). The journal file is located in the same directory as .svn/wc.db database: .svn/wc.db-journal. I can’t say why this file cannot be created or opened in write mode our your users’ machines intermittently. Is it possible due to e.g. antiviral software preventing files from creation or interfering to cause such errors? Are you using Windows? On Windows SQLJet has 100 retries for file creation by default. It would be strange if that were not enough but one of the suggestions is to increase this number using JVM property:
If you’re using SVNKit programmatically, as a quick work-around for the period of investigation, you can turn journal off globally:
This would disable wc.db-journal completely replacing it with in-memory operations.
So far I have no other idea why this file cannot be created. Maybe it would make sense to create such a file manually and see if this is possible at all (of course with application not running – not to interfere its normal operations).