[jira] Commented: (CONNECTORS-114) Derby seems too unstable in multithreaded situations to be a good database for ManifoldCF, so try to add support for HSQLDB
[ https://issues.apache.org/jira/browse/CONNECTORS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920227#action_12920227 ] Karl Wright commented on CONNECTORS-114: Support added and checked in. However, when I try to use hsqldb for an actual crawl, in less than 10 seconds I wind up with a java-level thread deadlock. I've posted the thread dump to connectors-dev. All the locks seem to be deep inside hsqldb, FWIW, which leads me to believe that perhaps hsqldb is even less stable than Derby in a multithread environment. Derby seems too unstable in multithreaded situations to be a good database for ManifoldCF, so try to add support for HSQLDB --- Key: CONNECTORS-114 URL: https://issues.apache.org/jira/browse/CONNECTORS-114 Project: ManifoldCF Issue Type: Bug Components: Framework core Reporter: Karl Wright Derby seems to have multiple problems: (1) It has internal deadlocks, which even if caught cause poor performance due to stalling (CONNECTORS-111); (2) It has no support for certain SQL constructs (CONNECTORS-109 and CONNECTORS-110); (3) It locks up entirely for some people (CONNECTORS-100). HSQLDB has been recommended as another potential embedded database that might work better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: hsqldb deadlock
maybe the problem is indicative of a bug in LCF? I think its strange that there are locking problems with Derby, too. That being said, maybe as a quick fix you could try SET DATABASE TRANSACTION CONTROL MVCC or SET DATABASE TRANSACTION CONTROL MVLOCKS, since i see you are using two phase locking: http://hsqldb.org/doc/2.0/guide/sessions-chapt.html#sqlgeneral_trans_cc-sect On Sun, Oct 10, 2010 at 9:18 AM, karl.wri...@nokia.com wrote: Does anybody have experience with hsqldb? I'm getting a java thread deadlock within about 10 seconds of running a job. I want to know if anyone has seen this before, or has used hsqldb in a massively multithreaded environment. Found one Java-level deadlock: = Thread-745: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Thread-725: waiting to lock monitor 0x04614284 (object 0x2927b550, a org.hsqldb.persist.Lo bManager), which is held by Thread-732 Thread-732: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Java stack information for the threads listed above: === Thread-745: at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x293b0b70 (a java.util.concurrent.locks.Reentr antReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen trantReadWriteLock.java:807) at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.executeDirectStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23dc38d0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source) - locked 0x23dc6fc0 (a org.hsqldb.jdbc.JDBCStatement) at org.apache.manifoldcf.core.database.Database.execute(Database.java:52 6) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D atabase.java:381) Thread-725: at org.hsqldb.persist.LobManager.adjustUsageCount(Unknown Source) - waiting to lock 0x2927b550 (a org.hsqldb.persist.LobManager) at org.hsqldb.SessionData.adjustLobUsageCount(Unknown Source) at org.hsqldb.TransactionManagerCommon.persistCommit(Unknown Source) at org.hsqldb.TransactionManager2PL.commitTransaction(Unknown Source) at org.hsqldb.Session.commit(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown Source) - locked 0x23ca8038 (a org.hsqldb.jdbc.JDBCPreparedStatement) at org.apache.manifoldcf.core.database.Database.execute(Database.java:56 6) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D atabase.java:381) Thread-732: at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x293b0b70 (a java.util.concurrent.locks.Reentr antReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen trantReadWriteLock.java:807) at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.persist.LobManager.createClob(Unknown Source) - locked 0x2927b550 (a org.hsqldb.persist.LobManager) at org.hsqldb.Session.createClob(Unknown Source) at org.hsqldb.jdbc.JDBCPreparedStatement.performPreExecute(Unknown Sourc e) at
Re: hsqldb deadlock
A brief conversation here with people who purportedly know hsqldb from an earlier life shows that my experience is by no means unusual. Hsqldb has apparently had problems of this kind since day one, and people who have experience with it tend to only use it in single-threaded environments. Karl On Tue, Oct 12, 2010 at 11:44 AM, Karl Wright daddy...@gmail.com wrote: Technically, a database is supposed to throw a sqlexception of a specific variety if deadlock occurs, not just hang due to thread lock. Indeed, if this is the way hsqldb handles deadlock it is not usable, because we *expect* there to be a possibility of deadlock under some conditions, and have coded backoff and retry when this is detected. Pre-locking everything under the sun is not an option because of the severe impact that has on performance. PostgreSQL has no problem with handling database deadlocks when they arise, FWIW. Derby also handles deadlocks, but at the cost of a timeout expiration of a minute, which is fine if the deadlocks are rare. In Derby's case, though, the deadlock occurs when you have one thread deleting rows based on a condition, and the second adding a row, and neither one of these in a transaction. That's a pretty lame excuse for deadlock, seems to me. I will try MVCC - maybe that will help. Karl On Tue, Oct 12, 2010 at 11:33 AM, Robert Muir rcm...@gmail.com wrote: maybe the problem is indicative of a bug in LCF? I think its strange that there are locking problems with Derby, too. That being said, maybe as a quick fix you could try SET DATABASE TRANSACTION CONTROL MVCC or SET DATABASE TRANSACTION CONTROL MVLOCKS, since i see you are using two phase locking: http://hsqldb.org/doc/2.0/guide/sessions-chapt.html#sqlgeneral_trans_cc-sect On Sun, Oct 10, 2010 at 9:18 AM, karl.wri...@nokia.com wrote: Does anybody have experience with hsqldb? I'm getting a java thread deadlock within about 10 seconds of running a job. I want to know if anyone has seen this before, or has used hsqldb in a massively multithreaded environment. Found one Java-level deadlock: = Thread-745: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Thread-725: waiting to lock monitor 0x04614284 (object 0x2927b550, a org.hsqldb.persist.Lo bManager), which is held by Thread-732 Thread-732: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Java stack information for the threads listed above: === Thread-745: at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x293b0b70 (a java.util.concurrent.locks.Reentr antReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen trantReadWriteLock.java:807) at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.executeDirectStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23dc38d0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source) - locked 0x23dc6fc0 (a org.hsqldb.jdbc.JDBCStatement) at org.apache.manifoldcf.core.database.Database.execute(Database.java:52 6) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D atabase.java:381) Thread-725: at org.hsqldb.persist.LobManager.adjustUsageCount(Unknown Source) - waiting to lock 0x2927b550 (a org.hsqldb.persist.LobManager) at org.hsqldb.SessionData.adjustLobUsageCount(Unknown Source) at org.hsqldb.TransactionManagerCommon.persistCommit(Unknown Source) at org.hsqldb.TransactionManager2PL.commitTransaction(Unknown Source) at org.hsqldb.Session.commit(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown Source) - locked 0x23ca8038 (a
[jira] Updated: (CONNECTORS-115) Restarting the example fails when db present
[ https://issues.apache.org/jira/browse/CONNECTORS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farzad updated CONNECTORS-115: -- Description: When you restart the example you get the following: C:\Program Files\Apache\apache-acf\examplejava -jar start.jar Configuration file successfully read org.apache.manifoldcf.core.interfaces.ManifoldCFException: Database exception: Exception doing query: ERROR: database d bname already exists at org.apache.manifoldcf.core.database.Database.executeViaThread(Database.java:421) at org.apache.manifoldcf.core.database.Database.executeUncachedQuery(Database.java:465) at org.apache.manifoldcf.core.database.Database$QueryCacheExecutor.create(Database.java:1072) at org.apache.manifoldcf.core.cachemanager.CacheManager.findObjectsAndExecute(CacheManager.java:144) at org.apache.manifoldcf.core.database.Database.executeQuery(Database.java:167) at org.apache.manifoldcf.core.database.DBInterfacePostgreSQL.createUserAndDatabase(DBInterfacePostgreSQL.java:50 8) at org.apache.manifoldcf.core.system.ManifoldCF.createSystemDatabase(ManifoldCF.java:638) at org.apache.manifoldcf.jettyrunner.ManifoldCFJettyRunner.main(ManifoldCFJettyRunner.java:202) Caused by: org.postgresql.util.PSQLException: ERROR: database dbname already exists at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:329) at org.apache.manifoldcf.core.database.Database.execute(Database.java:526) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(Database.java:381) C:\Program Files\Apache\apache-acf\example The only way to get it started is dropping the table it created the first time, in this case dbname. was: When you restart the example you get the following: Environment: Windows XP, Example running with PostgreSQL instead of embedded derby. Use defaults for dbname, user, and password. (was: Windows XP, Example running with PostgreSQL instead of embedded derby) Restarting the example fails when db present Key: CONNECTORS-115 URL: https://issues.apache.org/jira/browse/CONNECTORS-115 Project: ManifoldCF Issue Type: Bug Environment: Windows XP, Example running with PostgreSQL instead of embedded derby. Use defaults for dbname, user, and password. Reporter: Farzad When you restart the example you get the following: C:\Program Files\Apache\apache-acf\examplejava -jar start.jar Configuration file successfully read org.apache.manifoldcf.core.interfaces.ManifoldCFException: Database exception: Exception doing query: ERROR: database d bname already exists at org.apache.manifoldcf.core.database.Database.executeViaThread(Database.java:421) at org.apache.manifoldcf.core.database.Database.executeUncachedQuery(Database.java:465) at org.apache.manifoldcf.core.database.Database$QueryCacheExecutor.create(Database.java:1072) at org.apache.manifoldcf.core.cachemanager.CacheManager.findObjectsAndExecute(CacheManager.java:144) at org.apache.manifoldcf.core.database.Database.executeQuery(Database.java:167) at org.apache.manifoldcf.core.database.DBInterfacePostgreSQL.createUserAndDatabase(DBInterfacePostgreSQL.java:50 8) at org.apache.manifoldcf.core.system.ManifoldCF.createSystemDatabase(ManifoldCF.java:638) at org.apache.manifoldcf.jettyrunner.ManifoldCFJettyRunner.main(ManifoldCFJettyRunner.java:202) Caused by: org.postgresql.util.PSQLException: ERROR: database dbname already exists at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:329) at org.apache.manifoldcf.core.database.Database.execute(Database.java:526) at
[jira] Commented: (CONNECTORS-115) Restarting the example fails when db present
[ https://issues.apache.org/jira/browse/CONNECTORS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920250#action_12920250 ] Karl Wright commented on CONNECTORS-115: I believe I stumbled over this on Friday and fixed it. Can you synch up and try again? Bear in mind that you will need to drop the database anyway once, because the username has change from lcf to manifoldcf. Restarting the example fails when db present Key: CONNECTORS-115 URL: https://issues.apache.org/jira/browse/CONNECTORS-115 Project: ManifoldCF Issue Type: Bug Environment: Windows XP, Example running with PostgreSQL instead of embedded derby. Use defaults for dbname, user, and password. Reporter: Farzad When you restart the example you get the following: C:\Program Files\Apache\apache-acf\examplejava -jar start.jar Configuration file successfully read org.apache.manifoldcf.core.interfaces.ManifoldCFException: Database exception: Exception doing query: ERROR: database d bname already exists at org.apache.manifoldcf.core.database.Database.executeViaThread(Database.java:421) at org.apache.manifoldcf.core.database.Database.executeUncachedQuery(Database.java:465) at org.apache.manifoldcf.core.database.Database$QueryCacheExecutor.create(Database.java:1072) at org.apache.manifoldcf.core.cachemanager.CacheManager.findObjectsAndExecute(CacheManager.java:144) at org.apache.manifoldcf.core.database.Database.executeQuery(Database.java:167) at org.apache.manifoldcf.core.database.DBInterfacePostgreSQL.createUserAndDatabase(DBInterfacePostgreSQL.java:50 8) at org.apache.manifoldcf.core.system.ManifoldCF.createSystemDatabase(ManifoldCF.java:638) at org.apache.manifoldcf.jettyrunner.ManifoldCFJettyRunner.main(ManifoldCFJettyRunner.java:202) Caused by: org.postgresql.util.PSQLException: ERROR: database dbname already exists at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:329) at org.apache.manifoldcf.core.database.Database.execute(Database.java:526) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(Database.java:381) C:\Program Files\Apache\apache-acf\example The only way to get it started is dropping the table it created the first time, in this case dbname. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
