incubator-connectors-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Connectors Framework > FAQ
Date Mon, 31 Jan 2011 02:17:00 GMT
Space: Apache Connectors Framework (https://cwiki.apache.org/confluence/display/CONNECTORS)
Page: FAQ (https://cwiki.apache.org/confluence/display/CONNECTORS/FAQ)
Comment: https://cwiki.apache.org/confluence/display/CONNECTORS/FAQ?focusedCommentId=25200275#comment-25200275

Comment added by Karl Wright:
---------------------------------------------------------------------

Derby has a huge number of threads waiting on being able to modify or update a number of table
rows.  Meanwhile, one thread seems to be alive and is updating hop count data.

My suspicion is that there is indeed a bug in Derby, but it's the hopcount logic's intensive
use of database access that exacerbates the problem.  I suspect that jobs that do not deal
with hopcount at all will not fail readily.

In any case, you can easily change the Quick-Start's properties.xml file to use PostgreSQL
instead.  The online build-and-deploy doc explains how.


In reply to a comment by Karl Wright:
My Derby crawl did not finish either.  Even worse, it locked up badly enough so that I had
to stop and restart the crawler process to get into the UI.  So clearly there's a database
issue of some kind.

You can always safely restart the process; when you do that, the job should complete aborting.
 But that's immaterial, because Derby seems to be deadlocking internally in some way during
the crawl.

I strongly urge that you give up on Derby and use PostgreSQL.  The performance is better and
it won't deadlock in this way.

Meanwhile, I'm going to try and figure out what Derby thinks its doing when it hangs in this
way.




Change your notification preferences: https://cwiki.apache.org/confluence/users/viewnotifications.action

Mime
View raw message