a few questions:
- What version of Quartz do you use?
- Do you use Seam async dispatcher (i.e. @Asynchronous) or Quartz API?
- Do you provide your own quartz configuration file (quartz.properties)?
Also don't forget to have I/O socket timeouts defined. Otherwise the thread may hang in I/O wait indefinitely (i.e. will not be used for other job executions). I ran into a similar issue when using commons-mail to send an email via SMTP (there was no timeout by default - fixed in https://issues.apache.org/jira/browse/EMAIL-100).
I am not quite sure what Quartz version is used, I am using the one that is bundled with Seam. For Seam 2.2 this was Quartz 1.6, I am not sure whether that was updated for Seam 2.3 (1.6 sounds like it is very old).
We don't use the Quartz API directly, we only use the Seam async dispatcher and we don't have any custom quartz configuration (no seam.quartz.properties file).
Blocking sockets is not the problem here (although I had a similar problem with a misconfigured POP3 connection a while ago).
Seam 2.3 depends on Quartz 1.6.5 and yes it's quite an outdated version. Anyway org.jboss.seam.async.QuartzDispatcher.QuartzJob is catching all exceptions and the default AsynchronousExceptionHandler just logs the exception. The log message you posted indicates a transaction was not completed correctly - i.e. no commit/rollback - and the thread has some invalid tx info associated. As far as I know there's no "clean" way to remove a thread from the thread pool in Quartz. So the best solution would be to handle a transaction rollback correctly (if ValidationException occurs). Do you use Seam managed transactions in your app?