[Logo] Terracotta Discussion Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
my Quartz doesn't resume processing jobs after connections to db are restored  XML
Forum Index -> Quartz
Author Message
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

Using 1.8.4, on Windows XP talking to SQL Server 2005.

My problem is the following:

My software is running and very happy. Then a systems admin shutsdown my SQL Server instance. The way my software is designed is that it keeps running. We are able to do 99% of what we are suppose to do, we of course, can't persist things to the database.

When the system admin restarts the SQL Server instance, we reconnect and function quite well.

While I have not totally figured this out, if my access to SQL Server goes down for less than 2 hours, my Quartz Scheduler is able to pick up where it left off when its able to reconnect.

But, I just ran a test whereby my access to the SQL Server instance was lost for 4 hours. Well in that case, after I restart SQL Server Quartz does not come back okay.

The last set of Quartz related stack traces in my logs are:
01/23/2012 02:06:15 PM, smp.producer , QuartzScheduler_QuartzScheduler-NON_CLUSTERED_MisfireHandler, WARN , Failed to override connection auto commit/transaction isolation.
com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset by peer: socket write error
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1368)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1355)
at com.microsoft.sqlserver.jdbc.TDSChannel.write(IOBuffer.java:1548)
at com.microsoft.sqlserver.jdbc.TDSWriter.flush(IOBuffer.java:2368)
at com.microsoft.sqlserver.jdbc.TDSWriter.writePacket(IOBuffer.java:2270)
at com.microsoft.sqlserver.jdbc.TDSWriter.endMessage(IOBuffer.java:1877)
at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4403)
at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389)
at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1457)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1416)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1462)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1610)
at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293)
at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.setAutoCommit(AttributeRestoringConnectionInvocationHandler.java:91)
at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.invoke(AttributeRestoringConnectionInvocationHandler.java:65)
at $Proxy0.setAutoCommit(Unknown Source)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:712)
at org.quartz.impl.jdbcjobstore.JobStoreTX.getNonManagedTXConnection(JobStoreTX.java:69)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3107)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3896)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3916)
01/23/2012 02:06:15 PM, smp.producer , QuartzScheduler_QuartzScheduler-NON_CLUSTERED_MisfireHandler, WARN , Failed restore connection's original auto commit setting.
com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1592)
at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.setAutoCommit(PoolingDataSource.java:293)
at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.restoreOriginalAtributes(AttributeRestoringConnectionInvocationHandler.java:134)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.cleanupConnection(JobStoreSupport.java:3554)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3144)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3896)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3916)
01/23/2012 02:06:15 PM, smp.producer , QuartzScheduler_QuartzScheduler-NON_CLUSTERED_MisfireHandler, ERROR, Failed to close Connection
java.sql.SQLException: Already closed.
at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:77)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:180)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.closeConnection(JobStoreSupport.java:3579)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.cleanupConnection(JobStoreSupport.java:3555)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3144)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3896)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3916)
01/23/2012 02:06:15 PM, smp.producer , QuartzScheduler_QuartzScheduler-NON_CLUSTERED_MisfireHandler, ERROR, MisfireHandler: Error handling misfires: null
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.rollback(Unknown Source)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.rollbackConnection(JobStoreSupport.java:3604)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3137)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3896)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3916)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.invoke(AttributeRestoringConnectionInvocationHandler.java:71)
... 5 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:170)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:304)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.rollback(SQLServerConnection.java:1655)
at org.apache.commons.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:265)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.rollback(PoolingDataSource.java:288)
... 10 more

At this point, I am not sure if the stack traces and Quartz not recovering are related or not.


my quartz.properties are:

# Don't need to tie scheduling commands (such as adding and removing triggers)
# to other transactions.
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

# Thread pool class.
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool

# Number of threads to use.
org.quartz.threadPool.threadCount = 2

# Inform the JobStore of the table prefix being used.
org.quartz.jobStore.tablePrefix = QRTZ_

# Store all values in JobDataMaps as Strings instead of Objects.
org.quartz.jobStore.useProperties = true

# Have Quartz create and manage the DataSource itself
org.quartz.jobStore.dataSource = smpDS

# Maximum connections for the DataSource.
org.quartz.dataSource.smpDS.maxConnections = 5

# Disable quartz from "phoning home" and checking for newer versions
org.quartz.scheduler.skipUpdateCheck=true

jhouse

seraphim
[Avatar]
Joined: 11/06/2009 15:29:56
Messages: 1703
Offline


This isn't a complete set of properties that you've posted, so I can't tell how you've configured your datasource.

The most likely cause is that you didn't configure a validation query for the datasource.
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

I didn't write the code, I am just trying to debug it.

The only other properties in my quartz.properties file are related to a plugin:

org.quartz.plugin.shutdownhook.class = org.quartz.plugins.management.ShutdownHookPlugin
org.quartz.plugin.shutdownhook.cleanShutdown = true

The only other thing I can find, that I think is relevant is that in the code we set the property org.quartz.jobStore.driverDelegateClass to be org.quartz.imple.jdbcjobstore.MSSQLDelegate

We also set the connection url.

In the source code, I don't see anything related to a "validation query" at all. I am poking around the documentation now.


jhouse

seraphim
[Avatar]
Joined: 11/06/2009 15:29:56
Messages: 1703
Offline

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigDataSources
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

Thank you for providing this url. I will pursue this.

A difference I noticed in the stack trace, was the following segment where it mentiones a null in the MisfireHandler...

01/23/2012 02:06:15 PM, smp.producer , QuartzScheduler_QuartzScheduler-NON_CLUSTERED_MisfireHandler, ERROR, MisfireHandler: Error handling misfires: null
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.rollback(Unknown Source)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.rollbackConnection(JobStoreSupport.java:3604)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3137)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3896)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3916)
Caused by: java.lang.reflect.InvocationTargetException

how does the null in the misfire handler, relate to the validation

I was wondering if the null caused, the quartz code to stop doing what it normally does, and thus was the reason why it didn't resume processing the jobs when it was able to get a db connection.

I am rerunning the tests I ran yesterday with the 1.8.6 version, to see if the same thing happens there as it appears that there were errors fixed in the "misfire handler area" in 1.8.6.
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline


I switched to use 1.8.6 and I still have the same problem. It doesn't always occur, but if I shut down the SQL Server instance, and then later restart the instance (with later being at least 2 hours) later, then some times quartz does not resume processing jobs.

Now, my properties are set to have 2 worker threads, and 5 max connections.

I don't have a validation string right now.

Normally I have two jobs in my queue. 1 job that runs once a week, and a job that runs every 15 minutes. As a course of action, other jobs can be configured, but on my system right now, there are no other jobs.

We do however, have an API where we can show jobs in the queue. So, I know that when we use the UI which causes the API, that I can be using a worker thread, and of course at least one db connection.

What happens is not only is the 15 minute job not restarted when the db connection is restored, but I also can't paint my UI screen when I try to get a listing of what's in my queue.

So perhaps, I have stalled worker threads... And I need more. So, I am going to rerun my test with say 4 worker threads, and perhaps 7 connections (doc says numb connections needs to be num threads + 3).

Separately, on a different machine, I am concurrently trying out the "validationQuery" ... I have tried to put in "SELECT COUNT(*) FROM QRTZ_SCHEDULER_STATE" but I get an error about an unknown "stored procedure"... QRTZ_SCHEDULER_STATE is a table in my db. I will have to look at this more closely as to what the issue really is. I will try a non-quartz table next.

If I don't have a ValidationQuery, does Quartz 1.8.6 ever toss a db connection. My assumption would be that it would use the connection until it got an exception, and that it would then eat the exception, toss the connection, and create a new connection and try again ?


jhouse

seraphim
[Avatar]
Joined: 11/06/2009 15:29:56
Messages: 1703
Offline

Connection recovery relies on having a validation query.
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline


So, I set the property:

org.quartz.dataSource.smpDS.validationQuery = "SELECT COUNT(*) FROM QRTZ_SCHEDULER_STATE"

And I get

Failure occured during job recovery. [See nested exception: org.quartz.JobPersistenceException: Failed to obtain DB connection from data source 'smpDS': org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Could not find stored procedure 'SELECT COUNT(*) FROM QRTZ_SCHEDULER_STATE'.) [See nested exception: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Could not find stored procedure 'SELECT COUNT(*) FROM QRTZ_SCHEDULER_STATE'.)]]

When I start up my quartz instance.

The quartz documentation doesn't say that this has to be a stored procedure:

doc text says:

org.quartz.dataSource.NAME.validationQuery

Is an optional SQL query string that the DataSource can use to detect and replace failed/corrupt connections. For example an oracle user might choose "select table_name from user_tables" - which is a query that should never fail - unless the connection is actually bad.

I would like the query string to be DB agnostic if at all possible, as I have to support both an ORACLE and a SQL Server DB.

jhouse

seraphim
[Avatar]
Joined: 11/06/2009 15:29:56
Messages: 1703
Offline

No, it does not have to be a stored procedure, and in fact should not be. It should just be any valid fast-running sql query that return very few rows (preferably one) in the rust.

E.g. for Postgresql the typical used sql is "SELECT 0", from which the database returns the value 0 (one row, one column) -- totally meaningless, other than it tests the connection to the db.

Not sure why MS SQLServer doesn't like that sql.
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

I was able to execute "SELECT 0" in MS SQL Server Management Studio, but when I make that the validationQuery I get:

01/26/2012 04:31:52 PM, smp.producer , main , ERROR, Scheduler: Exception occurred during scheduler startup.org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.JobPersistenceException: Failed to obtain DB connection from data source 'smpDS': org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Could not find stored procedure 'SELECT 0'.) [See nested exception: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Could not find stored procedure 'SELECT 0'.)]]

macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

I changed the property for the validation query from

# db connection validation query
org.quartz.dataSource.smpDS.validationQuery = "SELECT 0"

to

# db connection validation query
org.quartz.dataSource.smpDS.validationQuery = SELECT 0

and now I don't get the error: "Could not find stored procedure 'SELECT 0'"

How will I know if the validation is working ?
jhouse

seraphim
[Avatar]
Joined: 11/06/2009 15:29:56
Messages: 1703
Offline


Ah! Of course the quotes were a problem - sorry I didn't think to catch that for you.

If the parameter is set and Quartz is running (without throwing exceptions on every event / api call), then it's working!
macomber

neo

Joined: 01/23/2012 09:47:55
Messages: 9
Offline

I don't even know why I thought of the quotes... to me the string had a space in it, so I needed to quote it...

I'll run my code over the weekend with the db being down, and restart it on monday am.... if everything resumes processing then, then I know it works...

Thanks for your help
jshaughn

neo

Joined: 05/08/2014 13:17:18
Messages: 2
Offline

I'm having a similar problem. Things work fine unless there is a loss of connection to the database. Even after a brief connection loss my scheduled triggers don't seem to recover, and I see repeating errors in the logs.

I'm using Quartz 1.8.6 and JBoss EAP 6 (AS 7.2). I was using Quartz 1.6.5 but upgraded in hopes the issue would go away, but it didn't.

I'm using postgres. Here is my quartz.properties:

Code:
 org.quartz.scheduler.instanceName = RHQScheduler
 org.quartz.scheduler.instanceId   = AUTO
 
 # thread pool config
 org.quartz.threadPool.class       = org.quartz.simpl.SimpleThreadPool
 org.quartz.threadPool.threadCount = 5
 
 # database config
 org.quartz.jobStore.class                 = org.quartz.impl.jdbcjobstore.JobStoreCMT
 org.quartz.jobStore.driverDelegateClass   = org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
 org.quartz.jobStore.isClustered           = true
 org.quartz.jobStore.clusterCheckinInterval = 30000
 org.quartz.jobStore.tablePrefix           = RHQ_QRTZ_
 org.quartz.jobStore.useProperties         = true
 org.quartz.jobStore.selectWithLockSQL     = SELECT * FROM {0}LOCKS ROWLOCK WHERE LOCK_NAME = ? FOR UPDATE
 org.quartz.jobStore.lockHandler.class     = org.quartz.impl.jdbcjobstore.StdRowLockSemaphore
 org.quartz.jobStore.dataSource            = RHQDS
 org.quartz.jobStore.nonManagedTXDataSource = NoTxRHQDS
 
 org.quartz.dataSource.RHQDS.jndiURL        = java:jboss/datasources/RHQDS
 org.quartz.dataSource.NoTxRHQDS.jndiURL    = java:jboss/datasources/NoTxRHQDS
 


My datasources are configured like this:

Code:
 <datasource jta="false" jndi-name="java:jboss/datasources/NoTxRHQDS" pool-name="NoTxRHQDS" enabled="true" use-java-context="true">
    <connection-url>${rhq.server.database.connection-url:jdbc:postgres://127.0.0.1:5432/rhq}</connection-url>
    <connection-property name="char.encoding">UTF-8</connection-property>
    <driver>postgres</driver>
    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
    <pool>
       <min-pool-size>2</min-pool-size>
       <max-pool-size>5</max-pool-size>
    </pool>
    <security>
       <security-domain>RHQDSSecurityDomain</security-domain>
    </security>
    <validation>
       <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
       <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
    <timeout>
       <blocking-timeout-millis>30000</blocking-timeout-millis>
       <idle-timeout-minutes>15</idle-timeout-minutes>
    </timeout>
    <statement>
       <prepared-statement-cache-size>75</prepared-statement-cache-size>
    </statement>
 </datasource>
 <xa-datasource jta="true" jndi-name="java:jboss/datasources/RHQDS" pool-name="RHQDS" use-java-context="true">
    <xa-datasource-property name="DatabaseName">${rhq.server.database.db-name:rhq}</xa-datasource-property>
    <xa-datasource-property name="PortNumber">${rhq.server.database.port:5432}</xa-datasource-property>
    <xa-datasource-property name="ServerName">${rhq.server.database.server-name:127.0.0.1}</xa-datasource-property>
    <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    <driver>postgres</driver>
    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
    <xa-pool>
       <min-pool-size>5</min-pool-size>
       <max-pool-size>50</max-pool-size>
    </xa-pool>
    <security>
       <security-domain>RHQDSSecurityDomain</security-domain>
    </security>
    <validation>
       <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
       <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
    <timeout>
       <blocking-timeout-millis>30000</blocking-timeout-millis>
       <idle-timeout-minutes>15</idle-timeout-minutes>
    </timeout>
    <statement>
       <prepared-statement-cache-size>75</prepared-statement-cache-size>
    </statement>
 </xa-datasource>
 


When the database comes back online I get various errors repeatedly (about 15s apart). Here is a sample:

Code:
 16:58:01,252 ERROR [org.quartz.core.ErrorLogger] (RHQScheduler_QuartzSchedulerThread) An error occured while releasing trigger
 'org.rhq.enterprise.server.scheduler.jobs.SavedSearchResultCountRecalculationJob.org.rhq.enterprise.server.scheduler.jobs.SavedSearchResultCountRecalculationJob': 
 org.quartz.impl.jdbcjobstore.LockException: 
 Failure obtaining db row lock: 
 This connection has been closed. [See nested exception: org.postgresql.util.PSQLException: 
 This connection has been closed.]
 	at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:109) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.DBSemaphore.obtainLock(DBSemaphore.java:112) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3781) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3750) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.releaseAcquiredTrigger(JobStoreSupport.java:2829) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.releaseTriggerRetryLoop(QuartzSchedulerThread.java:542) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:348) [quartz-1.8.6.jar:]
 Caused by: org.postgresql.util.PSQLException: This connection has been closed.
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:822)
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.getAutoCommit(AbstractJdbc2Connection.java:788)
 	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:536)
 	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)
 	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:302)
 	at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeQuery(CachedPreparedStatement.java:107)
 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
 	at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:89) [quartz-1.8.6.jar:]
 	... 6 more
 
 16:58:16,258 ERROR [org.quartz.impl.jdbcjobstore.JobStoreCMT] (RHQScheduler_QuartzSchedulerThread) Couldn't rollback jdbc connection. This connection has been closed.: 
 org.postgresql.util.PSQLException:
 This connection has been closed.
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:822)
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:839)
 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1101)
 	at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:778)
 	at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.7.0_45]
 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
 	at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.invoke(AttributeRestoringConnectionInvocationHandler.java:73) [quartz-1.8.6.jar:]
 	at com.sun.proxy.$Proxy144.rollback(Unknown Source)
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.rollbackConnection(JobStoreSupport.java:3629) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3798) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3750) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.releaseAcquiredTrigger(JobStoreSupport.java:2829) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.releaseTriggerRetryLoop(QuartzSchedulerThread.java:542) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:348) [quartz-1.8.6.jar:]
 
 16:58:30,796 ERROR [org.quartz.impl.jdbcjobstore.JobStoreCMT] (QuartzScheduler_RHQScheduler-jshaughn-THINK1399581891491_ClusterManager) 
 Couldn't rollback jdbc connection. This connection has been closed.: org.postgresql.util.PSQLException: This connection has been closed.
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:822)
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:839)
 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1101)
 	at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:778)
 	at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.7.0_45]
 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
 	at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.invoke(AttributeRestoringConnectionInvocationHandler.java:73) [quartz-1.8.6.jar:]
 	at com.sun.proxy.$Proxy144.rollback(Unknown Source)
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.rollbackConnection(JobStoreSupport.java:3629) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.doCheckin(JobStoreSupport.java:3240) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.manage(JobStoreSupport.java:3847) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport$ClusterManager.run(JobStoreSupport.java:3883) [quartz-1.8.6.jar:]
 
 16:58:31,264 ERROR [org.quartz.impl.jdbcjobstore.JobStoreCMT] (RHQScheduler_QuartzSchedulerThread) Couldn't rollback jdbc connection.
 This connection has been closed.: org.postgresql.util.PSQLException: This connection has been closed.
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:822)
 	at org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:839)
 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1101)
 	at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:778)
 	at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.7.0_45]
 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
 	at org.quartz.impl.jdbcjobstore.AttributeRestoringConnectionInvocationHandler.invoke(AttributeRestoringConnectionInvocationHandler.java:73) [quartz-1.8.6.jar:]
 	at com.sun.proxy.$Proxy144.rollback(Unknown Source)
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.rollbackConnection(JobStoreSupport.java:3629) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3798) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3750) [quartz-1.8.6.jar:]
 	at org.quartz.impl.jdbcjobstore.JobStoreSupport.releaseAcquiredTrigger(JobStoreSupport.java:2829) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.releaseTriggerRetryLoop(QuartzSchedulerThread.java:542) [quartz-1.8.6.jar:]
 	at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:348) [quartz-1.8.6.jar:]
 


Any ideas appreciated!
jshaughn

neo

Joined: 05/08/2014 13:17:18
Messages: 2
Offline

Alright, the answer to my issue is that for the Non-XA DS used for quartz, you must specify:

Code:
 <validation>
   ...
   <validate-on-match>true</validate-on-match>
 </validation>
 


This was not obvious at all due to a documentation bug in EAP 6.2 (and earlier), which specified that the default was true.

This setting can be left false for the XA DS.
 
Forum Index -> Quartz
Go to:   
Powered by JForum 2.1.7 © JForum Team