[GLASSFISH-21216] Java Batch does not work properly in Hybrid wep and ejb Created: 26/Sep/14  Updated: 25/Feb/15

Status: Open
Project: glassfish
Component/s: batch, OSGi-JavaEE
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kewlmain Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 8.1
jdk1.8.0_20



 Description   

If I deploy a wab or a hybrid ejb which is OSGi-Bundle the jbatch runtime does not work properly anymore. jbatch seems like it would start the job, but failes to execute the actual artifact, i.e. a batchlet.
If I deploy the archive as plain web app or ejb than everything works fine.
I traced the logs until the BatchWorkUnit should start but the logging stops there and no error messages get printed out in the console.

I created a post on the glassfish forum: https://www.java.net/forum/topic/glassfish/jsr-352-within-osgi-ejb-or-war-failes-execute-batch-job?force=286

There I attached a sample application, which demonstrate the issue. If you deploy the app as plain web app, the you will see the output:
Information: Starting batch...
Information: Batch with executionId: 14.780 started!
Information: SimpleBatchlet executed

If you deploy the package as OSGi bundle you only get to see:
Information: Starting batch...
Information: Batch with executionId: 14.780 started!

This means I can't use jbatch in the OSGi environment, which I need currently. And it seems like I'm not able to access the jbatch runtime with a plain OSGi bundle.



 Comments   
Comment by kewlmain [ 12/Oct/14 ]

After a few days of debugging I found out the problem lies somewhere in the ManagedExecuterServiceImpl, to be precise in the ContextSetupProviderImpl class on line 210:

private boolean isApplicationEnabled(String appId) {
if (appId != null)

{ Application app = applications.getApplication(appId); // return null if (app != null) return deployment.isAppEnabled(app); }

return false;
}

It seems like the hybrid bundles (doesn't matter whether WAB or EJB) are not recognised as enabled applications. I'm not sure why? The glassfish logs don't report any kind of exceptions, which could indicate whether the bundle was installed and started without any errors. The OSGi view of the admin web gui displays the bundle was started and is active successfully.

Do I miss something regarding how bundles are handled and this is the desired behaviour? I thought the point of the hybrid bundles was to have access to both the JavaEE and OSGi world. But in my case the bundles don't have access to the ManagedExecutorService implementations.

Maybe I missed some configuration entries in the pom file of the bundles, which could enabled this feature ?

Comment by smillidge-c2b2 [ 25/Feb/15 ]

I believe this is a simple race condition. The EJB startup class PostConstruct method is called before the application is fully deployed hence the failure in the code you have described above.

Comment by smillidge-c2b2 [ 25/Feb/15 ]

The EJB specification doesn't state that you can use JBatch or concurrency utility within a Singleton @Startup @Postconstruct method. I suppose this needs clarification from EJB spec leads.

The spec says you can only do;

SessionContext methods: getBusinessObject, getRollbackOnly, setRollbackOnly, getTimerService, lookup, getContextData
JNDI access to java:comp/env
Resource manager access
Enterprise bean access
EntityManagerFactory access
EntityManager access
TimerService and Timer methods





[GLASSFISH-21020] JDBC connection leak detected in JDBCPersistenceManagerImpl Created: 28/Mar/14  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: ChristianSch Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
        private boolean isDerby() throws SQLException {
                logger.entering(CLASSNAME, "isDerby");
                Connection conn = getConnectionToDefaultSchema();
                DatabaseMetaData dbmd = conn.getMetaData();
                boolean derby = dbmd.getDatabaseProductName().toLowerCase().indexOf("derby") > 0;

 >>>missing>>>  cleanupConnection(conn, null, null);

                logger.exiting(CLASSNAME, "isDerby", derby);
                return derby;
        }





[GLASSFISH-21019] Job cannot inject Created: 26/Mar/14  Updated: 26/Mar/14

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tijs14tijs Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours
Environment:

Linux x64, Netbeans 7.4, Java 7 EE (oracle), Glassfish 4.0


Tags: inject, job, named

 Description   

I use a batch job. In my writer I tried to inject a stateless service. My writer is created but the service has NOT been injected and no error has been shown, when I call the service it appears to be null (not injected).

When I use annotation @Named before MyItemWriter, and change job.xml to ref=myItemWriter then the service will be injected properly. The strange behavour is, that it still finds the writer with ref=kwetter.batch.MyItemWriter in job.xml, but it does not inject any services.

This behavour happens on chunks (reader, processor, writer) and the batchlet. (all defined in job.xml)
I did not check if it happens on more elements of job.xml

See below for my sources
---------------------------------------------------------------------
MyItemWriter.java

package kwetter.batch;

@Dependent
@Named
public class MyItemWriter extends AbstractItemWriter {

@Inject
private MyService service;

-------------------------------------------------------------------
job.xml

<?xml version="1.0" encoding="UTF-8"?>
<job id="job1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
<properties>
<property name="input_file" value="/home/tijs/Downloads/04c-JEA-kwetter-input.json"/>
</properties>
<step id="step1" next="cleanup">
<chunk checkpoint-policy="item" item-count="10">
<reader ref="kwetter.batch.MyItemReader"></reader>
<processor ref="kwetter.batch.MyItemProcessor"></processor>
<writer ref="myItemWriter"></writer>
</chunk>
</step>
<step id="cleanup">
<batchlet ref="kwetter.batch.CleanupBatchlet"></batchlet>
<end on="COMPLETED"/>
</step>
</job>

--------------------------------------------------------------------------
Glassfish log

SEVERE: Failure in Read-Process-Write Loop
com.ibm.jbatch.container.exception.BatchContainerRuntimeException: java.lang.NullPointerException
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.writeChunk(ChunkStepControllerImpl.java:495)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeChunk(ChunkStepControllerImpl.java:587)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:684)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:144)
at com.ibm.jbatch.container.impl.ExecutionTransitioner.doExecutionLoop(ExecutionTransitioner.java:112)
at com.ibm.jbatch.container.impl.JobThreadRootControllerImpl.originateExecutionOnThread(JobThreadRootControllerImpl.java:110)
at com.ibm.jbatch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:80)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
Caused by: java.lang.NullPointerException
at kwetter.batch.MyItemWriter1.writeItems(MyItemWriter1.java:31)
at com.ibm.jbatch.container.artifact.proxy.ItemWriterProxy.writeItems(ItemWriterProxy.java:71)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.writeChunk(ChunkStepControllerImpl.java:470)
... 13 more

WARNING: Caught throwable in chunk processing. Attempting to close all readers and writers.
WARNING: Caught exception executing step: com.ibm.jbatch.container.exception.BatchContainerRuntimeException: Failure in Read-Process-Write Loop
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeChunk(ChunkStepControllerImpl.java:670)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:684)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:144)
at com.ibm.jbatch.container.impl.ExecutionTransitioner.doExecutionLoop(ExecutionTransitioner.java:112)
at com.ibm.jbatch.container.impl.JobThreadRootControllerImpl.originateExecutionOnThread(JobThreadRootControllerImpl.java:110)
at com.ibm.jbatch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:80)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
Caused by: com.ibm.jbatch.container.exception.BatchContainerRuntimeException: java.lang.NullPointerException
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.writeChunk(ChunkStepControllerImpl.java:495)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeChunk(ChunkStepControllerImpl.java:587)
... 12 more
Caused by: java.lang.NullPointerException
at kwetter.batch.MyItemWriter1.writeItems(MyItemWriter1.java:31)
at com.ibm.jbatch.container.artifact.proxy.ItemWriterProxy.writeItems(ItemWriterProxy.java:71)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.writeChunk(ChunkStepControllerImpl.java:470)
... 13 more






[GLASSFISH-20997] Batch job xml file in META-INF/batch-jobs folder is not closed after executing batchlet Created: 28/Feb/14  Updated: 28/Feb/14

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: salaryman Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: batch

 Description   

Periodically start a batchlet(JobOperator.start) using timer service and confirmed that
batchlet job completed without error.

JobExecution.getBatchStatus() shows completed status for all jobs.

However the number of opened job xml file handle keeps
on growing over time.

Have verified this issue using Process Explorer in Windows and
lsof -p <pid> in linux.

When shutting down glassfish after calling batch, below exception is thrown. The same exception does not appear when shutting down if batchlet is not called.

WARNING: Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(ASURLClassLoader.java:1280)
at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:938)
at com.ibm.jbatch.container.services.impl.DelegatingJobXMLLoaderServiceImpl.loadJobFromBatchJobs(DelegatingJobXMLLoaderServiceImpl.java:96)
at com.ibm.jbatch.container.services.impl.DelegatingJobXMLLoaderServiceImpl.loadJSL(DelegatingJobXMLLoaderServiceImpl.java:70)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.startInternal(JobOperatorImpl.java:112)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:86)






[GLASSFISH-21041] make schema/table-prefix/table-suffix configurable for batch status tables Created: 16/Apr/14  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: ChristianSch Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-reviewed

 Description   

currently schema is hard coded, see GLASSFISH-20886

to comply with site policies / name scheme it would be useful to be able to define not only schema, but also table-prefix and suffix, for example javax.batch.table-prefix="T_"



 Comments   
Comment by Mahesh Kannan [ 16/Apr/14 ]

Mar for 4.0.1





[GLASSFISH-20942] javax.batch.operations.JobStartException: java.lang.IllegalArgumentException: xJCL invalid per schema Created: 27/Dec/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: aronrodrigues Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Net Beans 4


Tags: 4_0_1-evangelists, 4_0_1-reviewed, Jobs

 Description   

When I try to debug my project, all the job fails with this error. Maybe because some jobs starts at the same time.

The strange behaviour is when I'm not debugging, I have the same error too.

SEVERE: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
javax.batch.operations.JobStartException: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:90)
at br.com.oscarasdati.msdcdm.core.CronJobBatchRunner.run(CronJobBatchRunner.java:99)
at br.com.oscarasdati.msdcdm.core.CronJobBatchRunner.timeout(CronJobBatchRunner.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3993)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1199)
at com.sun.ejb.containers.EJBTimerService.access$000(EJBTimerService.java:89)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1919)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.RuntimeException: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.ibm.jbatch.jsl.util.ValidatorHelper.getXJCLSchema(ValidatorHelper.java:42)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.unmarshalJobXML(JobModelResolverImpl.java:58)
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.access$000(JobModelResolverImpl.java:45)
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:125)
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:45)
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)
... 39 more
Caused by: org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
at com.sun.org.apache.xerces.internal.jaxp.validation.Util.toSAXException(Util.java:65)
at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:259)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:627)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:659)
at com.ibm.jbatch.jsl.util.ValidatorHelper.getXJCLSchema(ValidatorHelper.java:40)
... 50 more

WARNING: JSL invalid per XSD, details:
MESSAGE: cvc-elt.1: Cannot find the declaration of element 'job'.
SEVERITY: 2
LINKED EXC: org.xml.sax.SAXParseException; lineNumber: 3; columnNumber: 21; cvc-elt.1: Cannot find the declaration of element 'job'.
LOCATOR INFO:
------------
COLUMN NUMBER: 21
LINE NUMBER: 3
OFFSET: -1
CLASS: class javax.xml.bind.helpers.ValidationEventLocatorImpl
NODE: null
OBJECT: null
URL: null



 Comments   
Comment by aronrodrigues [ 09/Jan/14 ]

Could you reproduce it? Can I help?

Comment by reza_rahman [ 15/Jan/14 ]

Could you outline the steps to reproduce?

Comment by aronrodrigues [ 16/Jan/14 ]

Create 2 @Startup @Singleton Beans which starts 2 differents jobs at the same time. Run sometimes...
I made an workaround making a syncronized block in the timeout method with a static variable.

Comment by Mahesh Kannan [ 16/Apr/14 ]

Mark for 4.0.1





[GLASSFISH-20199] BATCH CLI: asadmin set-batch-runtime-configuration --help command shows incorrect examples Created: 05/Apr/13  Updated: 21/Sep/15

Status: In Progress
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.1.1

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Gail Risdal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly b84

asadmin set-batch-runtime-configuration --help shows

Examples:

asadmin> configure-batch-runtime --executorservicelookupname concurrent/myExecutor
Command set-batch-runtime-configuration executed successfully.

Issue -> command name is wrong



 Comments   
Comment by Mahesh Kannan [ 05/Apr/13 ]

Assigning to Gail

Comment by Gail Risdal [ 05/Apr/13 ]

Example now uses set-batch-runtime-configuration.

The change has been made in the documentation source but no further updates to the bundled documentation (man pages and OLH) are planned for the GlassFish 4.0 Open Source Edition release. Marking this 'In Progress' to record the fact that the work has already been done in the source and will be picked up when bundled docs are built/committed for a future release.





[GLASSFISH-20685] Provide a REST API to stop a long running job after its submission Created: 08/Jul/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1.1

Type: Improvement Priority: Minor
Reporter: Anissa Lam Assignee: Mahesh Kannan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-20683 Add the possibility to stop - JobOper... Open

 Description   

Console will need this API in order to implement GLASSFISH-20683






Generated at Mon Jul 25 08:59:05 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.