[
https://issues.apache.org/jira/browse/FELIX-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721007#action_12721007
]
Chris Custine commented on FELIX-1192:
--------------------------------------
Patch applied, with thanks to Jamie Goodyear. I made a few small adjustments
to the patch and removed the logging calls related to FELIX-1180 because we
going to revisit that issue at a later date. Some calls were removed and some
were converted to System.err.println, etc.
> KARAF: Locking error in DefaultJDBCLock, also contains an eventual
> OutOfMemory error on locked processes.
> ---------------------------------------------------------------------------------------------------------
>
> Key: FELIX-1192
> URL: https://issues.apache.org/jira/browse/FELIX-1192
> Project: Felix
> Issue Type: Bug
> Components: Karaf
> Affects Versions: karaf-1.0.0
> Environment: All
> Reporter: Jamie goodyear
> Assignee: Chris Custine
> Fix For: karaf-1.0.0
>
> Attachments: felix1192.patch
>
>
> If you configure servicemix to use the DefaultJDBCLock like so:
> karaf.lock=true
> karaf.lock.class=org.apache.felix.karaf.main.DefaultJDBCLock
> karaf.lock.level=50
> karaf.lock.delay=1000
> karaf.lock.jdbc.url=jdbc:mysql://localhost:3306/somedatabase
> karaf.lock.jdbc.driver=org.apache.derby.jdbc.ClientDriver
> karaf.lock.jdbc.user=root
> karaf.lock.jdbc.password=
> karaf.lock.jdbc.table=KARAF_LOCK
> karaf.lock.jdbc.clustername=mycluster
> karaf.lock.jdbc.timeout=30
> and simply run it you'll get an OutOfMemory error printed to the console
> within an hour or so. It appears that the offending code is here:
> /**
> * isAlive - test if lock still exists.
> */
> public boolean isAlive() throws Exception {
> if (lockConnection == null) { return false; }
> PreparedStatement statement = null;
> try {
> lockConnection.setAutoCommit(false);
> statements.init(lockConnection);
> String sql = statements.testLockTableStatus();
> statement = lockConnection.prepareStatement(sql);
> statement.execute();
> } catch (Exception ex) {
> return false;
> }
> return true;
> }
> the try/catch statement needs a finally to ensure the PreparedStatement is
> cleaned up:
> } finally {
> if (statement != null) {
> try {
> statement.close();
> } catch (SQLException e) {
> //log failure here...
> }
> }
> }
> We should also put some unit testing in place for this class and ensure that
> it doesn't leak any other resources, JDBC or otherwise as this class is used
> to set up master/slave HA which is an important use case to support.
> Also of note is that the container level locking mechanism seems to not be
> honored by slave processes. In the Main#lock method if the lock is enabled we
> should only start up to the configured lock level, otherwise start Karaf up
> to the default lock level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
