scottkurz
commented
9 years ago Hi Michael,
Thanks for reporting this bug!
Yes, javax.xml.validation.SchemaFactory is not thread-safe, so we can synch on that rather than making you synch on the JobOperator. Next chance I get I'll include a fix which should go into the jbatch 1.0.1 we've been working on.
And yes, this is a fine forum to report implementation bugs.
We also have the forum: https://java.net/projects/jbatch/lists/issues/archive for spec and TCK issues/bugs/proposals, etc.
I'll update the glassfish JIRA as well.
schmid-michael
Hello,
I did not found a forum for the JSR-352 reference implementation - not sure if this actually is an issue or just a misconception on my side. We use version 1.0 of the reference implementation in a non-J2EE (tomcat) environment. We experienced problems under high load were many jobs were started by multiple server threads at the same time. The server application uses a singleton instance of the JobOperator interface. When under high load, JobOperator#start() eventually results in this exception:
java.lang.IllegalArgumentException: xJCL invalid per schema at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.unmarshalJobXML(JobModelResolverImpl.java:73) at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.access$2(JobModelResolverImpl.java:51) at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:127) at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl$1.run(JobModelResolverImpl.java:1) at java.security.AccessController.doPrivileged(Native Method) at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:123) at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.resolveModel(JobModelResolverImpl.java:1) at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.startJob(JobExecutionHelper.java:114) at com.ibm.jbatch.container.impl.BatchKernelImpl.startJob(BatchKernelImpl.java:123) at com.ibm.jbatch.container.api.impl.JobOperatorImpl.startInternal(JobOperatorImpl.java:121) at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:86)
The issue has been resolved by synchronizing access to the JobOperator:
synchronized(jobOperator) { jobOperator.start(...); }
Not sure if this Glassfish bug describes the same problem: https://java.net/jira/browse/GLASSFISH-20942
I'm not sure if JobOperator is designed to be used in a multi-threaded environment. If it's not it might be a good idea to say so in the JavaDoc of the interface. Any help/insights are appreciated!
Kind Regards, Michael