[GLASSFISH-20886] jbatch reference implementation does not work with oracle database as job repository. Created: 07/Nov/13  Updated: 22/Sep/15  Resolved: 27/Jan/15

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

Type: Bug Priority: Major
Reporter: jiggster Assignee: Mahesh Kannan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 (though this is almost certainly platform agnostic problem).


Tags: 4_0_1-approved, batch

 Description   

Steps to reproduce the bug:

  • Have a working instance of the Oracle database with some test schema. Schema name is very important and must be other than APP or JBATCH - in my case it was simply BATCH.
  • Install GlassFish Server Open Source Edition 4.0 with the default domain1 domain.
  • Install Oracle JDBC driver for the target database, i.e. place the driver's JAR file in domain's lib directory.
  • Execute the %GLASSFISH_HOME%\glassfish\lib\install\databases\jsr352-oracle.sql script in the target database schema.
  • Create jdbc connection pool to Oracle database schema, say jdbc/pool/oracle.
asadmin create-jdbc-connection-pool -e --datasourceclassname oracle.jdbc.xa.client.OracleXADataSource --restype javax.sql.XADataSource --steadypoolsize 2 --maxpoolsize 8 --maxwait 30000 --poolresize 1 --idletimeout 300 --isconnectvalidatereq=true --isolationlevel read-committed --validationmethod table --validationtable DUAL --failconnection=true --allownoncomponentcallers=false --nontransactionalconnections=false --description "Connection pool supporting distributed transactions to BATCH schema in local Oracle database." --property "User=BATCH:Password=BATCH123:URL=jdbc\:oracle\:thin\:@localhost\:1521\:orcl:LoginTimeout=5000:DataSourceName=OracleXADataSource" jdbc/pool/batch
  • Create jdbc resource (jdbc/oracle) that wraps the jdbc/pool/oracle
asadmin create-jdbc-resource --target server --connectionpoolid jdbc/pool/oracle --enabled=true --description "Wrapper for jdbc/pool/oracle JDBC connection pool." jdbc/oracle
  • Set jdbc/oracle resource as the target data source for the batch configuration in server instance
asadmin set-batch-runtime-configuration --datasourcelookupname jdbc/oracle
  • Restart domain - not sure if it's necessary, but I think it is.
  • Deploy the webserverlog application from Java EE 7 tutorial - will try to upload app archive.
  • Go to http://localhost:8080/webserverlog/ and click the "Start Batch Job" button - it shall fail with the "java.sql.SQLSyntaxErrorException: ORA-00922: missing or invalid option".

I spent half of the day tracing the cause of this problem and it seems that the reference batch implementation that is part of the GlassFish server always sets the APP schema on the database connection before proceeding with any database operation, as can be seen in the getConnection method. I found this out by turning on the JDBC driver's logging (by adding the JVM system property -Doracle.jdbc.Trace=true) and adding new logger (logger name: oracle, level: FINEST).



 Comments   
Comment by jiggster [ 07/Nov/13 ]

I've just made a test and can confirm that this issue also occurs for MySQL batch job repository. This time the test was made on mac os x 10.9; MySQL version: 5.6.14 MySQL Community Server (GPL). Below is a full stack trace.

Stack Trace
 
[2013-11-07T18:25:43.706+0100] [glassfish 4.0] [FATAL] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=20 _ThreadName=http-listener-1(3)] [timeMillis: 1383845143706] [levelValue: 1100] [[
  #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQ
L server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
javax.faces.FacesException: #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual tha
t corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
        at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
        at java.lang.Thread.run(Thread.java:744)
Caused by: javax.faces.FacesException: #{jsfBean.startBatchJob()}: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
        at javax.faces.component.UICommand.broadcast(UICommand.java:315)
        at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
        at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
        ... 30 more
Caused by: javax.faces.el.EvaluationException: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101)
        at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
        ... 34 more
Caused by: javax.batch.operations.JobStartException: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:90)
        at javaeetutorial.batch.webserverlog.beans.JsfBean.startBatchJob(JsfBean.java:59)
        at org.jboss.weldeetutorial.batch.webserverlog.beans.JsfBean$Proxy$_$$_WeldClientProxy.startBatchJob(Unknown Source)
        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 javax.el.ELUtil.invokeMethod(ELUtil.java:326)
        at javax.el.BeanELResolver.invoke(BeanELResolver.java:536)
        at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
        at com.sun.el.parser.AstValue.invoke(AstValue.java:269)
        at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
        at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
        at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
        at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
        at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
        ... 35 more
Caused by: com.ibm.jbatch.container.exception.PersistenceException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.createJobInstance(JDBCPersistenceManagerImpl.java:1712)
        at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.getNewJobInstance(JobExecutionHelper.java:89)
        at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.startJob(JobExecutionHelper.java:120)
        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)
        ... 50 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SCHEMA 'APP'' at line 1
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.Util.getInstance(Util.java:386)
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1054)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4237)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4169)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2825)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2156)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2459)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2376)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2360)
        at com.sun.gjc.spi.base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:125)
!!!IMPORTANT PART OF THE STACK TRACE BELOW!!!
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.setSchemaOnConnection(JDBCPersistenceManagerImpl.java:386)
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnection(JDBCPersistenceManagerImpl.java:323)
        at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.createJobInstance(JDBCPersistenceManagerImpl.java:1700)
        ... 55 more

I think that the key question is how does GlassFish sets the schema property of DatabaseConfigurationBean class? Can we set this property somewhere in domain.xml?

Comment by jiggster [ 08/Nov/13 ]

Another issue I've just found in the jbatch 1.0 reference implementation is that the createJobInstance method (and certainly some other methods also) won't work with ojdbc6 Oracle driver, because of the below code fragment, which assumes that the generated primary key is of Long data type (perfectly right assumption if the schema objects were created using the provided jsr352-oracle.sql script), but unfortunately the driver will raise the java.sql.SQLException: Invalid column type: getLong not implemented for class oracle.jdbc.driver.T4CRowidAccessor - more info here.

statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
statement.setString(1, name);
statement.setString(2, apptag);
statement.executeUpdate();
rs = statement.getGeneratedKeys();
if(rs.next()) {
	long jobInstanceID = rs.getLong(1);
	jobInstance = new JobInstanceImpl(jobInstanceID, jobXml);
	jobInstance.setJobName(name);
}

I was really hoping to make use of jsr 352 API in our ongoing project, but it seems (unfortunately) that there's still no solid, cross-platform implementation...

Comment by jiggster [ 18/Nov/13 ]

Is there any chance that someone will evaluate this issue in the near future?

Thank you.

Comment by ChristianSch [ 27/Mar/14 ]

thank you for the analysis of this issue, saved me a lot of time ...

I can confirm that this issue is still present in 4.0.1 b04

as a workaround I'm using the following patch

diff JDBCPersistenceManagerImpl.java com.ibm.jbatch-runtime-all/com/ibm/jbatch/container/services/impl/JDBCPersistenceManagerImpl.java
382a383,385
>               logger.info("setSchemaOnConnection disabled!");
>               return;
> /*
390a394
> */
1673c1677
<                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", new String[] {"jobinstanceid"});
1703c1707
<                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO jobinstancedata (name, apptag) VALUES(?, ?)", new String[] {"jobinstanceid"});
1742c1746
<                       statement = conn.prepareStatement("INSERT INTO executioninstancedata (jobinstanceid, createtime, updatetime, batchstatus, parameters) VALUES(?, ?, ?, ?, ?)", Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement("INSERT INTO executioninstancedata (jobinstanceid, createtime, updatetime, batchstatus, parameters) VALUES(?, ?, ?, ?, ?)", new String[]{"jobexecid"});
1845c1849
<                       statement = conn.prepareStatement(query, Statement.RETURN_GENERATED_KEYS);
---
>                       statement = conn.prepareStatement(query, new String[] {"stepexecid"});
Comment by Mahesh Kannan [ 16/Apr/14 ]

Mark for 4.0.1

Comment by Ed Bratt [ 20/May/14 ]

Assigned, FYI

Comment by Mahesh Kannan [ 21/May/14 ]

The bug is due to the fact (as reported in this bug) GlassFish's DatabaseConfigurationBean implementation always passes "APP" as the schema name.
Fix is on the way!!

Comment by Mahesh Kannan [ 27/Jan/15 ]

This has been resolved with the integration of 1.0.1-b07 jars.
Tested with Oracle db.

Comment by jiggster [ 28/Jan/15 ]

Finally

Care to explain what are the 1.0.1-b07 jars, how can I get them and what to do with them.

Thank you!

Comment by Mahesh Kannan [ 29/Jan/15 ]

1.0.1-b07 jars are the new jars built from the batch project. You can get them from maven central.
You don't need to download them separately. They are part of the GlassFish binaries.

I will update this bug with the GlassFish nightly build that has these new jars.

Comment by jiggster [ 29/Jan/15 ]

OK, great. I assume that the new nightly build will show up under this directory, right? Any idea when it will be available? The last nightly build is from 15-Dec-2014 - there are no nightly builds from 2015...

Comment by smillidge-c2b2 [ 30/Jan/15 ]

Mahesh,

We have a whole load of feature enhancements in Payara related to JBatch, asadmin command support, console changes etc. DB2, Oracle, MySQL Postgres support which we'd love to contribute upstream.

See http://www.payara.co.uk/jbatch_on_payara_41151_now_supports_5_different for details

Comment by davidwinters1980 [ 22/Sep/15 ]

Payara which is built from GF 4.1 supports up to 5 different database types for the JBatch RI

Comment by davidwinters1980 [ 22/Sep/15 ]

Link to Payara and where to download: http://payara.co.uk/home





[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-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-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-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






[GLASSFISH-20959] JMSContext injection does not work in CDI bean that is jbatch artifact. Created: 18/Jan/14  Updated: 20/Apr/15  Resolved: 20/Apr/15

Status: Resolved
Project: glassfish
Component/s: batch, cdi, jms
Affects Version/s: 4.0
Fix Version/s: None

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

Mac OS X 10.9, Ubuntu 12.04, Windows 7


Tags: 4_0_1-evangelists, 4_0_1-reviewed, batch, cdi, jms

 Description   

The following construct does not work when used inside CDI bean that is batch artifact:

@Inject private JMSContext context;

It results in org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped when the injected context is used.



 Comments   
Comment by jiggster [ 18/Jan/14 ]

How can I add attachment? Would like to upload sample application that presents the issue...

Comment by jjsnyder83 [ 16/Apr/14 ]

Login and you should see "Attach file" under Operations on the left column.

Comment by jjsnyder83 [ 24/Mar/15 ]

please provide a reproducible test case





[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-21022] JDBCPersistenceManagerImpl#jobOperatorGetJobExecution SQL syntax error Created: 31/Mar/14  Updated: 27/Jan/15  Resolved: 27/Jan/15

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0
Fix Version/s: 4.1

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

oracle 11g


Tags: 4_0_1-reviewed

 Description   
select A.createtime, A.starttime, A.endtime, A.updatetime, A.parameters, A.jobinstanceid, A.batchstatus, A.exitstatus, B.name 
from executioninstancedata as A inner join jobinstancedata as B on A.jobinstanceid = B.jobinstanceid 
where jobexecid = ?");

Oralce syntax does not allow keyword "as" in table alias, stmt should be converted to

select A.createtime, A.starttime, A.endtime, A.updatetime, A.parameters, A.jobinstanceid, A.batchstatus, A.exitstatus, B.name 
from executioninstancedata A inner join jobinstancedata B on A.jobinstanceid = B.jobinstanceid 
where jobexecid = ?");

this is just an example all stmt should be reviewed



 Comments   
Comment by ChristianSch [ 24/Apr/14 ]

http://docs.oracle.com/cd/B28359_01/server.111/b28286/ap_standard_sql003.htm#SQLRF55400

E051-08, Correlation names in FROM clause (Oracle supports correlation names, but not the optional AS keyword)

Comment by Mahesh Kannan [ 27/Jan/15 ]

This has been resolved with the integration of 1.0.1-b07 jars.
QL passed.





[GLASSFISH-20537] [SDK]Java EE 7 sample-Batch Processing Samples Created: 15/May/13  Updated: 19/Sep/14  Resolved: 18/Jul/14

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b88_RC4
Fix Version/s: 4.1

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

EE7 Bundle build 88


Tags: 4_0_1-approved

 Description   

For Batch Processing sample, which supposed to include two samples. And there are two samples in the sample list(/samples/docs/list.html)
However there is an additional app named 'partition' under the Batch Sample directory.

As far as I know, the sample app under /partition is the same as /joboperator-api.

Are we going to keep only two in this case?



 Comments   
Comment by Mahesh Kannan [ 18/Jul/14 ]

svn commit -m "GLASSFISH-20537. Add a patitioned step example"
Sending .
Sending docs/index.html
Sending src/main/java/com/oracle/javaee7/samples/batch/partition/PayrollPartitionMapper.java
Sending src/main/java/com/oracle/javaee7/samples/batch/partition/SampleDataHolderBean.java
Sending src/main/java/com/oracle/javaee7/samples/batch/partition/SimpleItemReader.java
Sending src/main/webapp/WEB-INF/classes/META-INF/batch-jobs/PayrollJob.xml
Transmitting file data .....
Committed revision 1214.





[GLASSFISH-20388] BATCH CLI: asadmin list-batch-jobs when the database is down returns Null Pointer Exception Created: 23/Apr/13  Updated: 19/Sep/14  Resolved: 17/Jul/14

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b85
Fix Version/s: 4.1

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-approved

 Description   

Steps

1) Create a cluster with 1 instance.
2) Deploy sample batch app. Don't start the database.
3) asadmin list-batch-jobs returns

remote failure: java.lang.NullPointerException
An error occurred during replication
Failure: Command _ListBatchJobs failed on server instance cl-instance1: remote failure: java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider com.ibm.jbatch.container.api.impl.JobOperatorImpl could not be instantiated: java.lang.RuntimeException: Could not instantiate service com.ibm.jbatch.container.impl.BatchKernelImpl due to exception: java.lang.reflect.InvocationTargetException
javax.batch.operations.JobOperator: Provider com.ibm.jbatch.container.api.impl.JobOperatorImpl could not be instantiated: java.lang.RuntimeException: Could not instantiate service com.ibm.jbatch.container.impl.BatchKernelImpl due to exception: java.lang.reflect.InvocationTargetException
Command list-batch-jobs failed

Although server logs shows connection failed with localhost:1527, but it will be good if the user gets appropriate error message.



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

Arun: It will help if you could post the complete stack trace.

Scott, I cannot print a meaningful stacktrace unless RI throws a more specific exception (Like NoConnectionAvailable etc.)

Comment by arunkumar_s [ 24/Apr/13 ]

[2013-04-23T23:23:40.813-0700] [glassfish 4.0] [WARNING] [poolmgr.get_connection_failure] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors] [tid: _ThreadID=52 _ThreadName=admin-listener(5)] [timeMillis: 1366784620813] [levelValue: 900] [[
RAR5117 : Failed to obtain/create connection from connection pool [ DerbyPool ]. Reason : com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.]]

[2013-04-23T23:23:40.814-0700] [glassfish 4.0] [WARNING] [jdbc.exc_get_conn] [javax.enterprise.resource.resourceadapter.com.sun.gjc.spi] [tid: _ThreadID=52 _ThreadName=admin-listener(5)] [timeMillis: 1366784620814] [levelValue: 900] [[
RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.]]]

[2013-04-23T23:23:40.817-0700] [glassfish 4.0] [SEVERE] [] [com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl] [tid: _ThreadID=52 _ThreadName=admin-listener(5)] [timeMillis: 1366784620817] [levelValue: 1000] [[
FAILED GETTING DATABASE CONNECTION; Exception stack trace: java.sql.SQLException: Error in allocating a connection. Cause: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.gjc.spi.base.AbstractDataSource.getConnection(AbstractDataSource.java:121)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnectionToDefaultSchema(JDBCPersistenceManagerImpl.java:340)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.isDerby(JDBCPersistenceManagerImpl.java:171)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.init(JDBCPersistenceManagerImpl.java:132)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.getService(ServicesManagerImpl.java:358)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.access$300(ServicesManagerImpl.java:341)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getService(ServicesManagerImpl.java:261)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getPersistenceManagerService(ServicesManagerImpl.java:292)
at com.ibm.jbatch.container.impl.BatchKernelImpl.<init>(BatchKernelImpl.java:83)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader._loadService(ServicesManagerImpl.java:404)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader._loadServiceHelper(ServicesManagerImpl.java:377)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.getService(ServicesManagerImpl.java:357)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.access$300(ServicesManagerImpl.java:341)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getService(ServicesManagerImpl.java:261)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getBatchKernelService(ServicesManagerImpl.java:307)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.<init>(JobOperatorImpl.java:72)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at java.lang.Class.newInstance0(Class.java:374)
at java.lang.Class.newInstance(Class.java:327)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at javax.batch.runtime.BatchRuntime$1.run(BatchRuntime.java:52)
at javax.batch.runtime.BatchRuntime$1.run(BatchRuntime.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:47)
at org.glassfish.batch.ListBatchJobs.findJobExecutions(ListBatchJobs.java:177)
at org.glassfish.batch.ListBatchJobs.executeCommand(ListBatchJobs.java:118)
at org.glassfish.batch.AbstractListCommand.execute(AbstractListCommand.java:101)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:319)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:196)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:171)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:166)
at com.sun.gjc.spi.base.AbstractDataSource.getConnection(AbstractDataSource.java:114)
... 101 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:103)
at com.sun.enterprise.resource.pool.ConnectionPool.addResource(ConnectionPool.java:282)
at com.sun.enterprise.resource.pool.ConnectionPool.createResourceAndAddToPool(ConnectionPool.java:1512)
at com.sun.enterprise.resource.pool.ConnectionPool.createResources(ConnectionPool.java:944)
at com.sun.enterprise.resource.pool.ConnectionPool.initPool(ConnectionPool.java:230)
at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:511)
at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:360)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:307)
... 105 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1189)
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
... 115 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.enterprise.resource.allocator.LocalTxConnectorAllocator.createResource(LocalTxConnectorAllocator.java:110)
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
... 117 more
Caused by: javax.resource.spi.ResourceAllocationException: Connection could not be allocated because: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at com.sun.gjc.spi.DSManagedConnectionFactory.createManagedConnection(DSManagedConnectionFactory.java:129)
at com.sun.enterprise.resource.allocator.LocalTxConnectorAllocator.createResource(LocalTxConnectorAllocator.java:87)
... 118 more
Caused by: java.sql.SQLNonTransientConnectionException: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.jdbc.ClientDataSource.getConnection(Unknown Source)
at com.sun.gjc.spi.DSManagedConnectionFactory.createManagedConnection(DSManagedConnectionFactory.java:115)
... 119 more
Caused by: org.apache.derby.client.am.DisconnectException: java.net.ConnectException : Error connecting to server localhost on port 1527 with message Connection refused.
at org.apache.derby.client.net.NetAgent.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection.newAgent_(Unknown Source)
at org.apache.derby.client.am.Connection.initConnection(Unknown Source)
at org.apache.derby.client.am.Connection.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source)
at org.apache.derby.jdbc.ClientDataSource.getConnectionX(Unknown Source)
... 121 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.<init>(Socket.java:425)
at java.net.Socket.<init>(Socket.java:208)
at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:271)
at org.apache.derby.client.net.OpenSocketAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 129 more
]]

[2013-04-23T23:23:40.819-0700] [glassfish 4.0] [SEVERE] [] [com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl] [tid: _ThreadID=52 _ThreadName=admin-listener(5)] [timeMillis: 1366784620819] [levelValue: 1000] [[
Could not instantiate service: com.ibm.jbatch.container.impl.BatchKernelImpl due to exception:java.lang.reflect.InvocationTargetException]]

[2013-04-23T23:23:40.820-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=52 _ThreadName=admin-listener(5)] [timeMillis: 1366784620820] [levelValue: 1000] [[
Exception while running a command
java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider com.ibm.jbatch.container.api.impl.JobOperatorImpl could not be instantiated: java.lang.RuntimeException: Could not instantiate service com.ibm.jbatch.container.impl.BatchKernelImpl due to exception: java.lang.reflect.InvocationTargetException
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at javax.batch.runtime.BatchRuntime$1.run(BatchRuntime.java:52)
at javax.batch.runtime.BatchRuntime$1.run(BatchRuntime.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:47)
at org.glassfish.batch.ListBatchJobs.findJobExecutions(ListBatchJobs.java:177)
at org.glassfish.batch.ListBatchJobs.executeCommand(ListBatchJobs.java:118)
at org.glassfish.batch.AbstractListCommand.execute(AbstractListCommand.java:101)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Could not instantiate service com.ibm.jbatch.container.impl.BatchKernelImpl due to exception: java.lang.reflect.InvocationTargetException
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader._loadServiceHelper(ServicesManagerImpl.java:385)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.getService(ServicesManagerImpl.java:357)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.access$300(ServicesManagerImpl.java:341)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getService(ServicesManagerImpl.java:261)
at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl.getBatchKernelService(ServicesManagerImpl.java:307)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.<init>(JobOperatorImpl.java:72)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at java.lang.Class.newInstance0(Class.java:374)
at java.lang.Class.newInstance(Class.java:327)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
... 75 more
]]

Comment by Mahesh Kannan [ 24/Apr/13 ]

Arun: Could you also post the stacktrace for NPE.

Comment by arunkumar_s [ 24/Apr/13 ]

Null Pointer Exception logs:
[2013-04-24T00:14:41.232-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=756 _ThreadName=admin-listener(47)] [timeMillis: 1366787681232] [levelValue: 1000] [[
Exception while running a command
java.lang.NullPointerException
at org.glassfish.batch.ListBatchJobsProxy.postInvoke(ListBatchJobsProxy.java:108)
at org.glassfish.batch.AbstractListCommandProxy.execute(AbstractListCommandProxy.java:128)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

Comment by Mahesh Kannan [ 29/Apr/13 ]

Batch runtime is throwing a generic 'RuntimeException' and the SQLException is
burried deep down in the chain. I cannot print a meaningful message (that the
database is down) based on this RuntimeException.

This being a minor bug and since the changes involves touching 6 files, I would
like to defer this to 4.0.1

Comment by pjiricka [ 24/Sep/13 ]

I am hitting this again - the behavior is completely unpredictable.

Comment by Mahesh Kannan [ 17/Jul/14 ]

Fixed. QL Passed.

Sending src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending src/main/java/org/glassfish/batch/ListBatchJobsProxy.java
Transmitting file data ......
Committed revision 63511.





[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-20304] BATCH RI: Can't inject an EntityManager in an ItemWriter implementation Created: 12/Apr/13  Updated: 22/Jun/13  Resolved: 18/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b85

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

Glassfish promoted b84.


Tags: batch, cdi

 Description   

Injecting an EntityManager using @PersistenceContext in an ItemWriter implementation results in a null pointer. For example:

...
public class MyWriter implements ItemWriter {
@PersistenceContext
EntityManager em;

@Override
public void open(Serializable s) throws Exception

{ System.out.println(em.toString); // em is a null pointer }

...
}



 Comments   
Comment by ScottKurz [ 16/Apr/13 ]

Would you be able to post a version of this application to help recreate?

Comment by rcervera [ 16/Apr/13 ]

Hi Scott,

I can't add an attachment to this issue on JIRA. I've sent you a very simple application that recreates this issue. This is on Glassfish b84, the last promoted build.

Thanks,

Comment by ScottKurz [ 17/Apr/13 ]

I'm wondering if the key element of this situation is the fact that the batch ItemReader runs on the relatively new managed thread pool (JSR-236) thread rather than the main thread of the servlet.

Could we ask JPA to take a look?

Comment by Mahesh Kannan [ 17/Apr/13 ]

I have the following working:

@Named("SimpleItemReader")
public class SimpleItemReader
extends AbstractItemReader

{ @EJB private SampleDataHolderBean dataBean; ..... }

So, I assume that the JSR 236 implementation is at least setting up the component env and class loader properly. Obviously, injection of PersistenceContext into an EJB is working (we have a lots of devtests, CTS tests for this).

I will try adding a @PostConstruct to my sample to see if it gives any clue.

Maybe, the CDI folks should look into this.

Comment by jjsnyder83 [ 17/Apr/13 ]

How is the instance of MyWriter created? Is it injected into a servlet or some other object?

Comment by ScottKurz [ 17/Apr/13 ]

If we assume the batch artifacts must be instantiated via CDI in order for the JPA injection to work, then the answer is simply that this isn't setup correctly from the batch+CDI perspective.

You're not in fact using CDI here but are falling back to META-INF/batch.xml-based artifact loading.

To fix this:

1) The batch artifacts must be annotated with @Named

2) The JSL @ref value must match the "bean name" (I put this in quotes since I'm not 100% sure this is the correct term).

E.g. you should have:

@Named
public class ExampleReader implements ItemReader {

aligning with JSL:

<step id="mobilefilter">
<chunk checkpoint-policy="item" item-count="10">
<reader ref="exampleReader"></reader> <!-- DEFAULT bean name per CDI -->

Or could have:

@Named("MyReaderBean")
public class ExampleReader implements ItemReader {

aligning with:

<step id="mobilefilter">
<chunk checkpoint-policy="item" item-count="10">
<reader ref="MyReaderBean"></reader>

------------------------------------------------------------------------------

Strictly from the batch perspective, we do support the batch.xml loading. If there is an expectation that this should also "work" in allowing JPA injection then this whole issue needs to be pursued further.

Comment by rcervera [ 17/Apr/13 ]

We will cover this use case in the documentation and examples, unless something changes.

Comment by Mahesh Kannan [ 18/Apr/13 ]

Based on Scott's comment, marking this as resolved

Comment by jimnicolson [ 21/Jun/13 ]

Although this is closed, I have just hit this problem for GF 4 Build 89 (Final release).

I've tried an EJB and a WAR project, with and without a valid persistence.xml and injecting EntityManager using @PersistenceContext and custom CDI Producer annotation.

The Batch processing actions are functional, EcliseLink/JPA initialization seems to be behaving normally, but no EntityManager.

Injection returns null on all three Batch classes Reader, Processor, Writer.

I'm happy to be wrong but at this point there still seems to be a problem.

I have a test WAR (with source included) (17K) but first just making an inquiry sine I'm a newbee to this site.

Comment by rcervera [ 21/Jun/13 ]

jimnicolson, this is no longer an issue; injecting an EntityManager should work. Please see the phonebilling example in the EE 7 tutorial for an example of a batch job that injects an EntityManager:

http://docs.oracle.com/javaee/7/tutorial/doc/batch-processing009.htm

The code for the example is included with the EE 7 SDK.

Comment by jimnicolson [ 22/Jun/13 ]

Thanks it's working but just for future reference:

From @Named to @Named("SimpleBatchReader") resolved the problem.

(I didn't need to add a no-arg constructor to have this work but will do so.)

@Dependent
@Named("SimpleBatchReader")
public class SimpleBatchReader extends AbstractItemReader {

@PersistenceContext
EntityManager em;

@Override
public void open(Serializable checkpoint) throws Exception

{ System.out.println("SimpleBatchReader.open em=" + em); }

....

Looking at the Java EE 7 Tutorial docs (http://docs.oracle.com/javaee/7/tutorial/doc/batch-processing005.htm#BCGIFJBB).

I suggest that it might be a useful addition to add an explicit note/clarification of this 'side-effect'.

Especially as the Batch Job 'works' and there are examples from credible sources (e.g. https://glassfish.java.net/hol/javaee7-hol.pdf See p40) whihc don't clarify this.

i.e. it is not clear that @Named without the string and using a batch.xml in META-INF has this side-effect (when in fact they are alternatives ?)

I had both - seems obvious now of course





[GLASSFISH-20418] xJCL invalid per schema, see SysOut for now for details Created: 26/Apr/13  Updated: 06/May/13  Resolved: 06/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Minor
Reporter: myfear Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Jdk7


Tags: 4_0-approved, fishcat

 Description   

If I have a invalid job.xml I get the following exception which I find is not very helpful at all.
Is there any chance to improve this for the developers?

At least a hint what exactly went wrong would be a good idea ...

Caused by: java.lang.IllegalArgumentException: xJCL invalid per schema, see SysOut for now for details
at com.ibm.jbatch.container.jsl.impl.JobModelResolverImpl.unmarshalJobXML(JobModelResolverImpl.java:73)
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:120)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:105)
at net.eisele.glassfish.jbatchexample.sb.SalesBean.runJob(SalesBean.java:45)
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:601)
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:46)
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:601)
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.aroundInvoke(SystemInterceptorProxy.java:140)
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:601)
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.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 61 more



 Comments   
Comment by ScottKurz [ 30/Apr/13 ]

The SAXParseException you'd get is a good clue to start. We should just change to a Logger warning() message rather than writing to SysOut (which I don't even understand the handling of). Will make that change at next opportunity to ship a fix.

Comment by Mahesh Kannan [ 30/Apr/13 ]

Assigning to Scott

Comment by Mahesh Kannan [ 30/Apr/13 ]

Scott, I assume that the this is a very low risk fix.

Comment by ScottKurz [ 30/Apr/13 ]

It is low risk. It shouldn't impact any runtime logic... we just had the validation handler code doing: System.out.println() that I can change to do a logger.warning().

Comment by ScottKurz [ 03/May/13 ]

In case it helps let me show what the message will look like in the server log.

We're using:

http://docs.oracle.com/javaee/5/api/javax/xml/bind/ValidationEventHandler.html

and the server log entry will look something like this:

LINKED EXC: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'listeners'. One of '

{"http://xmlns.jcp.org/xml/ns/javaee":reader}

' is expected.
LOCATOR INFO:
------------
COLUMN NUMBER: 14
LINE NUMBER: 23
OFFSET: -1
CLASS: class javax.xml.bind.helpers.ValidationEventLocatorImpl
NODE: null
OBJECT: null
URL: null|#]

[#|2013-05-03T16:56:36.614-0400|WARNING|glassfish 4.0|com.ibm.jbatch.jsl.util.JSLValidationEventHandler|_ThreadID=27;_ThreadName=http-listener-1(4);_TimeMillis= 1367614596614;_LevelValue=900;|
JSL invalid per XSD, details:
MESSAGE: unexpected element (uri:"http://xmlns.jcp.org/xml/ns/javaee", local:"listeners"). Expected elements are <

{http://xmlns.jcp.org/xml/ns/javaee}

skippable-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

no-rollback-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

retryable-exception-classes>,<

{http://xmlns.jcp.org/xml/ns/javaee}

reader>,

{http://xmlns.jcp.org/xml/ns/javaee}

checkpoint-algorithm>,<

{http://xmlns.jcp.org/xml/ns/javaee}

processor>,<

{http://xmlns.jcp.org/xml/ns/javaee}

writer>

Comment by myfear [ 06/May/13 ]

That looks good to me! Thanks!

Comment by Mahesh Kannan [ 06/May/13 ]
  • What is the impact on the customer of the bug?
    User may not get a clear idea about what went wrong / where the error is in a job xml
  • What is the cost/risk of fixing the bug?
    Very, Very low, and in fact has already been fixed in b29 itself.
    Doesn't affect CTS tests at all. I have run the batch devtests as well.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    NA
Comment by Tom Mueller [ 06/May/13 ]

Approved for 4.0.

Comment by Mahesh Kannan [ 06/May/13 ]

The issue was fixed when we integrated b29 jars. Here are the commit messages for b29 integration

Integrate b29 jars:

============================

Branch commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61832.

=============================

Trunk commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61833.

==============================





[GLASSFISH-20471] Add properties to partitition mapper Created: 06/May/13  Updated: 06/May/13  Resolved: 06/May/13

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

Type: New Feature Priority: Minor
Reporter: myfear Assignee: michael.y.chen
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

 Description   

Hi,

I was wondering if it could make sense to add a <properties> element to a <partition> <mapper ref="entriesPartitioner"> entry.
E.g. if you have a large file to process and need to hand over the file url of that one ... at the moment something like this isn't possible with a mapper .. you have to manually add a plan (a plan knows properties)

<partition>
<mapper ref="entriesPartitioner">
<properties>
<property name="file.url" value="#

{jobParameters['file.url']}

" />
</properties>
</mapper>
</partition>



 Comments   
Comment by myfear [ 06/May/13 ]

Seems to be my error. It actually works. Sorry. Please close ...





[GLASSFISH-20440] [BATCH RI] Batch Runtime fails to call listeners for partitioned steps Created: 30/Apr/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Major
Reporter: ScottKurz Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Tags: 4_0-approved

 Description   

The batch runtime fails to call any of the spec'd programming model's listeners for a partitioned step on the partitioned threads.

Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.

This is a significant restriction on the programming model for partitioned steps.



 Comments   
Comment by Mahesh Kannan [ 03/May/13 ]
  • What is the impact on the customer of the bug?
    Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.
  • What is the impact on the customer of the bug?
    This is a significant restriction on the programming model for partitioned steps.
  • What is the cost/risk of fixing the bug?
    Very low, since the RI team has already run the TCK / CTS tests
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests

Which is the targeted build of 4.0 for this fix?
88.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in?
Requires b30 jars from IBM Batch

Comment by Mahesh Kannan [ 03/May/13 ]
  • What is the impact on the customer of the bug?
    Though we do call the StepListener's beforeStep()/afterStep() on the main thread, we fail to call ChunkListener, SkipListener, RetryListener, ItemReadListener, etc. on each partitioned threads.
  • What is the impact on the customer of the bug?
    This is a significant restriction on the programming model for partitioned steps.
  • What is the cost/risk of fixing the bug?
    Very low, since the RI team has already run the TCK / CTS tests
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    Requires b30 jars from IBM Batch

The pom.xml changes diffs are pasted below:

svn diff main/appserver/pom.xml
Index: main/appserver/pom.xml
===================================================================
— main/appserver/pom.xml (revision 61823)
+++ main/appserver/pom.xml (working copy)
@@ -125,9 +125,9 @@
<jsonp.version>1.0</jsonp.version>
<concurrent-api.version>1.0</concurrent-api.version>
<concurrent.version>1.0</concurrent.version>

  • <javax.batch-api.version>1.0-b26</javax.batch-api.version>
  • <com.ibm.jbatch-runtime-all.version>1.0-b26</com.ibm.jbatch-runtime-all.version>
  • <com.ibm.jbatch-ri-spi.version>1.0-b26</com.ibm.jbatch-ri-spi.version>
    + <javax.batch-api.version>1.0-b30</javax.batch-api.version>
    + <com.ibm.jbatch-runtime-all.version>1.0-b30</com.ibm.jbatch-runtime-all.version>
    + <com.ibm.jbatch-ri-spi.version>1.0-b30</com.ibm.jbatch-ri-spi.version>
    <javax.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
    <javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
    </properties>
Comment by Mahesh Kannan [ 04/May/13 ]

Actullay, need to integrate b29 jars

svn diff appserver/pom.xml
Index: appserver/pom.xml
===================================================================
— appserver/pom.xml (revision 61827)
+++ appserver/pom.xml (working copy)
@@ -126,9 +126,9 @@
<jsonp.version>1.0</jsonp.version>
<concurrent-api.version>1.0</concurrent-api.version>
<concurrent.version>1.0</concurrent.version>

  • <javax.batch-api.version>1.0-b26</javax.batch-api.version>
  • <com.ibm.jbatch-runtime-all.version>1.0-b26</com.ibm.jbatch-runtime-all.version>
  • <com.ibm.jbatch-ri-spi.version>1.0-b26</com.ibm.jbatch-ri-spi.version>
    + <javax.batch-api.version>1.0-b29</javax.batch-api.version>
    + <com.ibm.jbatch-runtime-all.version>1.0-b29</com.ibm.jbatch-runtime-all.version>
    + <com.ibm.jbatch-ri-spi.version>1.0-b29</com.ibm.jbatch-ri-spi.version>
    <javax.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
    <javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
    </properties>
Comment by Mahesh Kannan [ 04/May/13 ]

Integrate b29 jars:

============================

Branch commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61832.

=============================

Trunk commit info:

svn commit -m "Fix for 20440. QL Passed. Batch devtests passed. Approved by Michael" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 61833.

==============================





[GLASSFISH-20428] [Regression] BATCH CLI: asadmin list-batch-job-executions or list-batch-steps with an operand value returns IllegalArgumentException Created: 29/Apr/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b88_RC4

Type: Bug Priority: Blocker
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL6


Tags: 4_0-approved

 Description   

Looks like fix for GLASSFISH-20264 caused this issue

Steps:

1) Run asadmin list-batch-job-executions <instance_id>

bash-4.1$ asadmin list-batch-job-executions 1
remote failure: Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
Usage: list-batch-job-executions [--executionid=executionid] [--terse=false] [--output=output] [--header=header] [--target=server] [--long=long] [instanceid]
Command list-batch-job-executions failed.

Stacktrace:

[2013-04-29T04:36:10.064-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1367235370064] [levelValue: 1000] [[
Exception while running a command
java.lang.IllegalArgumentException: Can not set java.lang.Long field org.glassfish.batch.ListBatchJobExecutionsProxy.instanceId to java.lang.String
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:680)
at org.jvnet.hk2.config.InjectionManager.syncDoInject(InjectionManager.java:171)
at org.jvnet.hk2.config.InjectionManager.inject(InjectionManager.java:73)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.injectParameters(CommandRunnerImpl.java:362)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1188)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by Mahesh Kannan [ 04/May/13 ]
  • What is the impact on the customer of the bug?
    Cannot list batch job executions or steps. So this is a significant regression
  • What is the cost/risk of fixing the bug?
    Very low, and fixing involves changing a few lines in three files.
    Doesn't affect CTS tests at all. I have run the batch devtests as well.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Batch QE tests
  • Which is the targeted build of 4.0 for this fix?
    88.
  • If this an integration of a new version of a component from another project,
    What are the changes that are being brought in?
    NA
Comment by Mahesh Kannan [ 04/May/13 ]

The fix is to check if the input is a long.

===============================

Branch commit info:

svn commit -m "Fix for 20428. QL Passed. Batch devtests passed. Approved by Michael"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Transmitting file data ....
Committed revision 61830.
makannan-mac% svn info
Path: .
URL: https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/batch
Repository Root: https://svn.java.net/svn/glassfish~svn
Repository UUID: 6f3ba3e3-413c-0410-a8aa-90bee3ab43b5
Revision: 61829
Node Kind: directory
Schedule: normal
Last Changed Author: mk111283
Last Changed Rev: 61563
Last Changed Date: 2013-04-19 10:28:11 -0700 (Fri, 19 Apr 2013)

=========================

trunk commit info:

svn commit -m "Fix for 20428. QL Passed. Batch devtests passed. Approved by Michael"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Transmitting file data ...

==========================





[GLASSFISH-20406]  @Inject @BatchProperty not working Created: 25/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

Type: Bug Priority: Major
Reporter: myfear Assignee: Mahesh Kannan
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7, JDK 7


Tags: fishcat

 Description   

Trying to use a batch property in a reader:

@Named("entryReader")
public class EntryReader extends AbstractItemReader {

@Inject
@BatchProperty(name = "file.url")
String fileName;
//...
}

Either defining it as

<reader ref="entryReader" >
<properties>
<property name="file.url" value="#

{jobParameters['file.url']}

" />
</properties>
</reader>

with

JobOperator jo = BatchRuntime.getJobOperator();
Properties jobParams = new Properties();
jobParams.put("file.url", "testdata.txt");
long jobId = jo.start("extract-cities", jobParams);

nor directly defining it in the job.xml works.
It always resolves to null.

Try the example here:
https://www.dropbox.com/s/zujizha4jhkhtzd/jbatchexample.zip

The EntryReader is where the injection should take place.



 Comments   
Comment by arunkumar_s [ 25/Apr/13 ]

If you can use the inject variable(filename) for verifying values in the open() method of the Reader, rather than the constructor, then it returns the values from passed JobParameters.

Comment by myfear [ 26/Apr/13 ]

That actually worked. Close please.

Comment by Mahesh Kannan [ 26/Apr/13 ]

Closing this issue as the submitter has confirmed that this is indeed working





[GLASSFISH-19911] BATCH CLI: asadmin list-batch-jobs -o not working with the options specified in help Created: 18/Mar/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

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


 Description   

Tested with 4.0 b80

asadmin list-batch-jobs --help shows the below options for -o or --output. But all of them are not working as expected. Eg: Help shows job-name as one option, but actually jobname only works

--output, -o
Displays specific details about each job. Use a comma-separated
list to specify the details you want to display and their order.
The values are case-insensitive. The job-name and instance-count
column headings are displayed by default.

Possible values are as follows:

job-name
Displays the name of the job.

instance-count
Displays the number of job instances that are running.

execution-id
Displays the execution ID of a particular job instance.

status
Displays the status of the job.

exit-status
Displays the exit status of the job.

start-time
Displays the start time of the job.

end-time
Displays the finish time of the job.

job-parameters
Displays the job parameters.



 Comments   
Comment by michael.y.chen [ 25/Apr/13 ]

I assume this is fixed.

Comment by Mahesh Kannan [ 25/Apr/13 ]

This has been fixed a while back by Gail Risdal.

Here is the command output:

asadmin list-batch-jobs --help
list-batch-jobs(1) asadmin Utility Subcommands list-batch-jobs(1)

NAME
list-batch-jobs - lists batch jobs

SYNOPSIS
list-batch-jobs [--help]
[--target target]
[--long=

{false|true}]
[--output output]
[--header={false|true}

]
[job_name]

DESCRIPTION
The list-batch-jobs subcommand lists batch jobs and job details.

OPTIONS
--help, -?
Displays the help text for the subcommand.

--target
Specifies the target for which to list batch jobs and job details.
Valid values are as follows:

server
Lists batch jobs for the default server instance server and is
the default value.

cluster-name
Lists batch jobs for every server instance in the cluster.

instance-name
Lists batch jobs for a particular server instance.

--long, -l
Displays detailed information about batch jobs. The default value
is false.

--output, -o
Displays specific details about batch jobs. Use a comma-separated
list to specify the details to display and their order. The values
are case-insensitive. The jobname and instancecount column headings
are displayed by default.

Possible values are as follows:

jobname
Displays the name of the job.

appname
Displays the name of the application.

instancecount
Displays the number of job instances.

instanceid
Displays the ID assigned to the job instance.

executionid
Displays the ID assigned to the execution of the batch job. A
new execution is created the first time a job is started and
every time the existing execution is restarted.

batchstatus
Displays the status of the job as set by the batch runtime.

starttime
Displays the start time of the job.

endtime
Displays the finish time of the job.

exitstatus
Displays the status of the job as set by the Job XML for the
job or by the batch application. By default, the exit status
and the batch status are the same unless the exit status is
explicitly overridden.

--header, -h
Specifies whether column headings are displayed when the --long
option is used. The default value is true. To suppress the
headings, set the --header option to false.

OPERANDS
job_name
The name of the job for which to list details.

EXAMPLES
Example 1, Listing Batch Jobs
This example lists batch jobs for the default server instance.

asadmin> list-batch-jobs
JOBNAME INSTANCECOUNT
payroll 9
bonus 6
Command list-batch-jobs executed successfully.

EXIT STATUS
0
subcommand executed successfully

1
error in executing the subcommand

SEE ALSO
list-batch-job-executions(1), list-batch-job-steps(1),
set-batch-runtime-configuration(1), list-batch-runtime-configuration(1)

asadmin(1M)

Java EE 7 13 Feb 2013 list-batch-jobs(1)
Command list-batch-jobs executed successfully.





[GLASSFISH-20264] BATCH CLI: asadmin list-batch-job-executions with some string operands shows no error message Created: 10/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

Tested with latest build

asadmin list-batch-job-executions p

For input string: "p"
Command list-batch-job-executions executed successfully.

Expected: Command should fail, says no instance id p found.

Same case for list-batch-job-steps



 Comments   
Comment by Mahesh Kannan [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    Without this fix the command will report success despite being pass an invalid parameter
  • What is the cost/risk of fixing the bug?
    Very low. Just a few lines.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    All batch tests. Although I have run batch devtests and QL.
  • Which is the targeted build of 4.0 for this fix?
    The fix is ready, Most likely in RC2.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Mahesh Kannan [ 19/Apr/13 ]

I changed the data type to Long which means this command takes only an int or long as parameter. Any other input will be flagged as an error by CLI framework

svn commit -m "Integrate b26 jars. Fix for 20335, 20264. QL and batch devtests passed. Approved by Tom"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending appserver/pom.xml
Transmitting file data ....
Committed revision 61563.





[GLASSFISH-20335] [BATCH RI] PartitionedStepControllerImpl is one-off when retrieving work from parallelBatchWorkUnits Created: 17/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b86_RC2

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

3.5.0-24-generic #37-Ubuntu SMP Thu Feb 7 01:50:30 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


Tags: 4_0-approved

 Description   

Disclaimer: The bug was found on b25 of the BATCH-RI

Example: Partition plan with 4 partitions and 2 threads
On line 334
// Start up to to the max num we are allowed from the num threads attribute
The variable numCurrentSubmitted has value 2 after completing this

Starting from line 375
if (readyToSubmitAnother) {
numCurrentCompleted++;
logger.fine("Ready to submit another (if there is another left to submit); numCurrentCompleted = " + numCurrentCompleted);
if (numCurrentCompleted < numTotalForThisExcecution) {
if (numCurrentSubmitted < numTotalForThisExcecution) {
numCurrentSubmitted++;
logger.fine("Submitting # " + numCurrentSubmitted + " out of " + numTotalForThisExcecution + " total for this execution");
if (stepStatus.getStartCount() > 1)

{ batchKernel.startGeneratedJob(parallelBatchWorkUnits.get(numCurrentSubmitted)); }

else

{ batchKernel.restartGeneratedJob(parallelBatchWorkUnits.get(numCurrentSubmitted)); }

readyToSubmitAnother = false;

The numCurrentSubmitted is increased to 3 and the next workUnit is retrieved is 3, thereby skipping entry 2 of the arry.
This means that while retrieving the last workUnit an exception is thrown and the third workUnit is never executed.

The exception was:
Wed Apr 17 19:37:41 CEST 2013 [com.ibm.jbatch.container.impl.BaseStepControllerImpl execute] WARNING: Caught exception executing step: java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at com.ibm.jbatch.container.impl.PartitionedStepControllerImpl.executeAndWaitForCompletion(PartitionedStepControllerImpl.java:385)



 Comments   
Comment by blankema [ 17/Apr/13 ]

I have a test project (maven based) and a patch file but could not find where to upload it.

If needed, just contact me.

Comment by shreedhar_ganapathy [ 17/Apr/13 ]

-> Mahesh for eval on Batch RI.

Comment by Mahesh Kannan [ 18/Apr/13 ]

Just wanted to add that currently (RC1) GlassFish is using only b23 batch jars.
Anyways, Scott can comment on this more

Comment by ScottKurz [ 18/Apr/13 ]

This is a bug. As we didn't test @threads in the TCK we ended up not testing it at all. I will fix in the next drop.

Comment by ScottKurz [ 18/Apr/13 ]

Actually there's another bug here where we're neglecting to even honor the @threads attribute. I'm guessing this is the patch file mentioned since without this fixed I can't see how you could have created this in the first place. If you want to send it in case there's something else I missed.. you can send to ScottKurz@java.net, but I think I have this fixed now. Thanks for identifying this...

BTW, Mahesh... I think this is b25. The 84 driver was supposed to have been built on 10 Apr 2013 ... and we delivered b25 on 4/9.

Comment by Mahesh Kannan [ 19/Apr/13 ]
  • What is the impact on the customer of the bug?
    Without this fix some workUnit is never executed
  • What is the cost/risk of fixing the bug?
    Medium. Just a few lines. But Scott has already fixed this.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    All batch tests. Although I have run batch devtests and QL.
  • Which is the targeted build of 4.0 for this fix?
    The fix is ready, Most likely in RC2.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    This requires integration of b26 jars from IBM
Comment by Tom Mueller [ 19/Apr/13 ]

Approved for 4.0, but in the future please fill out the change control template.

Comment by ScottKurz [ 19/Apr/13 ]

Just confirming that this is indeed fixed in 1.0-b26.

Comment by Mahesh Kannan [ 19/Apr/13 ]

Resolved in b26 jars.

Svn commit info

svn commit -m "Integrate b26 jars. Fix for 20335, 20264. QL and batch devtests passed. Approved by Tom"
Sending appserver/pom.xml
Transmitting file data ....
Committed revision 61563.





[GLASSFISH-20331] [Batch CLI] NPE thrown out when start the domain Created: 17/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b86_RC2

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

Win7


Tags: 4_0-approved

 Description   

The NPE were thrown out on the version of glassfish which I have built at 12/4/2013 in my local platform. Here's my reproduced steps:
1). asadmin start-domain
2). asadmin create-instance ins1
3). asadmin deploy test_sample1.war
4). asadmin deploy test_sample2.war
5). asadmin stop-domain
6). asadmin start-domain

After step6, the NPE were thrown out as follows:

[2013-04-17T19:51:55.327+0900] [glassfish 4.0] [WARNING] [NCLS-CORE-00069] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1366195915327] [levelValue: 900] [[
  Exception while dispatching an event
java.lang.NullPointerException
	at org.glassfish.batch.spi.impl.BatchRuntimeHelper.registerIfBatchJobsDirExists(BatchRuntimeHelper.java:178)
	at org.glassfish.batch.spi.impl.BatchRuntimeHelper.event(BatchRuntimeHelper.java:191)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
	at com.sun.enterprise.v3.server.AppServerStartup.postStartupJob(AppServerStartup.java:358)
	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:285)
	at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:179)
	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:170)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
	at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.start(EmbeddedOSGiGlassFishImpl.java:75)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
	at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
	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:601)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
]]


 Comments   
Comment by Jeremy_Lv [ 17/Apr/13 ]

Here's attached the code of the reproduced web application:
test_sample1.war

package com.fujitsu.test.hello;


import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


/**
*
* @author Jeremy
*/
@WebServlet(name="MyServlet", urlPatterns={""})
public class UserServlet extends HttpServlet {

   protected void processRequest(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       response.setContentType("text/html;charset=UTF-8");
       PrintWriter out = response.getWriter();
       try {
           out.println("<html>");
           out.println("<head>");
           out.println("<title>Servlet3.0 HelloWorld</title>");
           out.println("</head>");
           out.println("<body>");
           out.println("<h1>Hello! Servlet3.0 Sample1111111111</h1>");
           System.out.println("start to execute System.exit()");
           System.exit(1);
           System.out.println("System.exit() has been executed");
           out.println("</body>");
           out.println("</html>");
         
       } finally { 
           out.close();
       }
   } 

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   } 

   @Override
   protected void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   }


   @Override
   public String getServletInfo() {
       return "Short description";
   }
}

test_sample2.war

package com.fujitsu.test.hello;


import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


/**
*
* @author Jeremy
*/
@WebServlet(name="MyServlet", urlPatterns={""})
public class UserServlet extends HttpServlet {

   protected void processRequest(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       response.setContentType("text/html;charset=UTF-8");
       PrintWriter out = response.getWriter();
       try {
           out.println("<html>");
           out.println("<head>");
           out.println("<title>Servlet3.0 HelloWorld</title>");
           out.println("</head>");
           out.println("<body>");
           out.println("<h1>Hello! Servlet3.0 Sample22222222222</h1>");
           System.out.println("start to execute System.exit()");
           System.out.println("System.exit() has been executed");
           out.println("</body>");
           out.println("</html>");
         
       } finally { 
           out.close();
       }
   } 

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   } 

   @Override
   protected void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
       processRequest(request, response);
   }


   @Override
   public String getServletInfo() {
       return "Short description";
   }
}

The only difference between the test_sample1 and test_sample2 is that I add the code of "System.exit(1);" in the test_sample1.

Comment by Jeremy_Lv [ 17/Apr/13 ]

If anyone need these two applications, pl. send the mail to me(lvsongping@cn.fujitsu.com).

Comment by TangYong [ 17/Apr/13 ]

This seemed to be batch module's issue.

Comment by TangYong [ 17/Apr/13 ]

Also noting the issue happened on cluster scene.

Comment by Mahesh Kannan [ 17/Apr/13 ]

Marking as Batch CLI issue

Comment by Mahesh Kannan [ 18/Apr/13 ]

First of all couldn't reproduce this issue.

The offending line (@ 178) is as follows:

ClassLoader cl = moduleInfo.getModuleClassLoader();
@178 ==> if (cl.getResource("META-INF/batch-jobs") != null)

{ tagNamesRequiringCleanup.add(config.getName() + ":" + applicationInfo.getName()); }

The only way this could happen is if moduleInfo.getModuleClassLoader(); is null (System class loader). Not sure if apps can be
deployed using system CL.

Anyways, I have added a null check to this line as follows:
ClassLoader cl = moduleInfo.getModuleClassLoader();
@178 ==> if (cl != null && cl.getResource("META-INF/batch-jobs") != null)

{ tagNamesRequiringCleanup.add(config.getName() + ":" + applicationInfo.getName()); }
Comment by Jeremy_Lv [ 18/Apr/13 ]

Mashech:
Here's some comments in line:
1). I will update the source to the latest one and check whether the NPE is still exist.
2). pl. tell me your mail address so that I can send you these two application and you can reproduce in your platform.
3). I will also try to add the null check you have pointed out to check whether the issue is still exist.

Thanks

-jeremy

Comment by Jeremy_Lv [ 18/Apr/13 ]

Sorry about the wrong steps, Here's the exactly steps:
1. asadmin start-domain
2. asadmin create-cluster clu1
3. asadmin create-instance --node localhost-domain1 --cluster clu1 instance1
4. asadmin deploy --target clu1 test_sample1.war
5. asadmin deploy --target clu1 test_sample2.war
6. asadmin stop-domain
7. asadmin start-domain

Comment by Mahesh Kannan [ 18/Apr/13 ]

Thanks for listing the exact steps. Yes, now I can reproduce. Fix will be available in the next build

Comment by Mahesh Kannan [ 18/Apr/13 ]

What is the impact on the customer of the bug?
If any application has been deployed to a cluster / standalone instance, User will see an NPE when the domain is re-started.

What is the cost/risk of fixing the bug?
Very low. A few lines.

Is there an impact on documentation or message strings?
Yes. Logging a message at Warning Level should any other exception occur.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
I have run the devtests successfully. The bug submitter was kind enough to do a bunch of tests.
<from-submitter>
Here's my steps to tests:
1). asadmin start-domain
2). asadmin create-cluster clu1
3). asadmin create-instance --cluster clu1 --node localhost-domain1 instance1
4). asadmin deploy test_sample1.war
5). asadmin deploy --target clu1 test_sample2.war
6). asadmin stop-domain
7). asadmin start-domain
8). asadmin stop-cluster clu1
9). asadmin start-cluster clu1
10). asadmin undeploy test_sample1
11). asadmin undeploy --target clu1 test_sample2

After all, there's no NPE were thrown out after applied your changes into the latest building source.

BTW: I have also run the QL tests and all of the tests passed

QL tests results:

testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 117, Failures: 0, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
</from-submitter>

Which is the targeted build of 4.0 for this fix?
The fix is ready, not sure if it will make it into RC2.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by Mahesh Kannan [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    Without this fix the user will see an NPE during restart if any apps have been deployed to a cluster)
  • What is the cost/risk of fixing the bug?
    Very low. Just a few lines.
  • Is there an impact on documentation or message strings?
    Yes. A Few message Strings
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    All batch tests. Although I have run batch devtests and the bug submitter has extensively tested the patch.

Which is the targeted build of 4.0 for this fix?
The fix is ready, Most likely in RC2.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
N/A

Comment by Tom Mueller [ 18/Apr/13 ]

Approved for 4.0.

Comment by Mahesh Kannan [ 19/Apr/13 ]

svn commit -m "Fix for 20331. QL and Batch devtests passed. Approved by Tom" glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java

Sending glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Transmitting file data .
Committed revision 61549.





[GLASSFISH-20311] [SDK]Java EE 7 sample-The JobOperator API Batch Sample Application AND The Payroll Batch Sample Application Created: 15/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

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

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

EE7 sdk build84


Tags: 4_0-approved

 Description   

In the doc, there is one build instruction 'mvn build'. I got no build phases exceptions from maven. Is it correct command line?
It works if I am going to use 'mvn install'

Attached original line below:

-Build the sample application by running the mvn build command from a command line terminal.



 Comments   
Comment by Daniel [ 15/Apr/13 ]

The exceptions are attached below:
[ERROR] Unknown lifecycle phase "build". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy, pre-clean, clean, post-clean. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/LifecyclePhaseNotFoundException

Comment by shreedhar_ganapathy [ 17/Apr/13 ]

Assigning to Mahesh for now

Comment by Mahesh Kannan [ 18/Apr/13 ]

Agreed. It should have been mvn package (instead of mvn build)

Comment by Mahesh Kannan [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    The doc instructs the users to use 'mvn build' which is totally wrong. It should have been 'mvn package'
  • What is the cost/risk of fixing the bug?
    Very low. Just updating the index.html
  • Is there an impact on documentation or message strings?
    No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Actually, none. The fix is to just update index.html

Which is the targeted build of 4.0 for this fix?
The fix is ready, not sure if it will make it into RC2.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by Tom Mueller [ 18/Apr/13 ]

Approved for 4.0

Comment by Mahesh Kannan [ 18/Apr/13 ]

Here are the diffs:

svn diff payroll/docs/index.html partition/docs/index.html joboperator-api/docs/index.html
Index: payroll/docs/index.html
===================================================================
— payroll/docs/index.html (revision 1127)
+++ payroll/docs/index.html (working copy)
@@ -191,7 +191,7 @@
the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
<li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/payroll</code>.
</li>

  • <li>Build the sample application by running the <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running the <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running the <code>asadmin deploy --force target/payroll.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <code>http://localhost:8080/payroll/JobSubmitterServlet</code>.<br>
    (The port number might vary.)</li>
    Index: partition/docs/index.html
    ===================================================================
      • partition/docs/index.html (revision 1127)
        +++ partition/docs/index.html (working copy)
        @@ -173,7 +173,7 @@
        the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
        <li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/joboperator-api</code>.
        </li>
  • <li>Build the sample application by running <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running <code>asadmin deploy --force target/joboperator-api.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <a href="http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet">http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet</a>.
    (The port number might vary.)</li>
    Index: joboperator-api/docs/index.html
    ===================================================================
      • joboperator-api/docs/index.html (revision 1127)
        +++ joboperator-api/docs/index.html (working copy)
        @@ -174,7 +174,7 @@
        the <a href="../../../docs/UserREADME.html">common build instructions.</a></li>
        <li><code><i>samples_install_dir</i></code> is the sample application base directory. Go to: <code><i>samples_install_dir</i>/javaee7/batch/joboperator-api</code>.
        </li>
  • <li>Build the sample application by running the <code>mvn build</code> command from a command line terminal.</li>
    + <li>Build the sample application by running the <code>mvn package</code> command from a command line terminal.</li>
    <li>Deploy the sample application by running the <code>asadmin deploy --force target/joboperator-api.war</code> command from a command line terminal.</li>
    <li>The front page of this sample is at <code>http://localhost:8080/joboperator-api/PayrollJobSubmitterServlet</code><br>
    (The port number might vary.)</li>

Svn commit message:

svn commit -m "Fix for 20311. Approved by Tom." payroll/docs/index.html partition/docs/index.html joboperator-api/docs/index.html
Sending joboperator-api/docs/index.html
Sending partition/docs/index.html
Sending payroll/docs/index.html
Transmitting file data ...
Committed revision 1128.





[GLASSFISH-20284] NullPointerException An error occurred during replication Failure Created: 11/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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

Name of the Operating System: Windows 7
Binary Architecture name of the Operating System: amd64, Version: 6.1
JRE name: Java HotSpot(TM) 64-Bit Server VM Vendor: Oracle Corporation Version: 23.0-b16
GlassFish Server Open Source Edition 4.0 (build 83)


Tags: fishcat

 Description   

Created a cluster with one node and two instances (instance1 & instance2).
Started the cluster.
Accessed the "Batch" Tab via the cluster gave this exception:

[2013-04-11T07:26:00.060+0200] [glassfish 4.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=148 _ThreadName=admin-listener(6)] [timeMillis: 1365657960060] [levelValue: 1000] [[
Exception while running a command
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:432)
at org.glassfish.batch.ListBatchJobsProxy.postInvoke(ListBatchJobsProxy.java:108)
at org.glassfish.batch.AbstractListCommandProxy.execute(AbstractListCommandProxy.java:122)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommandLegacyFormat(TemplateExecCommand.java:161)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGetLegacyFormat(TemplateCommandGetResource.java:75)
at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-11T07:26:00.067+0200] [glassfish 4.0] [SEVERE] [] [org.glassfish.admingui] [tid: _ThreadID=158 _ThreadName=admin-listener(12)] [timeMillis: 1365657960067] [levelValue: 1000] [[
RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/list-batch-jobs'; attrs = '

{target=my-cluster, long=true}

']]



 Comments   
Comment by myfear [ 11/Apr/13 ]

Here is a screenshot:
https://www.dropbox.com/s/au6srenk2hl1m0p/batch_admin_ui_error_cluster.PNG

Comment by Mahesh Kannan [ 11/Apr/13 ]

This has been resolved in b84 itself.

svn revision 61272.





[GLASSFISH-20100] Batch RI: Transition Elements not working other than COMPLETED exit status Created: 29/Mar/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly.

Steps:

1) <fail on="COMPLETED" exit-status="EARLY COMPLETION"/> in Job XML for a <step> element.

This works fine.Step which exits with COMPLETED exit status sets the JOB exit status as EARLY COMPLETION

I tried with other possibilities given below, but these possibilities wont set the JOB exit status as expected.

<fail on="FAILED" exit-status="EARLY FAIL"/>
I have thrown an exception in a process execution,so the step fails with FAILED exit status. Step exit status get set as FAILED, but <fail> element didn't work.

<fail on="STOPPED" exit-status="EARLY STOP"/>
Used JobOperator.stop() to stop a process execution

The same case applies to all other transition elements: end,next,stop



 Comments   
Comment by ScottKurz [ 01/Apr/13 ]

We have a few of these tests doing similar things in the TCK that have passed on every released version.

Can you make the test app and/or logs available?

Comment by arunkumar_s [ 02/Apr/13 ]

Couldn't able to attach here.

Attached the deployable war file in https://www.dropbox.com/s/8yn5fcwtqv0dwfu/SampleBatchlets.war

http://<Server>:<port>/SampleBatchlets/SimpleBatchletServlet

Has three tests, One for Running a Job till it completes, Second Running a Job and Stopping in between , and third an Interrupted JOB(throwing some exceptions in Job process in between)

Transition elements in Job XML.

<fail on="COMPLETED" exit-status="EARLY COMPLETION"/>
<fail on="STOPPED" exit-status="EARLY STOP"/>
<fail on="FAILED" exit-status="EARLY FAIL"/>

Comment by ScottKurz [ 02/Apr/13 ]

Now that I see what you're doing, I believe that we may indeed have had a gap here that we closed in more recent drops, which I think should go into the 4.0_b83 build.

I need to come back to this and give it some more thought and maybe try your app. In the meantime, I would suggest that if you get the b83 build before I get back to this that you might give it a try.

Comment by ScottKurz [ 08/Apr/13 ]

Hi,

This issue forced us to go back to the EG and rethink a couple of our implementation details. It looks like where we're ending up is that the
normal completion and exception thrown paths will work as your test expects (once we deliver a fix).

On the other hand, there'll be no transitions after a stop. JobOperator.stop() means stop, as soon as possible (roughly speaking).

So these two exit statuses will be seen, but not the "EARLY STOP".

<fail on="COMPLETED" exit-status="EARLY COMPLETION"/>
<fail on="FAILED" exit-status="EARLY FAIL"/>

After a stop, you could check for BatchStatus.STOPPED on job/step completion. You could also do something like use a StepListener and/or JobListener to query the current BatchStatus and set a special "is stopping" exit status on the JobContext.

Note while the artifacts are still executing you'll see BatchStatus of STOPPING, not (yet) STOPPED.

Will deliver this change with our next drop, probably today.

Comment by ScottKurz [ 10/Apr/13 ]

Resolved,

But as I mentioned the STOPPED portion of the test needs to change since it isn't valid.





[GLASSFISH-20155] BATCH RI: Retryable exception not reprocess the current chunk Created: 03/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly

1) Start a job with some retryable exceptions

In my app, i throwed some retryable exceptions specified in job xml in ItemWriter.

PFD says it will reprocess the chunk if any retryable exceptions occur.

Is the job start read,process,write from the beginning of the chunk?

Issue --> It is not reprocessing the chunk again. It just continues read,process,write items with chunk item count=1



 Comments   
Comment by ScottKurz [ 03/Apr/13 ]

Could you please point me to the application? (Maybe it is one you already shared but just to be clear please link to it here.) Thanks

Comment by arunkumar_s [ 04/Apr/13 ]

Sample Application:

Latest from https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Test 4 reads,process,write with chunk itemcount =3. After 3 item read and process, write method throws retryable exception. But the chunk is not rollback by start reading the chunk values again. Its just continues reading next items with itemcount=1

Sample application src code found in https://www.dropbox.com/s/b3jgecloghnofic/SimpleListeners.zip

Comment by ScottKurz [ 04/Apr/13 ]

Based on looking at your source, this would seem to be working as designed.

The way that the "cursor position" within the chunk loop is maintained is via the calls to
open(Serializable checkpoint) and checkpointInfo().

So your test Reader should look like this:

public class SimpleItemReader ...
private int index = 0;
final int MAX_VALUE=6;

public void open(Serializable checkpoint) throws Exception

{ index = (Integer)checkpoint; }

public String readItem() throws Exception

{ return index < MAX_VALUE ? Integer.toString(index++) : null; }

public Serializable checkpointInfo() throws Exception

{ return index; }

...

--------

Please reopen if you see a problem after making an adjustment like that.

Comment by arunkumar_s [ 04/Apr/13 ]

Made adjustment:
public void open(Serializable checkpoint) throws Exception
{
if(checkpoint!=null)

{index = (Integer)checkpoint;}


else

{index=0;}

// If the retryable exception happens in first chunk, then no checkpointInfo() is called, so set back the index items to zero
}
public String readItem() throws Exception

{ return index < MAX_VALUE ? Integer.toString(index++) : null; }

public Serializable checkpointInfo() throws Exception

{ return index; }

I modified the Test4 in the app such that exception occurs in ItemWriter when second chunk is getting written. First chunk successfully committed as there are no exceptions happened, but it throws new Batch Container Service exception while second chunk is being rollbacked although retryable listener is called.

[2013-04-04T22:37:51.296+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.ChunkStepControllerImpl] [tid: _ThreadID=556 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-21] [timeMillis: 1365095271296] [levelValue: 900] [[
Caught exception in chunk processing]]

[2013-04-04T22:37:51.296+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.BatchletStepControllerImpl] [tid: _ThreadID=556 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-21] [timeMillis: 1365095271296] [levelValue: 900] [[
Caught exception executing step: com.ibm.jbatch.container.exception.BatchContainerServiceException: com.ibm.jbatch.container.exception.BatchContainerServiceException: Cannot persist the checkpoint data for [step1]
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:654)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:134)

I suspect after CheckPointInfo is called in ItemWriter once, then for the next chunk rollback this issue happens
Updated sample app: https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war
Updated Sample application src code found in https://www.dropbox.com/s/b3jgecloghnofic/SimpleListeners.zip

Comment by Kaushik Mukherjee [ 04/Apr/13 ]

It looks like the Serializable checkpoint data was not being persisted correctly so the chunk loop could never complete. This will be fixed in the next RI drop.





[GLASSFISH-20246] batch related log messages when undeploying an application Created: 09/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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


 Description   

The following log messages are output when undeploying a simple web application (just an index.jsp file that does not use batch):

[#|2013-04-09T16:53:28.341-0500|INFO|glassfish 4.0||_ThreadID=102;_ThreadName=Thread-3;_TimeMillis=1365544408341;_LevelValue=800;|
  ** BatchRuntimeHelper:: App Undeployed. tagName: server-config:helloworld|#]

[#|2013-04-09T16:53:28.341-0500|INFO|glassfish 4.0||_ThreadID=102;_ThreadName=pool-20-thread-1;_TimeMillis=1365544408341;_LevelValue=800;|
  Error while purging jobs: java.lang.NullPointerException|#]


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

This is fixed.

svn commit -m "Fix for 20246. Had to handle the corner case where server is restarted and immediately app is undeployed"
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Transmitting file data .
Committed revision 61280.





[GLASSFISH-20188] ADMINGUI :Batch Process for an Instance throws NPE Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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

Win 7 IE 9


Tags: NPE, admin-gui, batch, console

 Description   

Create an instance named : Inst1
select the instance ( inst1 )
select batch tab menu.
Got an error as :
"An error has occurred
java.lang.NullPointerException"



 Comments   
Comment by Anissa Lam [ 05/Apr/13 ]

The stack trace shows the NPE is from backend, and the console screen is able to display that error properly, saying
An error has occurred
java.lang.NullPointerException

Assign to Mahesh. Here is the exception.

[#|2013-04-05T08:16:42.038-0700|SEVERE|glassfish 4.0|javax.enterprise.system.core|_ThreadID=139;_ThreadName=admin-listener(7);_TimeMillis=1365175002038;_LevelValue=1000;_MessageID=NCLS-CORE-00003;|
Exception while running a command
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:542)
at org.glassfish.batch.ListBatchJobsProxy.postInvoke(ListBatchJobsProxy.java:108)
at org.glassfish.batch.AbstractListCommandProxy.execute(AbstractListCommandProxy.java:122)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommandLegacyFormat(TemplateExecCommand.java:161)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGetLegacyFormat(TemplateCommandGetResource.java:75)
at sun.reflect.GeneratedMethodAccessor120.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

#]
Comment by Mahesh Kannan [ 09/Apr/13 ]

svn commit -m "Fix for 20190 and 20188. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobsProxy.java
Transmitting file data ......
Committed revision 61272.





[GLASSFISH-20190] BATCH CLI: asadmin list-batch-jobs --output with invalid values throws Null Pointer exception Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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


 Description   

Tested with latest nightly b83.

asadmin list-batch-jobs --output somename

Issue --> throws Null pointer exception

remote failure: java.lang.NullPointerException
IllegalArgument null
Command list-batch-jobs failed

In my opinion, a proper error message should be displayed to the users.

Same case for all the Batch CLI Commands



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

svn commit -m "Fix for 20190 and 20188. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommandProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutionsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobStepsProxy.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobsProxy.java
Transmitting file data ......
Committed revision 61272.





[GLASSFISH-20196] BATCH CLI: asadmin set-batch-runtime-configuration able to set wrong values to the lookup name Created: 05/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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

Issue Links:
Dependency
depends on GLASSFISH-20210 Unable to lookup concurrent/__default... Closed

 Description   

Tested with latest nightly

Able to set Datasource look up values to Executor lookup service and vice versa.

bin/asadmin set-batch-runtime-configuration -d concurrent/__defaultManagedExecutorService
Command set-batch-runtime-configuration executed successfully.

bin/asadmin set-batch-runtime-configuration -x jdbc/__TimerPool
Command set-batch-runtime-configuration executed successfully.

Issue --> Set batch runtime configuration should allow to set only possible values



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

This has been fixed as part of svn commit 61217. However, I am not closing this until GlassFish-20210 is fixed.

svn commit -m "Fix for 20194, and partial fix for 20196. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/SetBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Adding batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchValidationException.java
Transmitting file data ...
Committed revision 61217.

Comment by Mahesh Kannan [ 09/Apr/13 ]

Resolved. Not set-batch-runtime-configuration command does validation.
svn commit -m "Fix for 20121, 20196. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/SetBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/pom.xml
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Adding batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/ManagedServiceActivator.java
Transmitting file data ......
Committed revision 61253.





[GLASSFISH-20121] Lookup failed for JNDI name: jdbc/__TimerPool for standalone instances/cluster Created: 01/Apr/13  Updated: 09/Apr/13  Resolved: 09/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

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


 Description   

Tested with latest nightly.

1) Deploy sample batch applications in standalone instances/clusters and try to access the app.

Issue -->
[2013-04-01T19:25:52.859+0530] [glassfish 4.0] [SEVERE] [] [com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1364824552859] [levelValue: 1000] [[
Lookup failed for JNDI name: jdbc/__TimerPool. One cause of this could be that the batch runtime is incorrectly configured to EE mode when it should be in SE mode.]]



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

Changed the default to jdbc/__default. Note that you need to start derby before running batch apps. This is exactly what needs to be done to run ejb timer apps





[GLASSFISH-20201] BATCH RI: Custom Checkpoint throws javax.transaction.RollbackException Created: 05/Apr/13  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly.

1) Have custom chunk checkpoint algorithm and start the job.

Issue --> Exception thrown. Looks like persistent issue

Logs:

[2013-04-05T22:23:22.250+0530] [glassfish 4.0] [SEVERE] [poolmgr.component_register_exception] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.rm] [tid: _ThreadID=176 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-5] [timeMillis: 1365180802250] [levelValue: 1000] [[
RAR5029:Unexpected exception while registering component
javax.transaction.RollbackException
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:305)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.startJTSTx(JavaEETransactionManagerSimplified.java:439)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.enlistLAOResource(JavaEETransactionManagerJTSDelegate.java:318)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistResource(JavaEETransactionManagerSimplified.java:356)
at com.sun.enterprise.resource.rm.ResourceManagerImpl.registerResource(ResourceManagerImpl.java:152)
at com.sun.enterprise.resource.rm.ResourceManagerImpl.enlistResource(ResourceManagerImpl.java:112)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:211)
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:354)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:307)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:196)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:171)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:166)
at com.sun.gjc.spi.base.AbstractDataSource.getConnection(AbstractDataSource.java:114)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnection(JDBCPersistenceManagerImpl.java:310)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.queryCheckpointData(JDBCPersistenceManagerImpl.java:408)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.updateCheckpointData(JDBCPersistenceManagerImpl.java:289)
at com.ibm.jbatch.container.persistence.CheckpointManager.checkpoint(CheckpointManager.java:132)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeChunk(ChunkStepControllerImpl.java:596)
at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:652)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:134)
at com.ibm.jbatch.container.impl.JobControllerImpl.doExecutionLoop(JobControllerImpl.java:332)
at com.ibm.jbatch.container.impl.JobControllerImpl.executeJob(JobControllerImpl.java:122)
at com.ibm.jbatch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:79)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:722)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:246)
]]

[2013-04-05T22:23:22.265+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.BatchletStepControllerImpl] [tid: _ThreadID=176 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-5] [timeMillis: 1365180802265] [levelValue: 900] [[
Caught exception executing step: com.ibm.jbatch.container.exception.BatchContainerServiceException: com.ibm.jbatch.container.exception.BatchContainerServiceException: Cannot persist the checkpoint data for [prepare]



 Comments   
Comment by ScottKurz [ 05/Apr/13 ]

Do we have any indication from any of the transation, connection management, or JDBC driver layers on why the RollbackException was thrown?

Could the issue be that the timeout controlled by the custom checkpoint algorithm has already hit?

Purely from the jbatch perspective, it might help to log an info message that says when the timeout was hit, even though we are not in direct control of the rollback (or not). We can look into that but that would be just a diagnostic aid in general and wouldn't necessarily debug this particular incident.

The timeout of '0' returned by AbstractCheckpointAlgorithm means don't timeout (i.e indefinite), by the way.

Comment by arunkumar_s [ 06/Apr/13 ]

Sample checkpoint war - https://www.dropbox.com/s/pejo5tewt3l1wm2/SimpleCheckPoint.war

http://<server>:<port>/simplecheckpoint/JobSubmitterServlet

Sample checkpoint app src code - https://www.dropbox.com/s/takw0o0ihus8vl1/SimpleCheckPoint.zip

Not sure why JDBC connection pool is failed, but without checkpoint algo, the job runs fine and listing batch jobs lists the job executed.

Comment by ScottKurz [ 08/Apr/13 ]

Took a look at the source... not sure what you aiming for in this test.

The processor has a 2 second sleep, but your checkpoint timeout is 2.

@Override
public int checkpointTimeout() throws Exception {
System.out.println("Checkpoint Timeout");
return 2;

So this would seem to be set up to always timeout.. producing a failure probably like the one you're seeing.

Note this isn't a "timeout" that says "take a checkpoint after this time". It says instead, "if you haven't reached the checkpoint, then fail the tran".

I.e. looks like working as designed.

Comment by arunkumar_s [ 08/Apr/13 ]

Scott,

Thanks. I have couple of questions.

1) SPEC says "The isReadyToCheckpoint method is invoked by the batch runtime after each item read" but actually it is called after each item is processed. Do you think spec statement is wrong or otherwise?
2) reason for isReadyToCheckpoint() is abstract in AbstractCheckpointAlgorithm? Just if i want to use only checkpointtimeout() as timeout for committing transactions, how it will be possible?

Comment by ScottKurz [ 08/Apr/13 ]

Hi,

1) I just asked Chris to change the Javadoc to "after each item read and processed"

2) checkpointTimeout() is not a timeout for committing trans, but for timing them out (i.e. rolling them back if the tran has not been committed in that time period). It maps to UserTransaction.setTransactionTimeout(int).

In batch you can configure the chunk to "take a checkpoint every 2 seconds" simply by:

<chunk checkpoint-policy="item" time-limit="2"...> OR

<chunk time-limit="2"...> (since "item" is the default)

So you don't even need a custom algorithm for this, but if you wanted one to checkpoint if time-limit > xxx AND some_other_condition then you'd have to code that yourself.





[GLASSFISH-20189] BATCH CLI: asadmin list-batch-jobs --long not listing Instance Count values Created: 05/Apr/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b84_RC1

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


 Description   

Tested with latest nightly b83.

Issue -> Not shows Instance Count values for jobs when running asadmin list-batch-jobs -l



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

This has been fixed on Friday's build itself.





[GLASSFISH-20194] BATCH CLI: asadmin set-batch-runtime-configuration without options doesn't seems valid Created: 05/Apr/13  Updated: 07/Apr/13  Resolved: 07/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b85

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly.

asadmin set-batch-runtime-configuration
Command set-batch-runtime-configuration executed successfully.

The above command doesn't make any sense. The command must have operand -x or(and) -d



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

Fixed.

svn commit -m "Fix for 20194, and partial fix for 20196. QL Passed"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/SetBatchRuntimeConfiguration.java
Sending batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Adding batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchValidationException.java
Transmitting file data ...
Committed revision 61217.





[GLASSFISH-20193] BATCH CLI: asadmin list-batch-runtime-configuration --help has some invalid texts Created: 05/Apr/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

Status: Closed
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b83
Fix Version/s: 4.0

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


 Description   

Tested with latest nightly.

bin/asadmin list-batch-runtime-configuration -? or --help
set-batch-runtime-configurasadmin)Utility Suset-batch-runtime-configuration(1) --> 1 st line some wrong text
....
....
Java EE 7 13 Feb 20list-batch-runtime-configuration(1) --> last line text issue

Same case for set-batch-runtime-configuration -? or --help

Same case for list-batch-job-executions -? (only for 1st line)



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

Assigning to Gail

Comment by Gail Risdal [ 05/Apr/13 ]

This is caused by long subcommands and the fact that we only have an 80 column display. The text in headers and footers for long subcommands will overlay; this is nothing we can fix.





[GLASSFISH-20093] [Batch RI] Halfway Terminated Job Executions Created: 28/Mar/13  Updated: 05/Apr/13  Resolved: 05/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly b82.

Steps:

1) Started a long running Job.
2) Killed the Job Process(here i killed Glassfish Process). Now the Job Execution killed/terminated halfway with status (STARTED)

Is getRunningExecutions() always returns the Job executions with state STARTED or really returns the actual running jobs?

If i try to abandon the halfway terminated job it says javax.batch.operations.JobExecutionIsRunningException

If i try to stop using joboperator.stop() the halfway terminated job then it says javax.batch.operations.JobExecutionNotRunningException

The user might actually get confused because of contradictory exceptions in this exceptional case



 Comments   
Comment by ScottKurz [ 02/Apr/13 ]

I made a fix which I believe will address this but I'll let you verify. We are delivering now in jbatch 1.0-b23, so I think that should make it into the b83.





[GLASSFISH-19870] Batch RI : Batch Exceptions : Restarting a running job execution starts a new job execution Created: 14/Mar/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-20119 BATCH RI: IllegalStateException when ... Resolved

 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Restart a job execution which is currently running

Issue --> Creates a new Job execution with FAILED status

Not sure this is a bug or request as JobOperator.restart(executionid) doesn't have JobExecutionIsRunningException defined in RI ,but it should throw JobExecutionIsRunningException



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

There are a couple aspects to this one.

First, it's not clear whether you're saying that you're doing:

// Restart, then do restart with the execution ID from the new restart, while first restart is still running

long exec1Id = jo.start(...)
long exec2Id = jo.restart(exec1Id, null);
long exec3Id = jo.restart(exec2Id, null);

OR:

// Restart, then do restart with the execution ID from the new restart

long exec1Id = jo.start(...)
long exec2Id = jo.restart(exec1Id, null);
long exec3Id = jo.restart(exec1Id, null);

----------

The second case we've addressed in 1.0-b21. It will actually be treated via JobExecutionNotMostRecentException, since
the 2nd time 'exec1Id' is passed, it is no longer the most recent.

The first is not fixed and I don't want to promise yet it will be in b22.

I agree JobExecutionIsRunningException would be a natural candidate ... but given that we hope to have frozen the API at this point, I'd suggest we can deal with this via JobRestartException.

Comment by arunkumar_s [ 27/Mar/13 ]

Job execution has to be in a State(Failed/Stopped) to restart the execution. If a Job is in Started State, and trying to restart the same job execution then the user should get JobExecutionIsRunningException or JobRestartException

Comment by ScottKurz [ 03/Apr/13 ]

Just doing another pass here. This is still a problem even in the latest code.

Comment by ScottKurz [ 04/Apr/13 ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20119] BATCH RI: IllegalStateException when restarting a running JOB Created: 01/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19870 Batch RI : Batch Exceptions : Restart... Resolved

 Description   

Tested with latest integrated b22 with latest glassfish nightly.

On top of bug http://java.net/jira/browse/GLASSFISH-19870, try to restart a already running job throws Illegal State Exception

java.lang.IllegalStateException: On restart, we didn't find an earlier batch status.
at com.ibm.jbatch.container.jobinstance.JobExecutionHelper.validateJobInstanceNotCompleteOrAbandonded(JobExecutionHelper.java:165)



 Comments   
Comment by ScottKurz [ 02/Apr/13 ]

OK.. I think the point you are making here is that we could use something like JobRestartException as a blanket unchecked exception rather than IllegalStateException.

That sounds better. Didn't make b23 but will do for the next drop.

Comment by ScottKurz [ 04/Apr/13 ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20144] BATCH RI: getEndTime() from Step Executions throws Null Pointer Exception Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly.

1) Start a long running Job.

StepExecution.getEndTime() of the currently running execution throws Null Pointer Exception

[2013-04-03T15:32:48.687+0530] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1364983368687] [levelValue: 900] [[
StandardWrapperValve[JobSubmitterServlet]: Servlet.service() for servlet JobSubmitterServlet threw exception
java.lang.NullPointerException
at com.ibm.jbatch.container.jobinstance.StepExecutionImpl.getEndTime(StepExecutionImpl.java:80)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.listJobExecutionDetails(JobSubmitterServlet.java:312)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.processRequest(JobSubmitterServlet.java:157)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.doPost(JobSubmitterServlet.java:471)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by ScottKurz [ 03/Apr/13 ]

Got it.. will fix in next drop.

Comment by ScottKurz [ 04/Apr/13 ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20149] BATCH RI: Skippable include class exceptions not caught with default skip-limit values Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest build b22

Have a chunk job with skippable exception include classes

Sample chunk element:

<chunk item-count="2">
...
</chunk>

skip-limit by PFD "The default is no limit.". Does it mean infinite maximum value or zero by default?

If the value is infinite value, then this bug is valid

The specified skippable exception include classes exception thrown inside chunk job, skippable listeners don't catch the exception and Job Failed with FAILED status.

Issue -> If skippable exception include classes is thrown in job processing, then it should skip the exceptions and continue the job processing

Attached sample application : https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Deploy the app and click StartJob1 from the servlet http://<server>:<port>/SimpleListeners/JobSubmitterServlet

Job1 has Arithmetic exception thrown in Item Processor which is not caught by skippable exception include class and the Job fails with FAILED Status

Job XML Chunk:

<chunk item-count="3">
<reader ref="SimpleItemReader"></reader>
<processor ref="SimpleItemProcessor"></processor>
<writer ref="SimpleItemWriter"></writer>
<skippable-exception-classes>
<include class="java.lang.ArithmeticException"/>
</skippable-exception-classes>
</chunk>



 Comments   
Comment by Kaushik Mukherjee [ 03/Apr/13 ]

We'll have a fix for this in the next RI drop.

Comment by ScottKurz [ 04/Apr/13 ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20150] BATCH RI: SkipWriteListener is called no of items processed rather than no of times exception thrown Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b84_RC1

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: ScottKurz
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest glassfish nightly + b22

My sample Job XML

<?xml version="1.0" encoding="UTF-8"?>
<job id="PayRollJobListeners" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="TESTNO" value="#

{jobParameters['TESTNO']}

"/>
</properties>
<step id="step1">
<listeners>
<listener ref="SampleSkipReadListener"></listener>
<listener ref="SampleSkipWriteListener"></listener>
<listener ref="SampleSkipProcessListener"></listener>
<listener ref="SampleRetryReadListener"></listener>
<listener ref="SampleRetryWriteListener"></listener>
<listener ref="SampleRetryProcessListener"></listener>
</listeners>
<chunk item-count="3" skip-limit="3">
<reader ref="SimpleItemReader"></reader>
<processor ref="SimpleItemProcessor"></processor>
<writer ref="SimpleItemWriter"></writer>
<skippable-exception-classes>
<include class="java.lang.ArithmeticException"/>
</skippable-exception-classes>
</chunk>
</step>
</job>

SimpleItemReader will read 6 items one by one.
I have introduced ArithmeticException in SimpleItemWriter writeItems method. As per chunk item-count my SimpleItemWriter writeItems called only twice as there are only 6 items from the reader. So skip-limit value set to 3 should complete the JOB successfully

Issue --> After writeItems Arithmetic Exception thrown, SkipWriterListener is called 3 times(chunk count) and job process next chunk it makes the JOB to FAILED bcoz of Arithmetic Exception

Attached Sample App: https://www.dropbox.com/s/eu78eidm31mveid/SimpleListeners.war

Deploy the app and start Job2 from http://<server>:<port>/SimpleListeners/JobSubmitterServlet



 Comments   
Comment by ScottKurz [ 03/Apr/13 ]

I thought this had come up on the spec ML and we'd decided on # of items. Looking back at the spec now I only see, clearly, that it's saying # of exceptions.

Thanks for catching that. Let me look into this...

Comment by Kaushik Mukherjee [ 03/Apr/13 ]

Looks like the RI was counting the exceptions against each item in the write chunk. This is fixed for the next drop.

Comment by ScottKurz [ 04/Apr/13 ]

Fixed in jbatch 1.0-b24





[GLASSFISH-20140] BATCH CLI: asadmin list-batch-job-executions <instanceid> with a running job instance id not shows the job execution details Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

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


 Description   

Tested with latest nightly b83.

1) Start any job
2) Get the instance id of the currently running job(instanceid)
3) In CLI asadmin list-batch-job-executions -l <instanceid>

Issue: Command executed successfully, but no job executions displayed. May be if not possible to display running job execution details, user should get some error message.

Same case for asadmin list-batch-job-steps -l <executionid>(of a running Job)



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

Nice catch! For running jobs, jobExecution.getEndTime() returns null causing an NPE in CLI.
Will fix it tomorrow.

Comment by Mahesh Kannan [ 04/Apr/13 ]

This is resovled. Basically, for a running job, the end time returns null and hence the NPE.

svn commit -m "Integrate b23 jars for Batch. Also fix GlassFish-20139 and GlassFish-20140. QL Passed"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchSecurityHelper.java
Sending appserver/pom.xml
Transmitting file data ......
Committed revision 61166.





[GLASSFISH-20139] BATCH CLI: asadmin list-batch-jobs not listing batch jobs when any job is running Created: 03/Apr/13  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

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


 Description   

Tested with latest nightly b83

1) Start any batch job
2) In CLI run asadmin list-batch-jobs -l

Issue --> Command executed successfully, but no jobs displayed.



 Comments   
Comment by arunkumar_s [ 03/Apr/13 ]

same case for list-batch-job-executions -l when any job process running.

Comment by Mahesh Kannan [ 03/Apr/13 ]

Same root cause as 20140

Comment by Mahesh Kannan [ 04/Apr/13 ]

This is resovled. Basically, for a running job, the end time returns null and hence the NPE.

svn commit -m "Integrate b23 jars for Batch. Also fix GlassFish-20139 and GlassFish-20140. QL Passed"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchSecurityHelper.java
Sending appserver/pom.xml
Transmitting file data ......
Committed revision 61166.





[GLASSFISH-19756] [Batch RI] Job details are still persisted in JobRepository even after the application that submitted it was undeployed Created: 28/Feb/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b83

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


 Description   

This is both RI bug and GF SPI impl bug. I am marking it against RI since we already have other tasks filed against SPI implementation.

Job details are still persisted in JobRepository even after the application that submitted it was undeployed



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

This is no longer RI bug since there is an SPI method to cleanup jobs upon undeployment

Comment by Mahesh Kannan [ 02/Apr/13 ]

BatchRuntimeHelper calls
batchSPIManager.getBatchJobUtil().purgeOwnedRepositoryData(tagName);

upon app undeployment, yet the data is not cleared from the JobReposiory

Comment by ScottKurz [ 02/Apr/13 ]

This should be fixed in today's drop of jbatch 1.0-b23





[GLASSFISH-20120] BATCH RI: Partition Plan throws BatchContainerRuntimeException Created: 01/Apr/13  Updated: 03/Apr/13  Resolved: 03/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b83

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


 Description   

Tested with latest nightly.

My Sample Job XML partition

<partition>
<plan partitions="2" threads="2">
<properties partition="0">
<property name="fileinput" value="SampleInput1.txt"/>
</properties>
<properties partition="1">
<property name="fileinput" value="SampleInput2.txt"/>
</properties>
</plan>
<collector ref="SamplePartitionCollector"/>
<analyzer ref="SamplePartitionAnalyzer"/>
</partition>

Starting a partitioned JOB with above partitioned config throws

[2013-04-01T17:21:27.031+0530] [glassfish 4.0] [WARNING] [] [com.ibm.jbatch.container.impl.BatchletStepControllerImpl] [tid: _ThreadID=637 _ThreadName=concurrent/__defaultManagedExecutorService-managedThreadFactory-Thread-9] [timeMillis: 1364817087031] [levelValue: 900] [[
Caught exception executing step: com.ibm.jbatch.container.exception.BatchContainerRuntimeException: There are only 2 partition instances, but there are 2 partition properties lists defined.
at com.ibm.jbatch.container.impl.PartitionedStepControllerImpl.generatePartitionPlan(PartitionedStepControllerImpl.java:237)
at com.ibm.jbatch.container.impl.PartitionedStepControllerImpl.invokeCoreStep(PartitionedStepControllerImpl.java:262)
at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:134)
at com.ibm.jbatch.container.impl.JobControllerImpl.doExecutionLoop(JobControllerImpl.java:332)
at com.ibm.jbatch.container.impl.JobControllerImpl.executeJob(JobControllerImpl.java:122)
at com.ibm.jbatch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:79)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:722)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:246)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at com.ibm.jbatch.container.impl.PartitionedStepControllerImpl.generatePartitionPlan(PartitionedStepControllerImpl.java:235)
... 13 more
]]



 Comments   
Comment by ScottKurz [ 01/Apr/13 ]

Looks like we're still using 1-based partitions based on 0-based and all our tests are 1-based as well (since this was a change later in the JSR spec).

Thanks for catching this..we'll update for next drop.

Comment by ScottKurz [ 02/Apr/13 ]

Should be fixed in today's drop of jbatch 1.0-b23





[GLASSFISH-19868] Batch RI : Batch Exceptions : JobExecutionAlreadyCompleteException not thrown when restarting a completed Job Created: 14/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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


 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Restart a job execution which is already completed.

Issue--> JobExecutionAlreadyCompleteException not thrown. Creates a new Job execution with the server logs. But actually the job not started.

Expected: JobExecutionAlreadyCompleteException should be thrown, and Job Operator should create a new execution.

[2013-03-14T18:18:15.890+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=29 _ThreadName=Thread-3] [timeMillis: 1363265295890] [levelValue: 800] [[

    • GlassFishBatchExecutorServiceProvider.getExecutorService() called]]

[2013-03-14T18:18:15.890+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=29 _ThreadName=Thread-3] [timeMillis: 1363265295890] [levelValue: 800] [[
Job with Execution id:287 restarted]]



 Comments   
Comment by ScottKurz [ 15/Mar/13 ]

OK.. I see we hadn't implemented this and have done so internally. Available next respin.

Comment by ScottKurz [ 27/Mar/13 ]

This should have been in for awhile now.. in 1.0-b19, I believe.





[GLASSFISH-19908] BATCH RI: JobRestartException not thrown when restarting a Abandon Job Created: 17/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

Tested with latest promoted build : glassfish-4.0-b80

Steps:
1) Abandon a failed/completed Job.
2) Restart a Abandoned Job

Issue --> Creates a new JOB although job not started in background, but JOB status shows completed. As per Spec Abandoned JOB cannot be restarted. So expecting JobRestartException thrown if try to starting a abandoned job.



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Fixed in 1.0-b21.





[GLASSFISH-20055] [Batch RI] Batch Job servlets/ejb applications able to stop/restart/abandon other batch job executions Created: 26/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b82_EE7MS7

Type: Bug Priority: Major
Reporter: arunkumar_s Assignee: arunkumar_s
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with latest nightly build 82

asadmin list-batch-jobs -l list all the batch jobs available

Try to stop/restart/abandon a batch execution by providing execution id from other servlet/ejb apps

Issue --> list batch jobs from an servlet/ejb displays only the current application batch jobs, the same thing should be applied to stop/restart/abandon batch jobs



 Comments   
Comment by Mahesh Kannan [ 27/Mar/13 ]

The jobOperator.getJobNames() uses BatchSecurityHelper to find out if the caller is an Admin. If not it calls BatchSecurityHelper.getCurrentTag() to determine the current app.

I guess these other APIs in JobOperator (stop/restart/abandon) must also make use of BatchSecurityHelper to prevent this use case.

Comment by ScottKurz [ 27/Mar/13 ]

Yes, it looks like we have some gaps here. Not sure if we'll fix tomorrow, but by end of week.

Comment by ScottKurz [ 29/Mar/13 ]

This should be fixed in the 1.0-b22 drop.





[GLASSFISH-19871] Batch RI : Batch Exceptions : JobExecutionIsRunningException not thrown when abandon a running job Created: 14/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Abandon a running Job

Issue--> No exception(JobExecutionIsRunningException) thrown and Job Operator Sets the status as ABANDONED, although job is still running



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Fixed in 1.0-b21.





[GLASSFISH-19869] Batch RI : Batch Exceptions : NoSuchJobExecutionException not thrown when restarting a job with non-existing executionId Created: 14/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

Tested with latest nightly : glassfish-4.0-b80-03_13_2013

Steps:

1) Run jo.restart(executionId) with a non existing execution Id

Issue --> Throws null pointer exception with the following server logs

[2013-03-14T18:26:07.015+0530] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=28 _ThreadName=http-listener-1(1)] [timeMillis: 1363265767015] [levelValue: 900] [[
StandardWrapperValve[JobSubmitterServlet]: Servlet.service() for servlet JobSubmitterServlet threw exception
java.lang.NullPointerException
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.restart(JobOperatorImpl.java:323)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.restartBatchJobExecution(JobSubmitterServlet.java:300)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.processRequest(JobSubmitterServlet.java:118)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.doPost(JobSubmitterServlet.java:368)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:176)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Fixed in 1.0-b21

Comment by Mahesh Kannan [ 27/Mar/13 ]

Arun, I have integrated b21 into GF

Could you verify and close this issue?

Comment by arunkumar_s [ 27/Mar/13 ]

Mahesh,

Now its throwing javax.batch.operations.JobExecutionNotMostRecentException instead of NoSuchJobExecutionException

Comment by ScottKurz [ 29/Mar/13 ]

Can you please try again with b22 integrated? I thought this as in b21 but maybe not...just ran my own on b22 level and caught NoSuchJobExecutionException.

Comment by Mahesh Kannan [ 02/Apr/13 ]

Should have been fixed in b22





[GLASSFISH-19914] BATCH RI: Abandoning a Job sets the StartTime of the Job execution to Current Time Created: 18/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

Tested with Glassfish 4.0 Build 80

Steps:

1) Abandon a Failed/Completed Job.

Issue --> Abandon a Job sets the Start time of the Job to the current time(). Not sure this is expected. As a result of this StartTime of a Job is greater than End time(sample output of list-batch-job-executions shown below)

$ bin/asadmin list-batch-job-executions -x 357
JOBNAME EXECUTIONID STARTTIME ENDTIME BATCHSTATUS EXITSTATUS
simple-batchlet-job 357 Mon Mar 18 18:41:54 IST 2013 Mon Mar 18 17:42:30 IST 2013 ABANDONED FAILED
Command list-batch-job-executions executed successfully.



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

In looking at the code, it seems we are updating the start time in a couple of places where we shouldn't, including this case.

Let me try to see if there was a reason behind this before jumping to make the change..

Comment by ScottKurz [ 29/Mar/13 ]

I think this is fixed in 1.0-b22. I came at it from a different angle so didn't run this exact test.... will look for confirmation.

Comment by Mahesh Kannan [ 02/Apr/13 ]

According to Scott, this should have been fixed in b22





[GLASSFISH-19856] [Batch RI] getEndTime() of a Job which is running throws Null Pointer Exception Created: 13/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

GF Nightly version: glassfish-4.0-b80-03_12_2013

Steps:

1) Start a job and use getEndTime() to get the EndTime of the running JOB
(Same scenario can be achieved by Start a Job and execute "list-batch-jobs -l" in command line)

list-batch-jobs -l command failed with Null Pointer Exception

Exception during command
java.lang.NullPointerException
at com.ibm.jbatch.container.jobinstance.JobOperatorJobExecutionImpl.getEndTime(JobOperatorJobExecutionImpl.java:112)



 Comments   
Comment by ScottKurz [ 21/Mar/13 ]

Should be fixed in jbatch 1.0-b20

Comment by Mahesh Kannan [ 02/Apr/13 ]

Yes. I see this is fixed in b22





[GLASSFISH-20053] Batch RI: JobExecutionNotRunningException shows job instance id as execution id Created: 26/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b83

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with Latest nightly build 82

1) Start and Stop a Job
2) Restart the Stopped Job and allow it to complete. (Now we will have same job instances with different execution id)

3) Now Stop the Completed Job

Issue --> JobExecutionNotRunningException is thrown as expected, but the execution id displayed in the exception is actually its job instance id



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Good catch... easy fix, so it will be in our next spin (1.0-b22).

Comment by Mahesh Kannan [ 27/Mar/13 ]

Gail I am assigning this to you as it seems related to man pages and docs

Comment by Gail Risdal [ 27/Mar/13 ]

Mahesh - assigning this back to you. This is not a docs issue. Error messages are not part of the man pages or docs.

Comment by Mahesh Kannan [ 02/Apr/13 ]

According to Scott, this should have been fixed in b22





[GLASSFISH-19855] [Batch RI] Start Time and End Time shows the same values for all Batch Jobs Created: 13/Mar/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

GF version: glassfish-4.0-b80-03_12_2013

Steps:

1) Start any batch job.
2) list-batch-jobs -l shows same values for both StartTime and EndTime.



 Comments   
Comment by Mahesh Kannan [ 15/Mar/13 ]

Actually if you do getEndtime().getTime() you will that the start and end times differ by a few hundred millis

Comment by arunkumar_s [ 26/Mar/13 ]

The issue still exists with the latest nightly build.

List batch jobs shows

JOBNAME APPNAME INSTANCEID EXECUTIONID BATCHSTATUS STARTTIME ENDTIME
null SimpleBatchJob1 3 3 COMPLETED Tue Mar 26 14:36:18 IST 2013 Tue Mar 26 14:36:18 IST 2013

List Batch Job steps for the same Job

$ bin/asadmin list-batch-job-steps 3

STEPNAME STEPID STARTTIME ENDTIME BATCHSTATUS EXITSTATUS
prepare 3 Tue Mar 26 14:33:37 IST 2013 Tue Mar 26 14:34:58 IST 2013 COMPLETED COMPLETED
process 4 Tue Mar 26 14:34:58 IST 2013 Tue Mar 26 14:36:18 IST 2013 COMPLETED COMPLETED
Command list-batch-job-steps executed successfully.

Comment by Mahesh Kannan [ 27/Mar/13 ]

This is what the command is using internally (where je is JobExecution) :

case START_TIME:
cfData[index] = je.getStartTime().toString();
break;
case END_TIME:
cfData[index] = je.getEndTime().toString();
break;

So, clearly, jobExecution.getStartTime and jobExecution.getEndTime() are returning the same values

Comment by Mahesh Kannan [ 27/Mar/13 ]

Based on my previous comments, I am marking this as RI bug

Comment by ScottKurz [ 29/Mar/13 ]

I think this is the same issue as GLASSFISH-19914, and therefore fixed in 1.0-b22.

Comment by Mahesh Kannan [ 02/Apr/13 ]

As per Scott's comment, I am marking this as resolved.





[GLASSFISH-19958] BATCH CLI: asadmin batch command help docs should be synonymous with other commands help docs Created: 20/Mar/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

Tested with Glassfish 4.0 Build 80

asadmin <available-batch-commands> --help or -?

All batch commands help docs should contain NAME,SYNOPSIS,DESCRIPTION,OPTIONS,OPERANDS, EXAMPLES, EXIT STATUS, SEE ALSO



 Comments   
Comment by ScottKurz [ 21/Mar/13 ]

I assume this isn't the responsibility of the jbatch code, but of the batch admin layer?

Comment by arunkumar_s [ 22/Mar/13 ]

This should be of Glassfish CLI admin commands

Comment by Mahesh Kannan [ 01/Apr/13 ]

This has been fixed.
For example, asadmin help list-bath-jobs gives:

asadmin help list-batch-jobs
list-batch-jobs(1) asadmin Utility Subcommands list-batch-jobs(1)

NAME
list-batch-jobs - lists batch jobs

SYNOPSIS
list-batch-jobs [--help]
[--target target]
[--long=

{false|true}]
[--output output]
[--header={false|true}

]
[job_name]

DESCRIPTION
The list-batch-jobs subcommand lists batch jobs and job details.

OPTIONS
--help, -?
Displays the help text for the subcommand.

--target
Specifies the target for which to list batch jobs and job details.
Valid values are as follows:

server
Lists batch jobs for the default server instance server and is
the default value.

cluster-name
Lists batch jobs for every server instance in the cluster.

instance-name
Lists batch jobs for a particular server instance.

--long, -l
Displays all details. The default value is false.

--output, -o
Displays specific details. Use a comma-separated list to specify
the details to display and their order. The values are
case-insensitive. The jobname and instancecount column headings are
displayed by default.

Possible values are as follows:

jobname
Displays the name of the job.

appname
Displays the name of the application.





[GLASSFISH-19957] asadmin list-batch-job-executions with a wrong instance id throws null pointer exceptions Created: 20/Mar/13  Updated: 29/Mar/13  Resolved: 29/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b83

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


 Description   

Tested with Glassfish4.0 build 80

1) Run asadmin list-batch-job-executions -i <SOME_ID>

SOME_ID is a non-existing instance id.

Issue--> Throws Null pointer exceptions in the logs.

[2013-03-20T15:07:33.578+0530] [glassfish 4.0] [WARNING] [] [] [tid: _ThreadID=43 _ThreadName=admin-listener(5)] [timeMillis: 1363772253578] [levelValue: 900] [[
Exception during command
java.lang.NullPointerException
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.getJobExecutions(JobOperatorImpl.java:174)
at org.glassfish.batch.ListBatchJobExecutions.getJobExecutionForInstance(ListBatchJobExecutions.java:182)
at org.glassfish.batch.ListBatchJobExecutions.executeCommand(ListBatchJobExecutions.java:120)
at org.glassfish.batch.AbstractListCommand.execute(AbstractListCommand.java:99)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by Mahesh Kannan [ 23/Mar/13 ]

This is really a RI bug as can be seen below:

java.lang.NullPointerException
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.getJobExecutions(JobOperatorImpl.java:167)
at org.glassfish.batch.ListBatchJobExecutions.getJobExecutionForInstance(ListBatchJobExecutions.java:183)

Comment by ScottKurz [ 27/Mar/13 ]

I'm wondering if this is a valid testcase.

The API doesn't give you a way to new up a JobInstance... you have to get one from another JobOperator method.

So how did you go about passing a JobInstance with "non-existing instance id" to
getJobExecutions() ?

Comment by Mahesh Kannan [ 27/Mar/13 ]

Scott,
I think the submitter is expecting (at the minimum a) NoSuchJobInstanceException from getJobExecutions(instanceId).
Is it possible for

com.ibm.jbatch.container.api.impl.JobOperatorImpl.getJobExecutions(JobOperatorImpl.java:174)

to throw NoSuchJobInstanceException?

Comment by ScottKurz [ 27/Mar/13 ]

Mahesh,

I'm not saying we've proven it's OK to throw an NPE... but I'd like to ask for more details on the test.

The spec API provides methods:
public List<JobExecution> getJobExecutions(JobInstance instance)
public JobExecution getJobExecution(long executionId)

but there is no:
List<JobExecution> getJobExecutions(long instanceId)

Did you just new up a JobInstance with an invalid instanceId?

Comment by Mahesh Kannan [ 27/Mar/13 ]

OK, this is not an RI bug but actually a bug in ListBatchJobExecutions command.

It is actually passing a null jobInstance to BatchRuntime.getJobOperator().getJobExecutions(jobInstance) when an invalid instanceId is passed.

Removing the 'Batch RI' prefix

Comment by Mahesh Kannan [ 29/Mar/13 ]

svn commit -m "Integrate b22 jars. Also Fix for 19957. QL Passed"
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/pom.xml
Transmitting file data ...
Committed revision 61030.





[GLASSFISH-20086] Batch Job Listing show error: "an error has ocurred" Created: 28/Mar/13  Updated: 28/Mar/13  Resolved: 28/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin_gui, batch
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b82_EE7MS7

Type: Bug Priority: Major
Reporter: jamdiazdiaz Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7
glassfish 4 b81
Admin console


Tags: fishcat

 Description   

The option Batch Jobs show a error message: "an error has ocurred"

If you enter to configuration get it error:

HTTP Status 500 - Internal Server Error

--------------------------------------------------------------------------------

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request.

exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response

note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.0 logs.



 Comments   
Comment by Anissa Lam [ 28/Mar/13 ]

This should be fixed in b82 or by using nightly build after 3/27.





[GLASSFISH-19752] [Batch RI] Cannot inject CDI beans into Item{Reader, Writer, Processor} Created: 28/Feb/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

This is a RI bug. This might have been fixed with the latest Weld integration. Will close this once I verify that "drop 3" of RI works properly.



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

This is still open.
Looks like https://issues.jboss.org/browse/WELD-1332 needs to be fixed for this

Comment by arungupta [ 13/Mar/13 ]

This is also causing injection of other artifacts like:

@PersistenceContext
EntityManager em;

failing as well.

Comment by ScottKurz [ 27/Mar/13 ]

I would hope this would be fixed with 1.0-b19 and later drops of jbatch. We removed the generic from the JobContext, StepContext interfaces, after which we expect the problem to go away.

Comment by Mahesh Kannan [ 27/Mar/13 ]

This seems to be resolved with b21.

I am able to inject JobContext, StepContext and an EJB into an ItemProcessor





[GLASSFISH-20054] Batch RI: Batchlet Exit status is not set as return value of Batchlet.process() Created: 26/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

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

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


 Description   

Tested with latest Nightly Build 82

Batchlet.process() return value is not set as batchlet exit status



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Without any other detail, I'm wondering: are you sure the test is not confusing the job-level exit status and the step-level exit status? The process() return value is not what you would see from JobExecution.getExitStatus()... but only from the corresponding StepExecution.

Comment by arunkumar_s [ 27/Mar/13 ]

I wrongly tested and expected batch job status as return value of Batchlet.Process()





[GLASSFISH-19928] [Batch RI] JobExecution returned by jobOperator.getJobExecutions(jobInstance) return null jobName Created: 19/Mar/13  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

for (String jn : jobOperator.getJobNames()) {
List<JobInstance> exe = jobOperator.getJobInstances(jn, 0, Integer.MAX_VALUE - 1);
if (exe != null) {
for (JobInstance ji : exe) {
for (JobExecution je : jobOperator.getJobExecutions(ji))

{ je.getJobName() ===> returns null }

}
}
}

However, jobOperator.getJobExecution(executionId).getJobName() is not null



 Comments   
Comment by ScottKurz [ 27/Mar/13 ]

Fixed in 1.0-b21.

Comment by Mahesh Kannan [ 27/Mar/13 ]

Yes. This has been fixed in b21





[GLASSFISH-19960] BATCH CLI: asadmin list-batch-runtime-configuration with --long or -l doesn't make sense Created: 20/Mar/13  Updated: 23/Mar/13  Resolved: 23/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

Type: Bug Priority: Minor
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Output of asadmin list-batch-runtime-configuration --long or -l is as same as without long option

Is list-batch-runtime-configuration should have --long option?



 Comments   
Comment by Mahesh Kannan [ 23/Mar/13 ]

With b19 integration this is fixed.

svn commit -m "Integrate version b19 of batch jars. QL Passed"
Sending appserver/batch/glassfish-batch-commands/pom.xml
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Adding appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractLongListCommand.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/javaee-api/javax.javaee-api/pom.xml
Sending appserver/packager/glassfish-common-full/pom.xml
Sending appserver/pom.xml
Transmitting file data ............
Committed revision 60736.





[GLASSFISH-19959] BATCH CLI: asadmin list-batch-job-steps with wrong exeecution id throws Null Pointer Exception Created: 20/Mar/13  Updated: 23/Mar/13  Resolved: 23/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

Tested with Glassfish Build 80

asadmin list-batch-job-steps <SOME_ID>

<SOME_ID> is non-existing execution Id.

[2013-03-20T15:41:28.625+0530] [glassfish 4.0] [WARNING] [] [] [tid: _ThreadID=43 _ThreadName=admin-listener(5)] [timeMillis: 1363774288625] [levelValue: 900] [[
Exception during command
java.lang.NullPointerException
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.getStepExecutions(JobOperatorImpl.java:300)
at org.glassfish.batch.ListBatchJobSteps.findStepExecutions(ListBatchJobSteps.java:133)
at org.glassfish.batch.ListBatchJobSteps.executeCommand(ListBatchJobSteps.java:106)
at org.glassfish.batch.AbstractListCommand.execute(AbstractListCommand.java:99)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by ScottKurz [ 21/Mar/13 ]

Just recreated this even on b20. Fix will be in b21, tomorrow.

Comment by Mahesh Kannan [ 23/Mar/13 ]

Fixed by b19 and svn r:60739

svn commit -m "Fix for GLASSFISH-19959"
Sending batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Transmitting file data .
Committed revision 60739.





[GLASSFISH-19917] [Batch RI] SQL Exception seen when calling TaggedJobExecution.getTgName() Created: 18/Mar/13  Updated: 23/Mar/13  Resolved: 23/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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

Issue Links:
Dependency
blocks GLASSFISH-19750 list-batch-jobs command must display ... Resolved

 Description   

The following exception is seen when

TaggedJobExecution.getTagName() is called

[2013-03-17T23:42:53.810-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=43 _ThreadName=Thread-4] [timeMillis: 1363588973810] [levelValue: 1000] [[
com.ibm.jbatch.container.exception.PersistenceException: java.sql.SQLSyntaxErrorException: Syntax error: Encountered "B" at line 1, column 117.
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getTagName(JDBCPersistenceManagerImpl.java:2441)
at com.ibm.jbatch.container.jobinstance.JobOperatorJobExecutionImpl.getTagName(JobOperatorJobExecutionImpl.java:237)
at org.glassfish.batch.ListBatchJobs.handleJob(ListBatchJobs.java:227)
at org.glassfish.batch.ListBatchJobs.executeCommand(ListBatchJobs.java:118)
at org.glassfish.batch.AbstractListCommand.execute(AbstractListCommand.java:99)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.sql.SQLSyntaxErrorException: Syntax error: Encountered "B" at line 1, column 117.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(Unknown Source)
at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHolder.java:586)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:255)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:52)
at com.sun.gjc.spi.ManagedConnectionImpl.prepareCachedStatement(ManagedConnectionImpl.java:992)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareStatement(ConnectionWrapper40.java:173)
at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getTagName(JDBCPersistenceManagerImpl.java:2434)
... 57 more
Caused by: java.sql.SQLException: Syntax error: Encountered "B" at line 1, column 117.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 77 more
Caused by: ERROR 42X01: Syntax error: Encountered "B" at line 1, column 117.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
... 71 more]]



 Comments   
Comment by ScottKurz [ 21/Mar/13 ]

This should be addressed in jbatch 1.0-b19

Comment by Mahesh Kannan [ 23/Mar/13 ]

Fixed in b19

svn commit -m "Integrate version b19 of batch jars. QL Passed"
Sending appserver/batch/glassfish-batch-commands/pom.xml
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Adding appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractLongListCommand.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/javaee-api/javax.javaee-api/pom.xml
Sending appserver/packager/glassfish-common-full/pom.xml
Sending appserver/pom.xml
Transmitting file data ............
Committed revision 60736.





[GLASSFISH-19956] BATCH CLI: asadmin list-batch-job-executions with both --instanceid and --executionid searches job only for execution id Created: 20/Mar/13  Updated: 23/Mar/13  Resolved: 23/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b82_EE7MS7

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


 Description   

Tested with 4.0 Build 80

Steps:

1) Run asadmin list-batch-job-executions --instanceid <INSTANCE_ID> --executionid <EXECUTION_ID>

Issue --> The command only searches for execution id, although job with <INSTANCE_ID> not exists. Command should search for A Job with matching both <INSTANCE_ID> and <EXECUTION_ID>



 Comments   
Comment by Mahesh Kannan [ 23/Mar/13 ]

With b19 integration this is fixed.

svn commit -m "Integrate version b19 of batch jars. QL Passed"
Sending appserver/batch/glassfish-batch-commands/pom.xml
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Adding appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractLongListCommand.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/javaee-api/javax.javaee-api/pom.xml
Sending appserver/packager/glassfish-common-full/pom.xml
Sending appserver/pom.xml
Transmitting file data ............
Committed revision 60736.





[GLASSFISH-19750] list-batch-jobs command must display application / component name that created the job Created: 28/Feb/13  Updated: 23/Mar/13  Resolved: 23/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b80_EE7MS6

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

Issue Links:
Dependency
depends on GLASSFISH-19917 [Batch RI] SQL Exception seen when ca... Resolved

 Description   

Currently the list-batch-jobs command doesn't display the application / component name that submitted the job. We need that to distinguish the jobs submitted by various apps.



 Comments   
Comment by Anissa Lam [ 11/Mar/13 ]

console will need to add one more column in the table to display the application name. Please transfer this to console after this done.

Comment by Mahesh Kannan [ 14/Mar/13 ]

This is a bug

Comment by Mahesh Kannan [ 18/Mar/13 ]

GlassFish-19917 is blocking this. Once the NPE is fixed by RI, this should be working

Comment by Mahesh Kannan [ 23/Mar/13 ]

With b19 integration this is fixed.

svn commit -m "Integrate version b19 of batch jars. QL Passed"
Sending appserver/batch/glassfish-batch-commands/pom.xml
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractListCommand.java
Adding appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/AbstractLongListCommand.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Sending appserver/batch/glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeConfiguration.java
Sending appserver/batch/glassfish-batch-connector/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Sending appserver/javaee-api/javax.javaee-api/pom.xml
Sending appserver/packager/glassfish-common-full/pom.xml
Sending appserver/pom.xml
Transmitting file data ............
Committed revision 60736.





[GLASSFISH-19930] Not able to start Jobs with latest nightly build Created: 19/Mar/13  Updated: 21/Mar/13  Resolved: 21/Mar/13

Status: Closed
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: arunkumar_s Assignee: Mahesh Kannan
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tested with Glassfish nightly b81-03_17_2013

Steps: Start a Batch Job

Issue --> Job not started

[2013-03-19T15:06:36.031+0530] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=30 _ThreadName=http-listener-1(3)] [timeMillis: 1363685796031] [levelValue: 900] [[
StandardWrapperValve[JobSubmitterServlet]: Servlet.service() for servlet JobSubmitterServlet threw exception
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at java.util.Properties.store0(Properties.java:827)
at java.util.Properties.store(Properties.java:765)
at com.ibm.jbatch.container.api.impl.JobOperatorImpl.start(JobOperatorImpl.java:81)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.submitJobFromXML(JobSubmitterServlet.java:131)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.processRequest(JobSubmitterServlet.java:79)
at com.oracle.javaee7.samples.batch.simple.JobSubmitterServlet.doPost(JobSubmitterServlet.java:361)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by shreedhar_ganapathy [ 19/Mar/13 ]

-> Mahesh

Comment by Mahesh Kannan [ 21/Mar/13 ]

Arun: The job parameters keys & values need to be Strings

Here is how my submitJobFromXML method is defined:

private long submitJobFromXML(String jobName, PrintWriter pw)
throws Exception

{ JobOperator jobOperator = BatchRuntime.getJobOperator(); pw.println("<tr><td>JobOperator class </td><td>" + jobOperator.getClass().getName() + " </td></tr>"); Properties props = new Properties(); for (int i=0; i<9; i++) props.setProperty(jobName + "-Param-" + i, "Value--" + i); return jobOperator.start(jobName, props); }

Looks like earlier versions of Batch RI never attempted to call properties.store()





[GLASSFISH-19910] BATCH CLI: asadmin list-batch-jobs -e not working Created: 18/Mar/13  Updated: 19/Mar/13  Resolved: 18/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

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


 Description   

Tested with 4.0 build 80

1) asadmin list-batch-jobs -e <EXECUTION_ID>

This command runs as

asadmin --host localhost --port 4848 --user admin --interactive=false --echo=true --terse=false list-batch-jobs --terse=false 352

It should list Jobs with execution id <EXECUTION_ID>



 Comments   
Comment by Mahesh Kannan [ 18/Mar/13 ]

All batch commands use -j for jobname, -x for executionid and -i for instanceid

svn commit -m "Fix for 19910, 19912, 19909, 19913"
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Transmitting file data ...
Committed revision 60542.





Clean up connector modules of various modules (GLASSFISH-17656)

[GLASSFISH-19819] batch connector has more than what it should have Created: 11/Mar/13  Updated: 18/Mar/13  Resolved: 18/Mar/13

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

Type: Sub-task Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: spo

 Description   

I see batch commands in batch-connector.jar



 Comments   
Comment by Mahesh Kannan [ 18/Mar/13 ]

The batch-connector module now has only the SPI code. The batch commands have been moved to glassfish-batch-commands module

svn commit -m "Rename batch-spi-impl to connector. QL passed."
Deleting appserver/batch/batch-connector
Sending appserver/batch/batch-database/pom.xml
Deleting appserver/batch/batch-spi-impl
Adding appserver/batch/glassfish-batch-commands
Sending appserver/batch/glassfish-batch-commands/pom.xml
Adding appserver/batch/glassfish-batch-connector
Sending appserver/batch/glassfish-batch-connector/pom.xml
Sending appserver/batch/pom.xml
Sending appserver/packager/glassfish-common-full/pom.xml
Transmitting file data .....
Committed revision 60527.





[GLASSFISH-19912] BATCH CLI: asadmin list-batch-job-executions not listing job executions Created: 18/Mar/13  Updated: 18/Mar/13  Resolved: 18/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

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


 Description   

Tested 4.0 b80

$ bin/asadmin list-batch-job-executions

JOBNAME EXECUTIONID STARTTIME ENDTIME BATCHSTATUS EXITSTATUS
Command list-batch-job-executions executed successfully.

Issue--> Not showing all job executions available



 Comments   
Comment by Mahesh Kannan [ 18/Mar/13 ]

This is fixed.

svn commit -m "Fix for 19910, 19912, 19909, 19913"
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Transmitting file data ...
Committed revision 60542.





[GLASSFISH-19909] BATCH CLI: asadmin list-batch-jobs -j or (--job-name) says invalid option Created: 18/Mar/13  Updated: 18/Mar/13  Resolved: 18/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

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


 Description   

Tested with 4.0 b80

Steps:

1) Run asadmin list-batch-jobs j or (-job-name) <JOBNAME> shows invalid option -j or --job-name

Same case for i or (-instance-id) <INSTANCE_ID>

Same case for --execution-id <EXECUTION_ID>



 Comments   
Comment by Mahesh Kannan [ 18/Mar/13 ]

I assume you meant --executionid (or --instanceid)

All batch commands use -j for jobname, -x for executionid and -i for instanceid

svn commit -m "Fix for 19910, 19912, 19909, 19913"
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Transmitting file data ...
Committed revision 60542.





[GLASSFISH-19913] BATCH CLI: Available options must be common across all the batch commands Created: 18/Mar/13  Updated: 18/Mar/13  Resolved: 18/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

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


 Description   

Tested with 4.0 b80

For example:

Available options:

list-batch-jobs --job-name -------- list-batch-job-executions --jobname

list-batch-jobs -e for execution id
list-batch-job-executions -x for execution id

It should be same across all available batch commands



 Comments   
Comment by Mahesh Kannan [ 18/Mar/13 ]

All batch commands use -j for jobname, -x for executionid and -i for instanceid

svn commit -m "Fix for 19910, 19912, 19909, 19913"
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobSteps.java
Sending glassfish-batch-commands/src/main/java/org/glassfish/batch/ListBatchJobs.java
Transmitting file data ...
Committed revision 60542.





[GLASSFISH-19754] [Batch RI] JobStep.getStepId() always returns null Created: 28/Feb/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0

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


 Description   

This is an RI bug. JobStep.getStepId() always returns null as seen in the list-job-steps command



 Comments   
Comment by ScottKurz [ 15/Mar/13 ]

Can you give some more detail ? I can't see in our RI what class or method you might be talking about

Comment by Mahesh Kannan [ 15/Mar/13 ]

If you have a JobStep object (From jobExecution) then calling getStepId always return(ed) null.

Anyways, This has been resolved in b16





[GLASSFISH-19858] Batch RI: JobOperator.getExecutions() and JobOperator.getJobExecutions() has no difference Created: 13/Mar/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b80_EE7MS6

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


 Description   

GF version: glassfish-4.0-b80-03_12_2013

JobOperator.getExecutions() and JobOperator.getJobExecutions() has no difference

Both accepts JobInstance as parameter and returns List<JobExecution>



 Comments   
Comment by ScottKurz [ 15/Mar/13 ]

This was an extra method in the RI... it has been removed since I think the b14, b15 drops of jbatch.

Comment by Mahesh Kannan [ 15/Mar/13 ]

Yes Scott. I too noticed that this has been removed from b15.

Once I integrate b16, I will close this as 'not a bug'

Comment by Mahesh Kannan [ 15/Mar/13 ]

This method has been removed in b16 drop of jbatch.





[GLASSFISH-19863] using REST to configure-batch-runtime always fails Created: 13/Mar/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b81

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

Tags: console

 Description   

Calling configure-batch-runtime is giving back a status 405 FAILURE.
I believe i am passing in the correct payload and using the correct endpoint.

[#|2013-03-10T21:00:27.225-0700|SEVERE|glassfish 4.0|org.glassfish.admingui|_ThreadID=78;_ThreadName=admin-listener(1);_TimeMillis=1362974427225;_LevelValue=1000;|
RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/configure-batch-runtime'; attrs = '

{executorServiceLookupName=java:comp/DefaultManagedExecutorService, dataSourceLookupName=jdbc/__TimerPool}

'|#]



 Comments   
Comment by Mahesh Kannan [ 15/Mar/13 ]

svn commit -m "Fix for 19863: The RestEndpoint.opType should have been a POST (instead of a GET)"
Sending batch-connector/src/main/java/org/glassfish/batch/ConfigureBatchRuntime.java
Sending batch-connector/src/main/java/org/glassfish/batch/ListBatchJobExecutions.java
Sending batch-connector/src/main/java/org/glassfish/batch/ListBatchRuntimeConfiguration.java
Transmitting file data ...
Committed revision 60482.





[GLASSFISH-19751] [Batch RI] getInstanceId() from JobInstance always returns 0 Created: 28/Feb/13  Updated: 09/Mar/13  Resolved: 09/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b79

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


 Description   

The getInstanceId() method from JobInstance always returns 0. This is actually a bug in RI. I will create a bug in jbatch project and link this bug to that.



 Comments   
Comment by Mahesh Kannan [ 09/Mar/13 ]

This seems to have been fixed with the latest code drop





[GLASSFISH-19526] Provide information to console team as to what is needed in the console to support this new component. Created: 13/Jan/13  Updated: 08/Mar/13  Resolved: 08/Mar/13

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

Type: New Feature Priority: Critical
Reporter: Anissa Lam Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-19208 Add console support for 'batch' which... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19231 Provide an asadmin command to retriev... Sub-task Resolved Mahesh Kannan  
GLASSFISH-19234 Provide an asdmin command to display ... Sub-task Resolved Mahesh Kannan  
GLASSFISH-19235 Batch module must provide a way to re... Sub-task Resolved Mahesh Kannan  
GLASSFISH-19528 Provide an asadmin commands to retrie... Sub-task Resolved Mahesh Kannan  

 Description   

The console team is waiting for this information.
This is blocking GLASSFISH-19208.
Please update this issue with what is needed in the console in detail here.
If no support is needed, please specify it and close this issue, and I will close the console RFE issue as well. thanks.



 Comments   
Comment by Mahesh Kannan [ 08/Mar/13 ]

All the sub-tasks have been resolved. So closing the issue

Comment by Anissa Lam [ 08/Mar/13 ]

I need to reopen the issue because one of its subtask is re-opened

Comment by Anissa Lam [ 08/Mar/13 ]

mark resolved again.





Provide information to console team as to what is needed in the console to support this new component. (GLASSFISH-19526)

[GLASSFISH-19528] Provide an asadmin commands to retrieve the configurations for Batch Runtime's threadpool Created: 14/Jan/13  Updated: 08/Mar/13  Resolved: 08/Mar/13

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

Type: Sub-task Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Batch Runtime uses an executor service. We should provide an asadmin command to retrieve and update the configurations for the executor service. Examples of these configurations are a) minimum-size, maximum-size, keep-alive-time and work-queue size

Admin gui must provide a screen to display these configurations and must provide a way to update these values



 Comments   
Comment by Mahesh Kannan [ 08/Mar/13 ]

Use asadmin list-batch-runtime-configuration command to get the the datasourceLoookupName and executorServiceLookupName. These are the only two attributes supported.

Comment by Anissa Lam [ 08/Mar/13 ]

I need to reopen the issue because the following which console depends on is not working properly.

CLI command works fine.

~/Awork/GF/glassfish4/glassfish/bin 4) asadmin list-batch-runtime-configuration
DATA-SOURCE-LOOKUP-NAME EXECUTOR-SERVICE-LOOKUP-NAME
jdbc/__TimerPool java:comp/DefaultManagedExecutorService
Command list-batch-runtime-configuration executed successfully.

but the REST endpoint that console depends on doesn't.
If you do
'http://localhost:4848/management/domain/configure-batch-runtime.json'
It returns the following:

{"message":"","command":"configure-batch-runtime AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"config":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

,"dataSourceLookupName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

,"executorServiceLookupName":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

}}],"commandLog":["configure-batch-runtime"]}}

As you can see, it doesn't return the value for the attributes.

Another question is, it is also showing 'config' as one of the attributes, which doesn't match what you said and what the CLI returns.

Please also clarify if these 3 attributes is editable.
If it is then the CLI command 'list-batch-runtime-configuration' doesn't seem right. 'list-xxx' commands should be just listing out info, not for edit.

Comment by Anissa Lam [ 08/Mar/13 ]

My mistake. I was confused with list-batch-runtime-configuration and configure-batch-runtime.





[GLASSFISH-19755] [Batch RI] EE archives need not have batch.xml to load / instantiate batch artifacts Created: 28/Feb/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

Status: Closed
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b79

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


 Description   

This is an RI bug. [Batch RI] EE archives need not have batch.xml to load / instantiate batch artifacts. batch.xml may not be required with Weld 2.0



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

The root cause is actually 19752





[GLASSFISH-19748] Implement the BatchSecurityHelper SPI defined by Batch Runtime Created: 28/Feb/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b79

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Batch Runtime defines an BatchSecurityHelper SPI that allows simple auth mechanism to limit the output of JobOperator.getJobNames.
The batch-connector module need to implement this.



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

svn commit -m "Implement SecurityHelper SPI (GlassFish-19748). QL Passed"
Sending batch/batch-connector/src/main/java/org/glassfish/batch/AbstractListCommand.java
Sending batch/batch-spi-impl/src/main/java/org/glassfish/batch/spi/impl/BatchRuntimeHelper.java
Adding batch/batch-spi-impl/src/main/java/org/glassfish/batch/spi/impl/GlassFishBatchSecurityHelper.java
Transmitting file data ...
Committed revision 60113.





[GLASSFISH-19757] Attempt to load artifact after ClassLoader.done was called? Created: 01/Mar/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

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

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


 Description   

Looks like some wrong classloader is cached within the Batch runtime:

I am going to investigate this more before filing a bug on RI

[#|2013-02-28T19:48:34.312-0800|WARNING|glassfish 4.0|javax.enterprise.system.util|_ThreadID=124;_ThreadName=pool-27-thread-1;_TimeMillis=1362109714312;_LevelValue=900;|ASURLClassLoader EarClassLoader :
doneCalled = true
doneSnapshot = ASURLClassLoader.done() called ON EarClassLoader :
urlSet = [URLEntry : file:/space/work/glassfish/workspace/trunk/glassfish4/glassfish/domains/domain1/applications/devtest-intro-simple-batchletApp/devtest-intro-simple-batchlet-ejb_jar/, URLEntry : file:/space/work/glassfish/workspace/trunk/glassfish4/glassfish/domains/domain1/generated/ejb/devtest-intro-simple-batchletApp/devtest-intro-simple-batchlet-ejb_jar]
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@579169f6

AT Thu Feb 28 19:46:12 PST 2013
BY :[java.lang.Thread.getStackTrace(Thread.java:1567), com.sun.enterprise.loader.ASURLClassLoader.done(ASURLClassLoader.java:204), com.sun.enterprise.loader.ASURLClassLoader.preDestroy(ASURLClassLoader.java:172), org.glassfish.javaee.full.deployment.EarClassLoader.preDestroy(EarClassLoader.java:100), org.jvnet.hk2.internal.ServiceLocatorImpl.preDestroy(ServiceLocatorImpl.java:833), org.jvnet.hk2.internal.ServiceLocatorImpl.preDestroy(ServiceLocatorImpl.java:817), org.glassfish.internal.data.ApplicationInfo.clean(ApplicationInfo.java:451), com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1068), com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1096), org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:400), com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:528), com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:524), java.security.AccessController.doPrivileged(Native Method), javax.security.auth.Subject.doAs(Subject.java:356), com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:523), com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:547), com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1424), com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108), com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759), com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1675), org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:387), org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:231), sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57), sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.lang.reflect.Method.invoke(Method.java:601), org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81), org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125), org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152), org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:93), org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350), org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345), org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102), org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:207), org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317), org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:183), org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:852), org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:321), org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161), org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181), com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246), org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164), org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175), org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273), org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200), org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134), org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112), org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77), org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820), org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55), org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135), org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564), org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544), java.lang.Thread.run(Thread.java:722)] Parent -> org.glassfish.internal.api.DelegatingClassLoader@579169f6
was requested to find resource META-INF/batch.xml after done was invoked from the following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader.findResource(ASURLClassLoader.java:503)
at java.lang.ClassLoader.getResource(ClassLoader.java:1138)
at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227)
at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:866)
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.getBatchXMLStreamFromClassLoader(DelegatingBatchArtifactFactoryImpl.java:113)
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.initArtifactMapFromClassLoader(DelegatingBatchArtifactFactoryImpl.java:106)
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.load(DelegatingBatchArtifactFactoryImpl.java:84)
at com.ibm.batch.container.artifact.proxy.ProxyFactory.loadArtifact(ProxyFactory.java:52)
at com.ibm.batch.container.artifact.proxy.ProxyFactory.createItemReaderProxy(ProxyFactory.java:95)
at com.ibm.batch.container.impl.ChunkStepControllerImpl.initializeChunkArtifacts(ChunkStepControllerImpl.java:707)
at com.ibm.batch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:645)
at com.ibm.batch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:156)
at com.ibm.batch.container.impl.JobControllerImpl.doExecutionLoop(JobControllerImpl.java:398)
at com.ibm.batch.container.impl.JobControllerImpl.executeJob(JobControllerImpl.java:184)
at com.ibm.batch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:85)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2013-02-28T19:48:34.331-0800|SEVERE|glassfish 4.0||_ThreadID=124;_ThreadName=Thread-4;_TimeMillis=1362109714331;_LevelValue=1000;|Exception in thread "pool-27-thread-1"|#]

[#|2013-02-28T19:48:34.332-0800|SEVERE|glassfish 4.0||_ThreadID=124;_ThreadName=Thread-4;_TimeMillis=1362109714332;_LevelValue=1000;|com.ibm.batch.container.exception.BatchContainerRuntimeException: This job failed unexpectedly.
at com.ibm.batch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:99)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.ibm.batch.container.exception.BatchContainerRuntimeException: java.lang.RuntimeException: Wrappering earlier uncaught exception:
at com.ibm.batch.container.impl.JobControllerImpl.executeJob(JobControllerImpl.java:241)
at com.ibm.batch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:85)
... 3 more
Caused by: java.lang.RuntimeException: Wrappering earlier uncaught exception:
at com.ibm.batch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:197)
at com.ibm.batch.container.impl.JobControllerImpl.doExecutionLoop(JobControllerImpl.java:398)
at com.ibm.batch.container.impl.JobControllerImpl.executeJob(JobControllerImpl.java:184)
... 4 more
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Unable to load batch.xml
at com.ibm.batch.container.artifact.proxy.ProxyFactory.loadArtifact(ProxyFactory.java:54)
at com.ibm.batch.container.artifact.proxy.ProxyFactory.createItemReaderProxy(ProxyFactory.java:95)
at com.ibm.batch.container.impl.ChunkStepControllerImpl.initializeChunkArtifacts(ChunkStepControllerImpl.java:707)
at com.ibm.batch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:645)
at com.ibm.batch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:156)
... 6 more
Caused by: java.lang.IllegalStateException: Unable to load batch.xml
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.getBatchXMLStreamFromClassLoader(DelegatingBatchArtifactFactoryImpl.java:116)
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.initArtifactMapFromClassLoader(DelegatingBatchArtifactFactoryImpl.java:106)
at com.ibm.batch.container.services.impl.DelegatingBatchArtifactFactoryImpl.load(DelegatingBatchArtifactFactoryImpl.java:84)
at com.ibm.batch.container.artifact.proxy.ProxyFactory.loadArtifact(ProxyFactory.java:52)
... 10 more|#]



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

The issue was that the devtest (that I used to file this bug) didn't wait till the jobstatus became either 'COMPLETED' or 'FAILED'. After submitting the job (and before the job was actually executed by the RI) the test exited causing the web-app class loader to unload the application artifacts





[GLASSFISH-19749] GlassFish Batch connector must implement the ExecutorServiceProvider SPI Created: 28/Feb/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b79

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

GlassFish Batch connector must implement the ExecutorServiceProvider SPI (defined by Batch RI).
This allows RI to use one of our ManagedExecutorService (JSR 236)



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

Fixed in svn revision 60110.
batch-ri-impl contains the implementation of the SPI





[GLASSFISH-19753] [Batch RI] Incorrect end-time reported by JobExecution.getEndTime() Created: 28/Feb/13  Updated: 07/Mar/13  Resolved: 07/Mar/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b79

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


 Description   

This is an RI bug.

JobExecution.getEndTime() always returns: 1969-12-31 16:00:00.0



 Comments   
Comment by Mahesh Kannan [ 07/Mar/13 ]

This is fixed in b13 (svn commit: 60110)





Provide information to console team as to what is needed in the console to support this new component. (GLASSFISH-19526)

[GLASSFISH-19234] Provide an asdmin command to display / retrieve status of a Batch job Created: 25/Oct/12  Updated: 28/Feb/13  Resolved: 28/Feb/13

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

Type: Sub-task Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mahesh Kannan [ 17/Dec/12 ]

IBM did the first code drop only last Friday. Hence moving this to MS4

Comment by Mahesh Kannan [ 28/Feb/13 ]

Implemented the following commands:

1. list-batch-jobs command. This command takes an optional jobName as argument. If no jobName is specified, then all batch jobs are listed. The --long option can be used to find out the start-time, end-time, instanceId, executionId etc.

2. list-batch-job-executions can be used to list job executions based on either instanceId or executionId. --long option can be used to list batch-status, exit-status, job-parameters step-count etc.

3. list-batch-job-steps can be use to list the status of every step in a job-execution. Again, --long can be used to retrieve step-status, step-exit-status, step-metrics etc.





Provide information to console team as to what is needed in the console to support this new component. (GLASSFISH-19526)

[GLASSFISH-19235] Batch module must provide a way to retrieve the number of instances of a job that are running Created: 25/Oct/12  Updated: 28/Feb/13  Resolved: 28/Feb/13

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

Type: Sub-task Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For a given job there could be multiple instances running. Provide a command to retrieve details (like jobId etc.) about these instances.

This can be used by admin gui to display the number of instances of jobs running for a job (type)



 Comments   
Comment by Mahesh Kannan [ 28/Feb/13 ]

Implemented list-batch-jobs command. This command by default (when --headers or --long is not used) will provide the instance count for each job





Provide information to console team as to what is needed in the console to support this new component. (GLASSFISH-19526)

[GLASSFISH-19231] Provide an asadmin command to retrieve the list of batch jobs that are running Created: 25/Oct/12  Updated: 28/Feb/13  Resolved: 28/Feb/13

Status: Resolved
Project: glassfish
Component/s: batch
Affects Version/s: 4.0_b60
Fix Version/s: 4.0_b72_EE7MS4

Type: Sub-task Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JobOperator class provides an api to retrieve the list of all job names. We should provide an asadmin command to list all the job names.

The console can use this command to display the list of batch jobs



 Comments   
Comment by Mahesh Kannan [ 17/Dec/12 ]

IBM did the first code drop only last Friday. Hence moving this to MS4

Comment by Mahesh Kannan [ 28/Feb/13 ]

Implemented list-batch-jobs command. This command takes an optional jobName as argument. If no jobName is specified, then all batch jobs are listed.





[GLASSFISH-19232] Batch RI must use the WorkManager that is available in GF Created: 25/Oct/12  Updated: 14/Jan/13  Resolved: 14/Jan/13

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

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Batch runtime requires a WorkManager to schedule and run batch jobs. This issue is to make Batch runtime use the WorkManager that is available in GF. This task may later be transferred to the WorkManager team if any changes are required in WorkManager itself.



 Comments   
Comment by Mahesh Kannan [ 17/Dec/12 ]

IBM did the first code drop only last Friday. Hence moving this to MS4

Comment by Mahesh Kannan [ 14/Jan/13 ]

Closing this as Batch Runtime will NOT be using orkManager





Generated at Sun Feb 07 10:53:15 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.