[GLASSFISH-21382]  A system exception occurred during an invocation on EJB Created: 27/Jun/15  Updated: 20/Apr/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dyego Assignee: diksha.nagpal
Resolution: Unresolved Votes: 2
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 14 + 5GB of ram + SSD 80GB



 Description   

In my application, randomily i get :

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[
A system exception occurred during an invocation on EJB PaisesNacionalidadesRepositoryRJ, method: public us.linkedby.link.selo.entities.RjPaisesnacionalidades us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesRepositoryRJ.getRjPaisesnacionalidadesByNomePais(java.lang.String)]]

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[

javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:361)
at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:255)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4524)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1986)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy337.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades._EJB31_GeneratedPaisesNacionalidadesRepositoryRJIntf__Bean_.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesServiceRJ.getRjPaisesnacionalidadesCodigoByNomePais(PaisesNacionalidadesServiceRJ.java:69)
at sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

But, this occurs if i call 15k times the EJB method... and ocurs in diferents parts of my code...



 Comments   
Comment by dyego [ 27/Jun/15 ]

only in linux, on windows doest occurs

Comment by dyego [ 27/Jun/15 ]

The transaction is maked to rollback in diferent points on execution and this error occurs after that...

If i invoce 10k times the EJB method this not occurs..

11k not occurs...

15k occurs...

help!

Comment by gururaja1234 [ 21/Mar/17 ]

I cannot reproduce this bug can you send me the EAR file that you have used to reproduce this issue this might be a configuration issue.

Comment by diksha.nagpal [ 20/Apr/17 ]

Hi,
Can you provide me a sample app to reproduce this bug.





[GLASSFISH-21280] Transaction attribute in subclass is ignored if a generic supertype exist Created: 29/Dec/14  Updated: 16/Apr/17

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

Type: Bug Priority: Critical
Reporter: martinandersson.com Assignee: diksha.nagpal
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Tested on Windows 7 x64 and Windows 8 x64


Tags: annotations, ejb-container, inheritance, transactionmanager

 Description   

According to "Common Annotations" spec as well as the EJB spec, supertype transaction attribute annotations are "always ignored" if the subclass override a method. Only if the superclass has a method not overridden by the subclass do annotations put in the superclass apply.

This work as long as the supertype, whether that be a class or interface, is not generic. As soon as it is, GlassFish behave in the other way around: ignoring the most specific subclass annotations and instead use annotations declared in the supertype.

Full description, specification quotes as well as test cases is located here (the project is a working Maven project, clone + build and all tests are executed using Arquillian):

https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/ejb/transactions/AnnotationInheritanceTest.java

In a separate project my mine that first exposed this issue, I have no workaround to apply. I have to stop using GlassFish or begin a new architectural design. Given that transactions are an intrinsic part of applications, as well as inheritance is a common method for code reuse in object oriented design, I consider this bug "critical". Also note that WildFly 8.2.0 pass all the tests provided in the link.






[GLASSFISH-21370] Periodic Deadlock in EJB Timer Service Created: 02/Jun/15  Updated: 16/Apr/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: slominskir Assignee: diksha.nagpal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Enterprise Linux 6



 Description   

Occasionally while attempting to redeploy an application the redeployment will fail due to what appears to be a deadlock situation with the EJB Timer service. This happens fairly infrequently, perhaps 6 times in the last two years. However, when it does happen the only recourse is to restart GlassFish forcefully, which is fairly invasive since the redeploy with the "--keepstate=true" option allows redeployment without downtime. The problem prevents all application deployment/redeployment/undeployment, and GlassFish starting/stopping/restarting so during one of these events I must forcefully kill the Glassfish process (kill -9 on Linux) . It appears that the EJB Timer Service uses the EclipseLink ORM library to store timer information in a Derby database and encounters a Lock timeout situation. The stack trace from the most recent incident follows:

[2015-06-02T12:32:53.965-0400] [glassfish 4.0] [WARNING] [] [org.eclipse.persistence.session.file:/opt/glassfish/4/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773965] [levelValue: 900] [[

Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
Error Code: 30000
Call: SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)
bind => [1 parameter bound]
Query: ReportQuery(name="findTimerIdsByContainer" referenceClass=TimerState sql="SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:679)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:248)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2714)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2651)
at org.eclipse.persistence.queries.ReportQuery.executeDatabaseQuery(ReportQuery.java:847)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(TimerBean.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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 com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy307.findTimerIdsByContainer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.stopTimers(PersistentEJBTimerService.java:643)
at com.sun.ejb.containers.BaseContainer.stopTimers(BaseContainer.java:2422)
at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4191)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doShutdown(SingletonLifeCycleManager.java:172)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:293)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:324)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:380)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1056)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:2125)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:113)
at com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:497)
at com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:465)
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:294)
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:358)
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:473)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.destroyOne(AsyncRunLevelContext.java:196)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:159)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$DownAllTheWay.run(CurrentTaskFuture.java:583)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.go(CurrentTaskFuture.java:120)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.proceedTo(AsyncRunLevelContext.java:296)
at org.glassfish.hk2.runlevel.internal.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:66)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:532)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:485)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:82)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
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:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)
Caused by: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
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.EmbedResultSet.closeOnTransactionError(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
at com.sun.gjc.spi.base.ResultSetWrapper.next(ResultSetWrapper.java:103)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processResultSet(DatabaseAccessor.java:754)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:653)
... 80 more
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 92 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(Unknown Source)
at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
... 85 more
]]

[2015-06-02T12:32:53.970-0400] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773970] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public java.util.Set org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(long)]]



 Comments   
Comment by slominskir [ 02/Jun/15 ]

The stack trace above shows that it is impossible to cleanly shutdown GlassFish when the EJB Timer service is stuck in this unusual state. Deployment is also impossible.

Comment by gururaja1234 [ 15/Feb/17 ]

can you look at this link https://wiki.apache.org/db-derby/LockDebugging.
it has more information about "Configuring deadlock detection and lock wait timeouts"





[GLASSFISH-21412] CLONE - EJB + JAX-RS don't work with updated example Created: 11/Aug/15  Updated: 16/Apr/17

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

Type: Bug Priority: Major
Reporter: atrajano Assignee: diksha.nagpal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones GLASSFISH-20654 EJB + JAX-RS don't work on the simple... Resolved

 Description   
/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package pcrl.model.services;

import javax.annotation.ManagedBean;
import javax.ejb.Stateless;
import javax.enterprise.context.RequestScoped;
import pcrl.model.entities.RepairLocation;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceUnit;
import javax.transaction.Transactional;
import javax.ws.rs.BeanParam;
import javax.ws.rs.POST;
import javax.ws.rs.Path;


/**
 *
 * @author walec51
 */
@Stateless
@Path("/api/RepairLocationRepository")
public class RepairLocationRepository {
    
    @PersistenceContext
    private EntityManager em;
    
    @POST
    @Path("add")
    public void add(@BeanParam RepairLocation rl) {
        em.persist(rl);
    }
}

SEVERE:   WebModule[/PcRepairLocations]Exception starting filter pcrl.PcrlApplication
java.lang.InstantiationException
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
	at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5297)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5909)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
	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.deployment.admin.ReDeployCommand.execute(ReDeployCommand.java:131)
	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 com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
	at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
	at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
	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.lang.IllegalStateException: Error when configuring to use the EJB interceptor binding API. JAX-RS EJB integration can not be supported.
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:168)
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.bind(EjbComponentProvider.java:200)
	at org.glassfish.jersey.server.ApplicationHandler.bindWithComponentProvider(ApplicationHandler.java:809)
	at org.glassfish.jersey.server.ApplicationHandler.bindProvidersAndResources(ApplicationHandler.java:741)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:388)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	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.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:277)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:379)
	at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
	... 53 more
Caused by: java.lang.reflect.InvocationTargetException
	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.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:163)
	... 70 more
Caused by: java.lang.NullPointerException
	at com.sun.ejb.containers.InternalInterceptorBindingImpl.registerInterceptor(InternalInterceptorBindingImpl.java:97)
	... 75 more


 Comments   
Comment by atrajano [ 12/Aug/15 ]

It didn't clone the comments as I expected... here is the text that should've gone up on the description

I am encountering the same error on GlassFish 4.1

I created a simple example

https://github.com/trajano/test/tree/local-beans

A simple @Stateless SLSB
A JAX-RS resource annotated with @Stateless
The resource has an @EJB reference
The @PostConstruct method simply does a System.out

In my example it fails the moment the resource SLSB is postconstructed

http://localhost:8080/test-war/V1/resource





[GLASSFISH-21667] SessionContext.getCallerPrincipal() returns previous principal on TimerService Created: 27/Jan/17  Updated: 16/Apr/17

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

Type: Bug Priority: Major
Reporter: nkobayashi Assignee: diksha.nagpal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1. Authenticated users (for example USER1) call SSB asynchronous method with ejb-thread-pool1.

2. TimerService's timeout method called with same ejb-thread-pool1, then SessionContext.getCallerPrincipal() returns USER1.

Example :

@Stateless
public class FooServiceImpl implements FooService {
    @Resource
    private SessionContext context;

    @Override
    @Asynchronous
    public void exec() {
        logger.info("exec()[{}]", context.getCallerPrincipal());
        // ...
    }
}

USER1 calls exec() then

[__ejb-thread-pool1] INFO FooServiceImpl - exec()[USER1]

So TimerService is

@Singleton
@Startup
@ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
public class SchedulerService {

    @Resource
    private TimerService timerService;

    @Resource
    private SessionContext context;

    @PostConstruct
    public void postConstruct() {
        TimerConfig timerConfig = new TimerConfig();
        // ...
        timerService.createIntervalTimer(0, 10000, timerConfig);
    }

    @Timeout
    public void handleTimeout(Timer timer) {
        logger.info("handleTimeout()[{}]", context.getCallerPrincipal());
        // ...
    }
}

Log is

[__ejb-thread-poolX] INFO SchedulerService - handleTimeout()[ANONYMOUS]
[__ejb-thread-pool1] INFO SchedulerService - handleTimeout()[USER1]
[__ejb-thread-poolX] INFO SchedulerService - handleTimeout()[ANONYMOUS]

ejb-thread-pool1 use previous principal !






[GLASSFISH-21476] Resource not available in @Singleton @Predestroy method Created: 22/Dec/15  Updated: 11/Apr/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kiranmohane Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

openjdk version "1.8.0_66
Ubuntu 15.10



 Description   

It seems like resources are not available to a Singleton's @Predestroy method.

@PreDestroy
public void cleanup() {
logger.info("*** Application shutting down. Dropping temporary tables ***");
try

{ connection = dataSource.getConnection(); Statement statement = connection.createStatement(); statement.execute("drop table TABLE1"); statement.execute("drop table TABLE2"); connection.close(); connection = null; }

catch (SQLException sqle)

{ sqle.printStackTrace(); }

}
The call to getConnection() fails with the error "No Pool Meta Data object associated with the pool". Note that the getConnection() call is successful in the @PostConstruct methods.

Is it a Bug in the application server implementation? If not, what is the most elegant way to drop temporary tables?

(Using Glassfish 4.1.1 + Derby DB. The datasource is created using glassfish-resources.xml deployed with the EAR

<resources>
<jdbc-resource pool-name="EmbeddedDerbyPool"
jndi-name="java:app/jdbc/ActionBazaarDS" />
<jdbc-connection-pool name="EmbeddedDerbyPool"
res-type="javax.sql.DataSource"
datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
is-isolation-level-guaranteed="false">
<property name="databaseName" value="memory:action-bazaar-db"/>
<property name="createDatabase" value="create"/>
</jdbc-connection-pool>
</resources>



 Comments   
Comment by gururaja1234 [ 15/Feb/17 ]

Can you provide the steps to reproduce the bug.
Did you undeploy the application?
Or Did you shutdown the server?
If you shutdown the server it might be the case that the datasource might not be available to the ejb container.

Comment by kiranmohane [ 31/Mar/17 ]

I was probably undeploying the application.





[GLASSFISH-21465] TimerService createCalendarTimer with dayOfWeek Created: 15/Nov/15  Updated: 14/Mar/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rsoika Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: timer

 Description   

Can you please reopen the following bug

https://java.net/jira/browse/GLASSFISH-20673

or at least give some feedback to the comunity.

===
Ralph



 Comments   
Comment by Kokil_Jain [ 13/Feb/17 ]

I am still unable to reproduce the bug(getting the expected output).
Current Date : Sun Feb 12 15:14:41 IST 2017
Here are the server log messages:

SCHEDULE : ScheduleExpression [second=0;minute=12;hour=15;dayOfMonth=*;month=*;dayOfWeek=1-5;year=*;timezoneID=null;start=null;end=null]

NEXT_TIMEOUT : Mon Feb 13 15:12:00 IST 2017

Can i know your system settings? Which OS are you on?
And also if you can provide the server logs of the latest run.





[GLASSFISH-21516] Retrieving AppName from InitialContext behaves differently depending on the current callstack in remote ejb Created: 19/Feb/16  Updated: 09/Mar/17

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.1.1
Fix Version/s: None

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


 Description   

I noticed changing results when requesting "java:app/AppName" in an EntityListener. The result varies depending on the call to InitialContext.lookup being in the transaction of in the transaction boundary handler when using Remote EJBs.

The scenario
The first application (TwixLeft) is an EAR archive containing a RemoteEJB to modify an entity, Country. The entity has an EntityListener that uses the AppName for other bean discovery (which is left out the example), the EntityListener only does a lookup now.

The second application (TwixRight) is a web archive containing a servlet executing a remote ejb call. The call can modify the Country Entity which forces a call to the entity listener.

Depending on the code inside the RemoteEJB the InitialContext.lookup returns different results. When being called from code executed really inside the remote EJB method the result of AppName is twixleft-ear.

The a call is made to the servlet to change an entity:

http://localhost:8080/twixright-web/right?action=update&id=1&input=hi8
Check the ConsoleLog for glassfish, the output is twixright-web

http://localhost:8080/twixright-web/right?action=updateFlush&id=1&input=hi2
Check the ConsoleLog for glassfish, the output is twixleft-ear

Question
Why does the AppName change? The RemoteEJB is proxied by Glassfish but handling the transaction belongs to the RemoteEJB call, to my opinion inside TwixLeft. If the remote EJB method code doesn't force a database write and has Glassfish taking care of this results vary.

The application can be used in both Glassfish 3 and 4 and both have the same results.

@Stateless
@Remote(value = EchoServiceRemote.class)
public class EchoService implements EchoServiceRemote {

    @PersistenceContext(name = "twixleft")
    EntityManager em;

    @Override
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public String updateCountry(Long id, String description) {
        Country country = em.find(Country.class, id);
        country.setDescription(description);		

        return echo(description);
		
		// entity listener is called when this method is already returned by Glassfish transaction wrappers. the result of
		// InitialContext.lookup is twixright-web. This is not expected.
    }

    @Override
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public String updateCountryWithFlush(Long id, String description) {
        Country country = em.find(Country.class, id);
        country.setDescription(description);
		
		// the em.flush forces JPA to change the entity immediatly and invokes the entity listener. the result of 
		// InitialContext.lookup is twixleft-ear. This is what I expect
        em.flush();

        return echo(description);
    }

}



 Comments   
Comment by sisirhc [ 19/Feb/16 ]

I created an example project which can be found via this link: https://github.com/cwesdorp/publicfiles/blob/master/GLASSFISH-21516-appname_context.zip





[GLASSFISH-21462] adminGUI does not load the classpath from manifest.mf to the precompilejsp in Application Deploy module Created: 05/Nov/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui, classloader, deployment, ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ccagf Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: jspc, precompilejsp, waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PWC6112, admin-gui, admingui, deploy, java.lang.ClassNotFoundException:, jspc, precompilejsp

 Description   

in adminGUI ==> Applications ==> Deploy Applications or Modules ==> Precompile JSPs:

if You choose the Option - Precomplier works with JARs included in the LIB
But Fails when 3rd Party Jars are refeneced in the manifest.mf file - as the Glassfish Precomplier is not reading the class path from manifest.mf.

In Glassfish Version 2.1.1 It Works - Stopped working since Glassfish v3.
Does Not work on Glassfish 4.1.1

Sugested BUG Fix - adminGUI (when precompilejsp is checked) also needs to Read the Manifest.MF's Class-Path and pass it on to the jspc compiler.

Error: PWC6112
java.lang.ClassNotFoundException:

Just FYI - When I pass the class-path part of jspc and copmile it works - so the bug surely is on the adminGUI console



 Comments   
Comment by sumasri [ 14/Feb/17 ]

I created a web application and referred third party jar in manifest.mf file and created war file for deploying.
Deployed that app and is working as expected. I do not see any issue as specified in the issue.
If you still see the issue, please provide me the app and exact steps to reproduce the issue.





[GLASSFISH-21129] User ID in File security realm affects role mapping Created: 14/Jul/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container, security
Affects Version/s: 4.1_dev
Fix Version/s: None

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

using nightly build from 2014-07-14
using following param in config:
<security-service activate-default-principal-to-role-mapping="true">



 Description   

Suppose following two simple classes:

@Stateless
@RunAs("student")
@PermitAll
public class Student {

    @Resource
    private SessionContext context;

    @EJB
    Notebook notebook;

    public String getNotebookPrincipal(){
        return notebook.getCallerPrincipal();
    }

    public String getStudentPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

and:

@Stateless
@RunAs("notebook")
@RolesAllowed("student")
public class Notebook {

    @Resource
    private SessionContext context;

    public String getCallerPrincipal(){
        return context.getCallerPrincipal().toString();
    }
}

When I have following mapping then it's fine:

User ID Group
student student
notebook student:notebook

but I cannot see any reason, why it should fail with e.g.:

User ID Group
john student
notebook student:notebook

Getting:

Caused by: javax.ejb.EJBAccessException
	at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2351)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2123)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy254.getCallerPrincipal(Unknown Source)
	at test.sceurity.__EJB31_Generated__Notebook__Intf____Bean__.getCallerPrincipal(Unknown Source)
	at test.sceurity.Student.getNotebookPrincipal(Student.java:29)
	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:4786)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
	at sun.reflect.GeneratedMethodAccessor296.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:608)
	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: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:4758)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
	... 103 more
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation
	at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1960)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
	... 137 more


 Comments   
Comment by tremes [ 14/Jul/14 ]

Maybe I am wrong, but I understand that @RunAs specifies role name and not user name. I would attach simple reproducer app, but looks like I cannot.





[GLASSFISH-21137] NullPointerException calling ejbContext.getCallerPrincipal(); Created: 20/Jul/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0, 4.1_dev
Fix Version/s: None

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

Linux



 Description   

We have a non null (verified) ejbContext injected into an interceptor

Context is injected (and not null) using:
@Inject
private SessionContext ejbContext;

This interceptor is running as part of the ejb layer. It is intercepting the request to an ejb @Stateless @WebService.

Because it seems to be inconsistent, I want to add one thing I noticed. It seems to be fine if the web service is called directly, but the problem occurs when the web services are called from the web apps deployed on the same app server. That is we have several wars that make their calls to the business layer via web services.

This is obviously a show stopper when using this architecture.

Here is the stack trace of when we call ejbContext..getCallerPrincipal();

2014-07-19 20:17:28.066 - :: WARN [http-listener-2(9)] c.p.p.i.CurrentUserInstaller:60 - Got a NPE while trying to get caller principal from ejbContext
java.lang.NullPointerException: null
at org.apache.catalina.connector.Request.setAttribute(Request.java:2021) ~[web-core.jar:na]
at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:585) ~[web-core.jar:na]
at org.jboss.weld.context.beanstore.http.RequestBeanStore.setAttribute(RequestBeanStore.java:53) ~[na:na]
at org.jboss.weld.context.beanstore.AttributeBeanStore.put(AttributeBeanStore.java:125) ~[na:na]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:99) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99) [weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.proxies.EJBContext$SessionContext$1591394485$Proxy$_$$_WeldClientProxy.getCallerPrincipal(Unknown Source) ~[weld-osgi-bundle.jar:na]



 Comments   
Comment by gcruscoe [ 30/Jul/14 ]

Wanted to add one more thing. I created a test case for 21118 and was able to use it to reproduce this issue as well. This time I am using 4.0.1 b09 (plus fix for 21118). I am using Java 8u20(ea).

This version of the exception occurs I believe when the session has timed out. It makes sense there is no user principal but it causes a NullPointerException and then the EJBException and rollback making it a big problem.

Here is the stack trace.
2014-07-30 09:48:07.800 - :: ERROR [http-listener-2(10)] com.sun.xml.ws.server.sei.TieHandler:282 - null
javax.ejb.EJBException: null
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748) ~[ejb-container.jar:na]
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698) ~[ejb-container.jar:na]
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503) ~[ejb-container.jar:na]
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566) ~[ejb-container.jar:na]
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:205) ~[ejb-container.jar:na]
at com.sun.proxy.$Proxy207.getMessage(Unknown Source) ~[na:na]
...
Caused by: java.lang.NullPointerException: null
at com.sun.ejb.containers.EJBContextImpl.getCallerPrincipal(EJBContextImpl.java:411) ~[ejb-container.jar:na]
at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_20-ea]
at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_20-ea]
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) ~[weld-osgi-bundle.jar:2014-06-18 10:59]
at org.jboss.weld.proxies.EJBContext$SessionContext$692107405$Proxy$_$$_WeldClientProxy.getCallerPrincipal(Unknown Source) ~[weld-osgi-bundle.jar:na]
at com.test.interceptors.SystemUserInterceptor.findSystemUser(SystemUserInterceptor.java:27) ~[TestEjb-0.0.1-SNAPSHOT_jar/:na]





[GLASSFISH-21154] Missing Descriptor on Redeploy Created: 04/Aug/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container, entity-persistence
Affects Version/s: 4.1_dev
Fix Version/s: None

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

JDK 1.8.0_11, NetBeans 8, Windows 8.1 Pro 64, i7-2600, 16GB RAM



 Description   

After redeploy I'm getting a missing descriptor error. The error is thrown when I call methods with an EntityManager.createNativeQuery() statement.

[snip]
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-6007] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.QueryException
Exception Description: Missing descriptor for...
[snip]

On restart of the application server and fresh deploy of the application I do not get this message.

I did not see this behavior in Glassfish 4.0.1 build 8. I'm not sure if this item existed in Glassfish 4.0.1 build 9 but would be glad to check if it would be useful for this bug report.



 Comments   
Comment by gesker [ 11/Aug/14 ]

Issue remains in Glassfish 4.1 build 11





[GLASSFISH-18420] EJB: Inspect JDK 7 getMethods()/getDeclaredMethods() usage Created: 28/Feb/12  Updated: 20/Dec/16

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

Type: Task Priority: Major
Reporter: Joe Di Pol Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Recent JDK 7 releases have altered the order of methods returned by the
Class.getMethods() and Class.getDeclaredMethods() calls. The order is
no longer stable and can change from one JVM run to the next.

This caused a number of sporadic bugs to appear during 3.1.2 development
when running with JDK 7. Those have been fixed, but further inspection
of the source has found a number of cases where we use getMethods() and
getDeclaredMethods().

Each of these cases should be visually inspected to see if the code is
making any assumptions on the order of methods returned by get*Methods().
In particular it should handle the case of multiple methods having the
same name.

For more details on what to look for and how to fix it see this document:

https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods

Please inspect the following files for their use of getMethods() /
getDeclaredMethods() to ensure the code is not making any assumptions
with respect to the order of methods returned. Create bugs for
any issues that need to be fixed and link them to this task. Once you
have completed inspection update this task with status and close it.

GlassFish Core EJB container implementation
    AbstractEjbHandler.java
    BaseContainer.java
    BeanMethodCalculatorImpl.java
    EJBHandler.java
    EjbOptionalIntfGenerator.java
    Generator.java
    HomeGenerator.java
    InitHandler.java
    Remote30WrapperGenerator.java
    RemoteGenerator.java
    ServiceInterfaceGenerator.java
    WrapperGenerator.java
    AccessTimeoutHandler.java
    AsynchronousHandler.java
    LockHandler.java
    SystemInterceptorProxy.java





[GLASSFISH-18890] Removing dependency between EjbContainer config bean and EjbTimerService config beans Created: 11/Jul/12  Updated: 20/Dec/16

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

Type: Task Priority: Major
Reporter: Masoud Kalali Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: config-api, ejb-container

 Description   

The EjbContainer config bean should not have direct dependency on EjbTimerService config bean. The solution would be defining an EjbContainerExtension which EjbTimerService implements. Then EjbContainer will have a List of EjbContainerExtension extensions with two accessor methods.

List<EjbContainerExtension> getExtensions() and <T extends EjbContainerExtension> T getExtensionByType(Class<T> type). For more details on config bean extension patterns Domain and Config class can be good places to look... It may requires creating a new module as timer service is not part of EJB Lite






[GLASSFISH-19036] Deployment of the same EJB app with a different name should succeed by default Created: 25/Aug/12  Updated: 20/Dec/16

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the 2nd deployment of the same EJB app but with a different --name option fails because of the conflict in GF-specific (non-portable) JNDI names. It should succeed with a warning and either the 2nd app shouldn't get non-portable JNDI names, or get some adjusted version.



 Comments   
Comment by marina vatkina [ 15/May/13 ]

The same problem is happening if 2 EJBs share the same interface





[GLASSFISH-19310] Ensure methods declared on Object class are not exposed as business methods of the no-interface view Created: 09/Nov/12  Updated: 20/Dec/16

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

3.4.4 Session Bean's No-Interface View: Only public methods of the bean class (and any superclasses, except methods declared on the java.lang.Object class) may be invoked through the no-interface view.

GF already filters methods declared in Object (EjbOptionalIntfGenerator), this a tracker bug to investigate/fix any issues with the support.



 Comments   
Comment by Srini [ 18/Nov/12 ]

Support exists in GF already, convert to a tracker bug

Comment by marina vatkina [ 20/Nov/12 ]

equals (and hashCode) for the no-interface view must follow the rules defined in EJB 3.2 (Core) spec, section 3.4.7 Session Object Identity. Currently they use Object.equals and (even worse) allow bean developer to override it (that latter case must result in a warning).





[GLASSFISH-19399] Async method should not be allowed on component interface or ´╗┐web service client view Created: 04/Dec/12  Updated: 20/Dec/16

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

EJB spec requires that

Business methods exposed through the local component, remote component, and web service client views must not be designated as asynchronous

GF doesn't prohibit it (not only deployment succeeds, but the method is executed without an error)






[GLASSFISH-18567] Reading HomeHandle from stream causes ClassNotFoundException: com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase Created: 28/Mar/12  Updated: 20/Dec/16

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

EJB devtests from pre-v3 days had (need to check all similar tests when fixed) - see devtests/ejb/bmp/handle - tests that do this:

ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(handle);
oos.flush();

byte[] data = bos.toByteArray();
ByteArrayInputStream bis = new ByteArrayInputStream(data);
ObjectInputStream ois = new ObjectInputStream(bis);
HomeHandle newHandle = (HomeHandle) ois.readObject();

The last line fails (tested on trunk) with CNF (stack trace below). The package is exported by the orb bundle and imported by the ejb-container. CL during write/read is the EarCL:

[#|2012-03-27T15:12:52.745-0700|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=14;_ThreadName=Thread-2;|==> writeObject CL: EarClassLoader :
urlSet = [URLEntry : file:/Users/mvatkina/v3/gfs/glassfish3/glassfish/domains/domain1/applications/ejb-bmp-handle-mixApp/ejb-bmp-handle-mix-ejb_jar/, URLEntry : file:/Users/mvatkina/v3/gfs/glassfish3/glassfish/domains/domain1/generated/ejb/ejb-bmp-handle-mixApp/ejb-bmp-handle-mix-ejb_jar]
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@2ef65160

#]

[#|2012-03-27T15:12:53.079-0700|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=14;_ThreadName=Thread-2;|==> readObject CL: EarClassLoader :
urlSet = [URLEntry : file:/Users/mvatkina/v3/gfs/glassfish3/glassfish/domains/domain1/applications/ejb-bmp-handle-mixApp/ejb-bmp-handle-mix-ejb_jar/, URLEntry : file:/Users/mvatkina/v3/gfs/glassfish3/glassfish/domains/domain1/generated/ejb/ejb-bmp-handle-mixApp/ejb-bmp-handle-mix-ejb_jar]
doneCalled = false
Parent -> org.glassfish.internal.api.DelegatingClassLoader@2ef65160

#]

The stack trace:

Caused by: java.lang.ClassNotFoundException: com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.apache.felix.framework.BundleWiringImpl.doImplicitBootDelegation(BundleWiringImpl.java:1666)
at org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1603)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1439)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at org.glassfish.enterprise.iiop.impl.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:115)
at org.glassfish.enterprise.iiop.impl.IIOPHandleDelegate.readEJBHome(IIOPHandleDelegate.java:108)
at com.sun.ejb.portable.HomeHandleImpl.readObject(HomeHandleImpl.java:102)






[GLASSFISH-19948] Verify LC interceptor method signatures Created: 19/Mar/13  Updated: 20/Dec/16

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

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


 Description   

Lifecycle callback interceptor methods defined on an interceptor class must have one of the following signatures:

void <METHOD>(InvocationContext)
Object <METHOD>(InvocationContext) throws Exception






[GLASSFISH-20070] EjbSessionDescriptor.isPassivationCapable should be false by default Created: 27/Mar/13  Updated: 20/Dec/16

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

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


 Description   

It should be set to true for SFSBs






[GLASSFISH-20703] deployment failed with "--name" option Created: 16/Jul/13  Updated: 20/Dec/16

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

Type: Bug Priority: Major
Reporter: xianwu Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)



 Description   

Reproducible operational steps:

1) deployment of j2eesample.ear with name as "j2eesample1" works
asadmin deploy --name j2eesample1 j2eesample.ear

2) deployment of j2eesample.ear with a name as "j2eesample1:1" works
asadmin deploy --name j2eesample1:1 j2eesample.ear

3) deployment of j2eesample.ear with a different name as "j2eesample2" failed
asadmin deploy --name j2eesample2 j2eesample.ear

C:\GF_Feedback>asadmin deploy --name j2eesample2 j2eesample.ear
remote failure: Error occurred during deployment: Exception while loading the app :
EJB Container initialization error. Please see server.log for more details.
Command deploy failed.

Below are loggings from server.log

[2013-07-16T15:42:02.481+1000] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322481] [levelValue: 800] [[
visiting unvisited references]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00036] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
TopLevel AvailabilityService.getAvailabilityEnabled: [true]]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00037] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
TopLevel EjbAvailabilityService.getAvailabilityEnabled: [true]]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00038] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
Global AvailabilityEnabled: [true], application AvailabilityEnabled: [false]]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00040] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
StatefulContainerBuilder AvailabilityEnabled [false] for this application]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00041] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
StatefulContainerBuilder.buildStoreManager() storeName: [CartBean-90043015745306624-BackingStore]]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [] [org.glassfish.ha.store.adapter.file.FileBackingStore] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
[FileBackingStore::initialize] Successfully Created and initialized store. Working dir: C:\glassfish-4.0-b89\glassfish4\glassfish\domains\domain1\session-store\CartBean-90043015745306624; Configuration: BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='CartBean-90043015745306624-BackingStore', shortUniqueName='90043015745306624', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='C:\glassfish-4.0-b89\glassfish4\glassfish\domains\domain1\session-store\CartBean-90043015745306624', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={start.gms=false, async.replication=true, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@f3fac9c, local.caching=true, value.class.is.thread.safe=true, broadcast.remove.expired=false}}]]

[2013-07-16T15:42:02.591+1000] [glassfish 4.0] [INFO] [AS-EJB-00043] [javax.enterprise.ejb.container] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322591] [levelValue: 800] [[
StatefulContainerbuilder instantiated store: org.glassfish.ha.store.adapter.file.FileBackingStore@1d5d3d96, with ha-enabled [false], and backing store configuration: BackingStoreConfiguration{clusterName='null', instanceName='null', storeName='CartBean-90043015745306624-BackingStore', shortUniqueName='90043015745306624', storeType='file', maxIdleTimeInSeconds=-1, relaxVersionCheck='null', maxLoadWaitTimeInSeconds=0, baseDirectoryName='C:\glassfish-4.0-b89\glassfish4\glassfish\domains\domain1\session-store\CartBean-90043015745306624', keyClazz=interface java.io.Serializable, valueClazz=class org.glassfish.ha.store.util.SimpleMetadata, synchronousSave=false, typicalPayloadSizeInKiloBytes=0, vendorSpecificSettings={start.gms=false, async.replication=true, key.transformer=com.sun.ejb.base.sfsb.util.SimpleKeyGenerator@f3fac9c, local.caching=true, value.class.is.thread.safe=true, broadcast.remove.expired=false}}]]

[2013-07-16T15:42:02.606+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322606] [levelValue: 1000] [[
Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
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.GeneratedMethodAccessor289.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:165)
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.lang.RuntimeException: Error while binding JNDI name pkgCartBean.CartBeanHome for EJB CartBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1552)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:385)
at com.sun.ejb.containers.StatefulContainerFactory.createContainer(StatefulContainerFactory.java:489)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
... 59 more
Caused by: javax.naming.NameAlreadyBoundException [Root exception is org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0]
at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:92)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:611)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:636)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:674)
at javax.naming.InitialContext.bind(InitialContext.java:419)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishCosNamingObject(GlassfishNamingManagerImpl.java:230)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:4857)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1539)
... 62 more
Caused by: org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0
at org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper.read(AlreadyBoundHelper.java:60)
at org.omg.CosNaming._NamingContextStub.bind(_NamingContextStub.java:67)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:600)
... 68 more
]]

[2013-07-16T15:42:02.606+1000] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322606] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
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.GeneratedMethodAccessor289.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:165)
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.lang.RuntimeException: Error while binding JNDI name pkgCartBean.CartBeanHome for EJB CartBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1552)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:385)
at com.sun.ejb.containers.StatefulContainerFactory.createContainer(StatefulContainerFactory.java:489)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
... 59 more
Caused by: javax.naming.NameAlreadyBoundException [Root exception is org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0]
at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:92)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:611)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:636)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:674)
at javax.naming.InitialContext.bind(InitialContext.java:419)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishCosNamingObject(GlassfishNamingManagerImpl.java:230)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:4857)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1539)
... 62 more
Caused by: org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0
at org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper.read(AlreadyBoundHelper.java:60)
at org.omg.CosNaming._NamingContextStub.bind(_NamingContextStub.java:67)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:600)
... 68 more
]]

[2013-07-16T15:42:02.606+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322606] [levelValue: 1000] [[
Exception while loading the app]]

[2013-07-16T15:42:02.622+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1373953322622] [levelValue: 1000] [[
Exception while loading the app : EJB Container initialization error
java.lang.RuntimeException: Error while binding JNDI name pkgCartBean.CartBeanHome for EJB CartBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1552)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:385)
at com.sun.ejb.containers.StatefulContainerFactory.createContainer(StatefulContainerFactory.java:489)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
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.GeneratedMethodAccessor289.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:165)
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: javax.naming.NameAlreadyBoundException [Root exception is org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0]
at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:92)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:611)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:636)
at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:674)
at javax.naming.InitialContext.bind(InitialContext.java:419)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishCosNamingObject(GlassfishNamingManagerImpl.java:230)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:4857)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1539)
... 62 more
Caused by: org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0
at org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper.read(AlreadyBoundHelper.java:60)
at org.omg.CosNaming._NamingContextStub.bind(_NamingContextStub.java:67)
at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:600)
... 68 more
]]



 Comments   
Comment by kumara [ 16/Jul/13 ]

AFAIK, this is expected. Deploy with a name of the form <name>:<number> creates a new version of the application that was named <name>. At any one point, only one version is active and therefore there is no conflict in JNDI. However, deploying with another name results in an attempt to load two copies of the application and results in JNDI name conflict leading to deployment failure.

Comment by xianwu [ 16/Jul/13 ]

I have uploaded the sample application at
https://github.com/xianwum/GLASSFISH-20703/blob/master/j2eesample.ear

Comment by xianwu [ 16/Jul/13 ]

Hi Kumara

Thanks for your comments.

Here are two issues.

First, in asadmin deploy manual, the description on "--name" option did not clearly address the format of <name>

--name
Name of the deployable component.

The name can include an optional version identifier, which follows the name and is separated from the name by a colon (. The version identifier must begin with a letter or number. It can contain alphanumeric characters plus underscore (_), dash , and period (.) characters. For more information about module and application versions, see the Module and Application Versions in Oracle GlassFish Server 3.1 Application Deployment Guide.

Second, the error message from asadmin command line below
"remote failure: Error occurred during deployment: Exception while loading the app :
EJB Container initialization error. Please see server.log for more details.
Command deploy failed."

does not tell user what exactly the problem is about.

I think GlassFish team should improve both the manual page and error message this this.

Comment by marina vatkina [ 16/Jul/13 ]

Note that the actual error is covered by https://java.net/jira/browse/GLASSFISH-19036

Comment by xianwu [ 16/Jul/13 ]

Hi Kumara,

I have found that the usage of "--name" option is very confusing.

I have two more samples of deployment with <name>, CartBean.jar and web_ejb_ok.jar. The first failed if the second <name> is different from initial <name> but the second accepts different <name> without error. See details below.

1) Deployment of CartBean.jar (https://github.com/xianwum/GLASSFISH-20703/blob/master/CartBean.jar?raw=true) with a second <name> failed
asadmin deploy --name cart CartBean.jar
Application deployed with name cart.
Command deploy executed successfully.

asadmin deploy --name cart1 CartBean.jar
remote failure: Error occurred during deployment: Exception while loading the app : EJB Container initialization error. Please see server.log for more details.
Command deploy failed.

Here is the server.log
[2013-07-17T09:23:08.565+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=54 _ThreadName=admin-listener(3)] [timeMillis: 1374016988565] [levelValue: 1000] [[
Exception while loading the app : EJB Container initialization error
java.lang.RuntimeException: Error while binding JNDI name pkgCartBean.CartBeanHome for EJB CartBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1552)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:385)
at com.sun.ejb.containers.StatefulContainerFactory.createContainer(StatefulContainerFactory.java:489)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)

2) Deployment of web_ejb_ok.jar (https://github.com/xianwum/GLASSFISH-20703/blob/master/web_ejb_ok.jar?raw=true) with a second <name> is successful

asadmin deploy --name webejb web_ejb_ok.jar
Application deployed with name webejb.
Command deploy executed successfully.

asadmin deploy --name webejb1 web_ejb_ok.jar
Application deployed with name webejb1.
Command deploy executed successfully.

It looks to me that a different <name> is acceptable at certain conditions.

I hope GlassFish team should add descriptions in deploy manual to details of how to use <name>.
In addition, if an invalid <name> is provided, the command line should provide accurate
error messages to tell user what is wrong.

Can you please help to further investigate?

Regards, Xianwu

Comment by Hong Zhang [ 17/Jul/13 ]

xianwu: there is nothing in the server code to prevent a user from deploying the same application bits multiple times with different names as this could be a useful use case for some users. There is really no "invalid" name here as far as the deployment infrastructure is concerned. The users need to make sure these multiple deployments don't cause conflicts if they want to do this kind of multiple deployments. If they cause conflicts, in the case of your example 1), the error message would tell you why they cause conflict, in this case, the JNDI names.

Comment by xianwu [ 17/Jul/13 ]

Hi Hong

I understand the complexity of handling multiple deployments.
What I tried to say is to provide informative error messages from command line if the deployment failed.

See a sample from the deployment of war file.

asadmin deploy --name cart cart.war
Application deployed with name cart.
Command deploy executed successfully.

asadmin deploy --name cart1 cart.war
remote failure: Error occurred during deployment: Exception while loading the app :
java.lang.Exception: Virtual server server already has a web module cart loaded
at /cart therefore web module cart1 cannot be loaded at this context path on
this virtual server. Please see server.log for more details.
Command deploy failed.

Obviously, user will know what is wrong from the errors above.

In case of deployment failure of a jar or ear due to a conflict of JNDI names,
the code should catch the exception and provide errors like "There is a JNDI name conflict...",
instead of simply throwing the exception to the top caller and asking users to check server.log.

Regards, Xianwu

Comment by Hong Zhang [ 17/Jul/13 ]

I see your point. The deployment code is just displaying what's propagated from the container code where the error happens and it's not always easy for the container to propagate the root cause back depending on the involved method stacks (so the error message would always point user to look at the server.log for more details). I will let ejb team take a look to see if it's possible to propagate the JNDI error as part of EJB container initialization error in this case.





[GLASSFISH-20995] Exception in thread "connector-timer-proxy" Created: 27/Feb/14  Updated: 20/Dec/16

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

Type: Bug Priority: Minor
Reporter: labkeeper Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version by asadmin version --verbose is:
Version = GlassFish Server Open Source Edition 4.0 (build 89), JRE version 1.7.0_45

Installation windows, zip, full 4.0 version.

Patched: weld-osgi-bundle-2.0.5-Final.jar because leaking memory in JSF and nucleus-grizzly-all.jar because of compression error.


Tags: 4_0_1-reviewed

 Description   

Scenario:
EJB (Timer) takes connection from pool and executes query. After execution of few queries (each query obtains new connection and releases it after query) got 1 minute timeout and then exception is thrown:

[2014-02-27T17:20:29.953+0100] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=810 _ThreadName=Thread-4] [timeMillis: 1393518029953] [levelValue: 1000] [[
Exception in thread "connector-timer-proxy"]]

[2014-02-27T17:20:29.953+0100] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=810 _ThreadName=Thread-4] [timeMillis: 1393518029953] [levelValue: 1000] [[
java.lang.IllegalArgumentException: can't parse argument number: PoolInfo : (name=java:app/sqltbstelematico)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1420)
at java.text.MessageFormat.applyPattern(MessageFormat.java:479)
at java.text.MessageFormat.<init>(MessageFormat.java:363)
at com.sun.enterprise.util.i18n.StringManagerBase.getStringWithDefault(StringManagerBase.java:205)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.printConnectionLeakTrace(ConnectionLeakDetector.java:180)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.potentialConnectionLeakFound(ConnectionLeakDetector.java:160)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector.access$000(ConnectionLeakDetector.java:63)
at com.sun.enterprise.resource.pool.ConnectionLeakDetector$ConnectionLeakTask.run(ConnectionLeakDetector.java:225)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.NumberFormatException: For input string: " PoolInfo : (name=java:app/sqltbstelematico)"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:481)
at java.lang.Integer.parseInt(Integer.java:527)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1418)
... 9 more]]

Later timer is recreated and scheduled at fixed rate (see attached log).
Later have errors RAR5117 (2 times), RAR5114 (2 times) and after another minute again 4 errors.
After another minute got errors RAR5109, RAR7093, RAR8066 3 times and following queries execution continues.



 Comments   
Comment by labkeeper [ 27/Feb/14 ]

Cannot attach compressed log.





[GLASSFISH-21063] Getting Exception during Junit testing of Ejb Created: 12/May/14  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_dev
Fix Version/s: None

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

Windows 7 64 bit, eclipse 3.2, Junit 4, glassfish3.1.2


Status Whiteboard:

org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.v3.server.ServerContextImpl.env with class caused by NullpointerException


 Description   

org.jvnet.hk2.component.ComponentException: injection failed on com.sun.enterprise.v3.server.ServerContextImpl.env with class org.glassfish.server.ServerEnvironmentImpl
at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:165)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:126)
at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getByContract(Habitat.java:1050)
at com.sun.enterprise.naming.impl.SerialContext.<init>(SerialContext.java:322)
at com.sun.enterprise.naming.impl.SerialContext.<init>(SerialContext.java:334)
at com.sun.enterprise.naming.impl.SerialInitContextFactory.createInitialContext(SerialInitContextFactory.java:358)
at com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:353)
at com.sun.enterprise.naming.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:69)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at com.test.pluginlib.test.UserManagerTest.setUp(UserManagerTest.java:58)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.NullPointerException
at org.glassfish.server.ServerEnvironmentImpl.postConstruct(ServerEnvironmentImpl.java:155)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator$1.run(ConstructorCreator.java:86)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:83)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.jvnet.hk2.component.Habitat.getBy(Habitat.java:1056)
at org.jvnet.hk2.component.Habitat.getByType(Habitat.java:1037)
at com.sun.hk2.component.InjectInjectionResolver.getComponentInjectValue(InjectInjectionResolver.java:159)
at com.sun.hk2.component.InjectInjectionResolver.getValue(InjectInjectionResolver.java:90)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:143)
... 44 more






[GLASSFISH-20731] Application deployed on standalone instance does not initialize database Created: 29/Jul/13  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_dev, 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gray Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish DAS with several standalone instances under control



 Description   

This problem has deep roots. First of all - for some strange reason all resources has domain global definitions. I.e. if I have same application deployed on each, dedicated for customer, standalone instance and I really want each application use it's own database - how should I do that? Since connection pool definition is shared across all instances I either have to alter each application installation and point it to different jdbc resource (create dedicated pools and jdbc resources for all of them, which is tedios) or configure pool using system property references like $

{database.name.system.property}

and provide different values at different instances. Latter approach is OK, but works only for jdbc pools - custom resources would not expand system properties in values and $

{my.custom.resource.value}

will stay like this.
Back to the jdbc pools and deployment issues. Right now, when you deploy application at some standalone instance, initial database initialization happens on DAS. I.e., all tables will be created at database which DAS sees, not at database which instance will see considering mentioned above configuration approach. When application will be actually deployed at standalone instance - no database initialization will happen because this is actually not a "deployment" but "load". This creates obvious problem - database that application will be actually using does not contain proper tables and DAS will actually complain during deployment if database that it sees either inaccessible or already contains all structures (not mentioning the fact that this database MUST exists for no good reason, since DAS itself will never use it).
More to that, issue with database initialization basically breaks Timer Service at each standalone instance! If application use scheduled EJB methods glassfish will try to create Timer Service (by deploing ejb-timer-service-app.war) and since it is happening at instance not at DAS, database for _TimerPool will NOT be initialized which causes "EJBTIMER_TBL table does not exists" exceptions during runtime.
I see not good reason having "load" mode deployment happens at instance level first of all, in my opinion DAS should use "load" and instance "deploy".



 Comments   
Comment by Hong Zhang [ 29/Jul/13 ]

I think all the resources need to be explicitly created on the standalone instances (except for a few system default resources which are now available automatically on all instances in late 4.0 builds), but I will let resource team provide more accurate comments on this.

Comment by gray [ 29/Jul/13 ]

There is no way to "explicitly create resource on the standalone instance". Pool is just pool - you can't specify where it is actually created. Jdbc resource can be assigned to set of instances, but same resource can't point to different pools for different standalone instances, and therefore I still can't use different databases for different instances.
But main issue is actually Timer Service failure - what can you say about that?

Comment by gray [ 31/Jul/13 ]

So, any news on this?

Comment by Jagadish [ 02/Aug/13 ]

There may not be a complete solution, but here is my attempt :

To be able to have customized pool configuration for each instance :
I don't think it's possible (other than the system-property approach you are already aware of), since both application and resources are meant to be uniform (homogeneous) across standalone instances/clusters. This is by design.

An alternate approach I can think of is to use application scoped resources.
a) via GlassFish specific glassfish-resources.xml
or
b) Java EE 7 descriptors which support @DatasourceDefintion, @MailSessionDefinition, @JMSConnectionFactory, @ConnectionFactoryDefinition etc., (@DataSourceDefinition is available from Java EE 6). You can specify these annotation equivalents in the appropriate descriptors (eg: ejb-jar.xml, web.xml, application.xml etc.,)

So, you can deploy multiple copies of same application (by different name) in DAS each using different glassfish-resources.xml (or standard descriptors) and then enable them selectively in standalone instances/clusters.

Comment by gray [ 02/Aug/13 ]

It looks like you have misunderstood the topic
I have resolved problem with making different applications use different databases with system properties - and I'm pretty happy with that. The problem is that database that this application is pointing to does not get initialized with schema structure (i.e. create-tables not happening). This in particular causing TimerService to fail. Timer service war get deployed at standalone instance during first use of the timers in one of the applications. Since I don't want centralized timer service (all my application instances are independent) I did not configure it to use some central database intentionally - i.e. timer service use derby db that is created during startup. When application get deployed on standalone instance it use "load" deployment mode and because of that all "create-table" steps skipped. Timer service will eventually try to make query against this database and fail because EJB_TIMER_TBL does not exists.

Regarding you suggestion for using glassfish-resources.xml and JavaEE 7 - both are unacceptable, because I don't want to have different ear file for each instance, this is actually exactly what I want to avoid first of all.

Regarding "uniform (homogenious) resources" - I can understand why this is true for clusters, but for standalone instances? As I see use case for standalone instances - I use DAS as single point of configuration and each standalone instance is independent application server that generally may have nothing to do with other standalone instances under same DAS. Or am I wrong?

Comment by Jagadish [ 02/Aug/13 ]

OK. This looks like deployment+timer-service related query. I shall transfer this to ejb component.

w.r.t homogeneous resources :
Applications and resources are global in nature, one can enable them in individual targets cluster/standalone instances based on their need. This is by design.
If they were not global (domain wide), what you are suggesting would have been feasible.

Comment by gray [ 02/Aug/13 ]

I understood that this is "by design" - I just don't understand why this is designed like this. What is the use case?

And by the way - I really doubt that this issue have anything to do with jdbc (may be JPA), since table creation step get completely skipped because of that code:

package org.glassfish.ejb.persistent.timer;
...
public class PersistentEJBTimerService extends EJBTimerService {
...
    private static boolean deployEJBTimerService(File root, File appScratchFile, 
            String resourceName, boolean is_upgrade) {
...
                if (_ejbContainerUtil.isDas() && appScratchFile.createNewFile() && !is_upgrade) {
                    params.origin = OpsParams.Origin.deploy; // this is for DAS
                } else {
                    params.origin = OpsParams.Origin.load; // this is for instance/cluster
                }
...

Note that if we are currently not at DAS origin will be set to "load".
And later JPADeployer:

package org.glassfish.persistence.jpa;
...
public class JPADeployer extends SimpleDeployer<JPAContainer, JPApplicationContainer> implements PostConstruct, EventListener {
...
    private void iterateInitializedPUsAtApplicationPrepare(final DeploymentContext context) {
...
        PersistenceUnitDescriptorIterator pudIterator = new PersistenceUnitDescriptorIterator() {
            @Override void visitPUD(PersistenceUnitDescriptor pud, DeploymentContext context) {
...
                    if(isDas()) { //We do validation and execute Java2DB only on DAS
                        if(deployCommandParameters.origin.isDeploy()) { //APPLICATION_PREPARED will be called for create-application-ref also. We should perform java2db only on first deploy
...

In case of Timer Service application on standalone instance it is obvious that "isDaS()" is false along with "origin.isDeploy()" and no database initialization happen.

Comment by marina vatkina [ 03/Aug/13 ]

This is per design - the Timer Service on DAS sometimes needs to precreate the timers and it can't support more than one database at this time. So changing to an RFE.

Until then you can create the tables manually - the DLL is available under glassfish3/glassfish/lib/install/databases or glassfish4/glassfish/lib/install/databases





[GLASSFISH-18330] Unhelpful INFO log messages Created: 07/Feb/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This was reported to me by Abhijit:

The following log messages are completely useless to the user and should be debug:

[#|2012-01-31T08:20:02.703-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=15;_ThreadName=Thread-9;|TopLevel AvailabilityService.getAvailabilityEnabled => true|#]

[#|2012-01-31T08:20:02.704-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=15;_ThreadName=Thread-9;|TopLevel EjbAvailabilityService.getAvailabilityEnabled => true|#]

[#|2012-01-31T08:20:02.705-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=15;_ThreadName=Thread-9;|**Global AvailabilityEnabled => true; isAppHAEnabled: false|#]

[#|2012-01-31T08:20:02.706-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=15;_ThreadName=Thread-9;|StatefulContainerBuilder AvailabilityEnabled for this app => false|#]

[#|2012-01-31T08:20:02.707-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers.builder|_ThreadID=15;_ThreadName=Thread-9;|StatefulContainerBuilder.buildStoreManager() storeName: com_sun_ts_tests_common_vehicle_ejb_EJBVehicle-87033560788828160-BackingStore|#]






[GLASSFISH-18885] Created timer sometimes won't pass to scheduled state (with jdk 1.7.0_04) Created: 11/Jul/12  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rik72 Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS release 6.3 (Final) - kernel 2.6.32-279.el6.x86_64 - jdk1.7.0_04


Attachments: File jstacks.tgz     Zip Archive TimerTest.zip     Zip Archive TimerTestApp.zip    
Tags: ejb-container, timers

 Description   

The attached application (Netbeans project) registers a timer that on delivery triggers a task creating a new timer. A J2EE5 trick to implement a periodic task.
The problem we have is that after a few iterations (10 - 15 approximately) the mechanism stops: the last timer - in a 'created' state - is never seen in logs to pass from 'created' to 'SCHEDULED', 'BEING DELIVERED' and so on, and the associated task is not triggered any more.
Problem showed up in a (newly created) 1.7 environment specified above. Timer pool javadb settings were factory defaults.
We develop the minimal application in order to replicate the problem in a more simple context, and we found that the attached app is faulty on the 1.7 env, while it's ok in two different 1.6 environments we tested:

  • GF 3.1.1 with jdk 1.6.0_22 on Linux
  • GF 3.1.2 with openjdk 1.6.0_24 (OpenJDK Runtime Environment - IcedTea6 1.11.3) on Linux (that was the "fix" we chose for our system)
  • GF 3.1.2 with jdk 1.6.0_31 on Mac OS X


 Comments   
Comment by marina vatkina [ 11/Jul/12 ]

Can you run a pure Java test on JDK 7 that creates a TimerTask and a Timer and follows your pattern in create/cancel sequence?

Comment by rik72 [ 12/Jul/12 ]

Hi,
I created a Java application with the same pattern I used in the EJB example, please find it attached.
It seems to run without any issue on my JDK 7 box.

Comment by marina vatkina [ 12/Jul/12 ]

Does taskCommand.getSleepSecsBefore() work the same in your app and in the TimerTask test? What is the logged value before the timers stop working (which is kind of strange because we use JDK timers to do the timeouts)?

Comment by rik72 [ 13/Jul/12 ]

Does taskCommand.getSleepSecsBefore() work the same in your app and in the TimerTask test?

TimerTaskCommand class is identical in the two examples. As a matter of fact in order to obtain the pure Java project I took the ejb project and eliminated any reference to javax components. So I had to introduce some code in order to use the java.util.TimerTask instead of TimerService callback mechanism.
Just to be sure that everything is clear: I assume that what you are referring to as "my app" is the TimerTest.zip (EJB-based) and the "TimerTask test" is TimerTestApp.zip (pure Java), right?

What is the logged value before the timers stop working (which is kind of strange because we use JDK timers to do the timeouts)?

...on the basis of the information you extract from the timers db, I suppose. That's really strange indeed.

This is an extract of logs in a run of my app under the 1.7 box: we face stopping timers. Last logged events are:

  • creation of the last timer (never delivered)
  • canceling of the last good (delivered) timer

===
last "good" timer creation (37420)
===

[#|2012-07-10T09:27:04.135+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=createTimer;|@@@ Created timer [37420@@1341826826858@@server@@domain1] with the first expiration set to: Tue Jul 10 09:27:14 CEST 2012|#]

[#|2012-07-10T09:27:04.135+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=<init>;|RuntimeTimerState 37420@@1341826826858@@server@@domain1 created|#]

[#|2012-07-10T09:27:04.135+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerCache;MethodName=addTimer;|Adding timer '37420@@1341826826858@@server@@domain1' 'TimedObject = GameSrvTimerSvcEjb' 'Application = GameSrv' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87937962312466439' 'Tue Jul 10 09:27:14 CEST 2012' '0' |#]

[#|2012-07-10T09:27:04.137+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.TimerBean;MethodName=createTimer;|TimerBean.createTimer() ::timerId=37420@@1341826826858@@server@@domain1 ::containerId=87937962312466439 ::applicationId=87937962312466432 ::timedObjectPK=null ::info=TimerTaskCommand [taskExecutorClass=class it.sinapto.tas.gamesrv.timers.GameSrvCacheSweeperTask, payload=null, sleepSecsBefore=10] ::schedule=null ::persistent=true ::initialExpiration=Tue Jul 10 09:27:14 CEST 2012 ::intervalDuration=0 :::state=TIMER_ACTIVE :::creationTime=Tue Jul 10 09:27:04 CEST 2012 :::ownerId=server|#]

[#|2012-07-10T09:27:04.145+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=scheduleTask;|Scheduling '37420@@1341826826858@@server@@domain1' 'TimedObject = GameSrvTimerSvcEjb' 'Application = GameSrv' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87937962312466439' 'Tue Jul 10 09:27:14 CEST 2012' '0' for timeout at Tue Jul 10 09:27:14 CEST 2012|#]

[#|2012-07-10T09:27:04.146+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=598;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|37420@@1341826826858@@server@@domain1: CREATED to SCHEDULED|#]

===
10 seconds pass, this timer is delivered...
===

[#|2012-07-10T09:27:14.135+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=92;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|37420@@1341826826858@@server@@domain1: SCHEDULED to BEING_DELIVERED|#]

[#|2012-07-10T09:27:14.135+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=92;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=taskExpired;|Adding work pool task for timer 37420@@1341826826858@@server@@domain1|#]

[#|2012-07-10T09:27:14.136+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=deliverTimeout;|EJBTimerService.deliverTimeout(): work thread is processing work for timerId = 37420@@1341826826858@@server@@domain1|#]

[#|2012-07-10T09:27:14.136+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=deliverTimeout;|Calling ejbTimeout for timer '37420@@1341826826858@@server@@domain1' 'TimedObject = GameSrvTimerSvcEjb' 'Application = GameSrv' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 87937962312466439' 'Tue Jul 10 09:27:14 CEST 2012' '0' |#]

===
... and a new one is created (37421)
===

[#|2012-07-10T09:27:14.141+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=createTimer;|@@@ Created timer [37421@@1341826826858@@server@@domain1] with the first expiration set to: Tue Jul 10 09:27:24 CEST 2012|#]

[#|2012-07-10T09:27:14.141+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=<init>;|RuntimeTimerState 37421@@1341826826858@@server@@domain1 created|#]

[#|2012-07-10T09:27:14.141+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerCache;MethodName=addTimer;|Adding timer '37421@@1341826826858@@server@@domain1' 'TimedObject = GameSrvTimerSvcEjb' 'Application = GameSrv' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87937962312466439' 'Tue Jul 10 09:27:24 CEST 2012' '0' |#]

===
canceling the last good timer (37420)
===

[#|2012-07-10T09:27:14.148+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=getValidTimerFromDB;|The Timer :37420@@1341826826858@@server@@domain1: is a valid timer for the server (server)|#]

[#|2012-07-10T09:27:14.148+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=postEjbTimeout;|Single-action timer '37420@@1341826826858@@server@@domain1' 'TimedObject = GameSrvTimerSvcEjb' 'Application = GameSrv' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 87937962312466439' 'Tue Jul 10 09:27:14 CEST 2012' '0' was successfully delivered. Removing...|#]

[#|2012-07-10T09:27:14.149+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|37420@@1341826826858@@server@@domain1: BEING_DELIVERED to CANCELLED|#]

[#|2012-07-10T09:27:14.152+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=589;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerSynch;MethodName=afterCompletion;|TimerSynch::afterCompletion. timer state = TIMER_CANCELLED , timer id = 37420@@1341826826858@@server@@domain1 , JTA TX status = TX_STATUS_COMMITTED , timeout = null|#]

===
... and the new one??? No further logs on 37421...
===

Comment by rik72 [ 13/Jul/12 ]

Well, bad news (or good news, don't know).
Now (quite suddenly) even with openjdk 1.6 the app stops delivering timers.

I include extended logs of the final phase. Same pattern: the last timer is delivered (59992), a new one is created (59993) that is never delivered. More exactly the new one never pass from created to SCHEDULED.
After the block, you can see the timer pool shrink.

Can it be a bad usage pattern in my app?

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

[#|2012-07-13T05:42:25.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=createTimer;|@@@ Created timer [59992@@1342086956656@@server@@domain1] with the first expiration set to: Fri Jul 13 05:42:27 CEST 2012|#]

[#|2012-07-13T05:42:25.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=<init>;|RuntimeTimerState 59992@@1342086956656@@server@@domain1 created|#]

[#|2012-07-13T05:42:25.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerCache;MethodName=addTimer;|Adding timer '59992@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:27 CEST 2012' '0' |#]

[#|2012-07-13T05:42:25.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.createTimer(java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig) throws javax.ejb.CreateException,ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.303+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = createTimer,Local,java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig (Caller) = null|#]

[#|2012-07-13T05:42:25.303+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = TimerTest/TimerTest-ejb_jar newV = ejb-timer-service-app/ejb-timer-service-app_internal|#]

[#|2012-07-13T05:42:25.303+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.TimerBean;MethodName=createTimer;|TimerBean.createTimer() ::timerId=59992@@1342086956656@@server@@domain1 ::containerId=87955009790541824 ::applicationId=87955009790541824 ::timedObjectPK=null ::info=TimerTaskCommand [taskExecutorClass=class common.timer.TimerTestTask, payload=null, sleepSecsBefore=2] ::schedule=null ::persistent=true ::initialExpiration=Fri Jul 13 05:42:27 CEST 2012 ::intervalDuration=0 :::state=TIMER_ACTIVE :::creationTime=Fri Jul 13 05:42:25 CEST 2012 :::ownerId=server|#]

[#|2012-07-13T05:42:25.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = ejb-timer-service-app/ejb-timer-service-app_internal newV = TimerTest/TimerTest-ejb_jar|#]

[#|2012-07-13T05:42:25.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.createTimer(java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig) throws javax.ejb.CreateException,ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = TimerTest/TimerTest-ejb_jar newV = ejb-timer-service-app/ejb-timer-service-app_internal|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = findTimer,Local,com.sun.ejb.containers.TimerPrimaryKey (Caller) = null|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=getValidTimerFromDB;|The Timer :59991@@1342086956656@@server@@domain1: is a valid timer for the server (server)|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=postEjbTimeout;|Single-action timer '59991@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:25 CEST 2012' '0' was successfully delivered. Removing...|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract void com.sun.ejb.containers.TimerLocal.cancel(com.sun.ejb.containers.TimerPrimaryKey) throws java.lang.Exception,ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=137;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = cancel,Local,com.sun.ejb.containers.TimerPrimaryKey (Caller) = null|#]

[#|2012-07-13T05:42:25.306+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|59991@@1342086956656@@server@@domain1: BEING_DELIVERED to CANCELLED|#]

[#|2012-07-13T05:42:25.306+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract void com.sun.ejb.containers.TimerLocal.cancel(com.sun.ejb.containers.TimerPrimaryKey) throws java.lang.Exception,ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerSynch;MethodName=afterCompletion;|TimerSynch::afterCompletion. timer state = TIMER_CANCELLED , timer id = 59991@@1342086956656@@server@@domain1 , JTA TX status = TX_STATUS_COMMITTED , timeout = null|#]

[#|2012-07-13T05:42:25.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerCache;MethodName=removeTimer;|Removing timer 59991@@1342086956656@@server@@domain1|#]

[#|2012-07-13T05:42:25.311+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerSynch;MethodName=afterCompletion;|TimerSynch::afterCompletion. timer state = TIMER_ACTIVE , timer id = 59992@@1342086956656@@server@@domain1 , JTA TX status = TX_STATUS_COMMITTED , timeout = Fri Jul 13 05:42:27 CEST 2012|#]

[#|2012-07-13T05:42:25.311+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=scheduleTask;|Scheduling '59992@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:27 CEST 2012' '0' for timeout at Fri Jul 13 05:42:27 CEST 2012|#]

[#|2012-07-13T05:42:25.311+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|59992@@1342086956656@@server@@domain1: CREATED to SCHEDULED|#]

[#|2012-07-13T05:42:25.312+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=TimerTest_TimerTest-ejb.jar_TimerSvcEjb_ejb.TimerSvcEjb87955009790541824,isLocal=false,isRemote=false,isBusinessInterface=false,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=null,method=public void test.timer.ejb.TimerSvcBean.onTaskTimer(javax.ejb.Timer),ejb=test.timer.ejb.TimerSvcBean@5ab476b9,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:25.312+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=137;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=deliverTimeout;|Timer no longer exists for 59991@@1342086956656@@server@@domain1 after callEJBTimeout|#]

[#|2012-07-13T05:42:27.301+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|59992@@1342086956656@@server@@domain1: SCHEDULED to BEING_DELIVERED|#]

[#|2012-07-13T05:42:27.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=taskExpired;|Adding work pool task for timer 59992@@1342086956656@@server@@domain1|#]

[#|2012-07-13T05:42:27.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=deliverTimeout;|EJBTimerService.deliverTimeout(): work thread is processing work for timerId = 59992@@1342086956656@@server@@domain1|#]

[#|2012-07-13T05:42:27.302+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=deliverTimeout;|Calling ejbTimeout for timer '59992@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:27 CEST 2012' '0' |#]

[#|2012-07-13T05:42:27.303+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=TimerTest_TimerTest-ejb.jar_TimerSvcEjb_ejb.TimerSvcEjb87955009790541824,isLocal=false,isRemote=false,isBusinessInterface=false,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=null,method=public void test.timer.ejb.TimerSvcBean.onTaskTimer(javax.ejb.Timer),ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.303+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = ejb-timer-service-app/ejb-timer-service-app_internal newV = TimerTest/TimerTest-ejb_jar|#]

[#|2012-07-13T05:42:27.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = findTimer,Local,com.sun.ejb.containers.TimerPrimaryKey (Caller) = null|#]

[#|2012-07-13T05:42:27.304+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = TimerTest/TimerTest-ejb_jar newV = ejb-timer-service-app/ejb-timer-service-app_internal|#]

[#|2012-07-13T05:42:27.305+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = ejb-timer-service-app/ejb-timer-service-app_internal newV = TimerTest/TimerTest-ejb_jar|#]

[#|2012-07-13T05:42:27.306+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.306+0200|INFO|glassfish3.1.2|TimerSvc|_ThreadID=138;_ThreadName=Thread-2;|TimerTaskCommand scheduled execution : TimerTaskCommand [taskExecutorClass=class common.timer.TimerTestTask, payload=null, sleepSecsBefore=2]|#]

[#|2012-07-13T05:42:27.306+0200|INFO|glassfish3.1.2|common.timer|_ThreadID=138;_ThreadName=Thread-2;| * TIMER TEST TASK * |#]

[#|2012-07-13T05:42:27.306+0200|INFO|glassfish3.1.2|TimerSvc|_ThreadID=138;_ThreadName=Thread-2;|Task re-scheduling : TimerTaskCommand [taskExecutorClass=class common.timer.TimerTestTask, payload=null, sleepSecsBefore=2]|#]

[#|2012-07-13T05:42:27.307+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=createTimer;|@@@ Created timer [59993@@1342086956656@@server@@domain1] with the first expiration set to: Fri Jul 13 05:42:29 CEST 2012|#]

[#|2012-07-13T05:42:27.307+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=<init>;|RuntimeTimerState 59993@@1342086956656@@server@@domain1 created|#]

[#|2012-07-13T05:42:27.307+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService$TimerCache;MethodName=addTimer;|Adding timer '59993@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'CREATED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:29 CEST 2012' '0' |#]

[#|2012-07-13T05:42:27.307+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.createTimer(java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig) throws javax.ejb.CreateException,ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.307+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = createTimer,Local,java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig (Caller) = null|#]

[#|2012-07-13T05:42:27.308+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = TimerTest/TimerTest-ejb_jar newV = ejb-timer-service-app/ejb-timer-service-app_internal|#]

[#|2012-07-13T05:42:27.308+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.TimerBean;MethodName=createTimer;|TimerBean.createTimer() ::timerId=59993@@1342086956656@@server@@domain1 ::containerId=87955009790541824 ::applicationId=87955009790541824 ::timedObjectPK=null ::info=TimerTaskCommand [taskExecutorClass=class common.timer.TimerTestTask, payload=null, sleepSecsBefore=2] ::schedule=null ::persistent=true ::initialExpiration=Fri Jul 13 05:42:29 CEST 2012 ::intervalDuration=0 :::state=TIMER_ACTIVE :::creationTime=Fri Jul 13 05:42:27 CEST 2012 :::ownerId=server|#]

[#|2012-07-13T05:42:27.308+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = ejb-timer-service-app/ejb-timer-service-app_internal newV = TimerTest/TimerTest-ejb_jar|#]

[#|2012-07-13T05:42:27.308+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.createTimer(java.lang.String,long,long,java.lang.String,java.lang.Object,java.util.Date,long,com.sun.ejb.containers.TimerSchedule,javax.ejb.TimerConfig) throws javax.ejb.CreateException,ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=resetPolicyContext;|JACC: Changing Policy Context ID: oldV = TimerTest/TimerTest-ejb_jar newV = ejb-timer-service-app/ejb-timer-service-app_internal|#]

[#|2012-07-13T05:42:27.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = findTimer,Local,com.sun.ejb.containers.TimerPrimaryKey (Caller) = null|#]

[#|2012-07-13T05:42:27.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract com.sun.ejb.containers.TimerState com.sun.ejb.containers.TimerLocal.findTimer(com.sun.ejb.containers.TimerPrimaryKey),ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=getValidTimerFromDB;|The Timer :59992@@1342086956656@@server@@domain1: is a valid timer for the server (server)|#]

[#|2012-07-13T05:42:27.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.EJBTimerService;MethodName=postEjbTimeout;|Single-action timer '59992@@1342086956656@@server@@domain1' 'TimedObject = TimerSvcEjb' 'Application = TimerTest' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 87955009790541824' 'Fri Jul 13 05:42:27 CEST 2012' '0' was successfully delivered. Removing...|#]

[#|2012-07-13T05:42:27.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=preInvoke;|Entering BaseContainer::preInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract void com.sun.ejb.containers.TimerLocal.cancel(com.sun.ejb.containers.TimerPrimaryKey) throws java.lang.Exception,ejb=null,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.org.glassfish.ejb.security.application|_ThreadID=138;_ThreadName=Thread-2;ClassName=org.glassfish.ejb.security.application.EJBSecurityManager;MethodName=authorize;|JACC: Access Control Decision Result: true EJBMethodPermission (Name) = TimerBean (Action) = cancel,Local,com.sun.ejb.containers.TimerPrimaryKey (Caller) = null|#]

[#|2012-07-13T05:42:27.310+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.RuntimeTimerState;MethodName=printStateTransition;|59992@@1342086956656@@server@@domain1: BEING_DELIVERED to CANCELLED|#]

[#|2012-07-13T05:42:27.310+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=ejb-timer-service-app_/ejb-timer-service-app,isLocal=true,isRemote=false,isBusinessInterface=true,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=interface com.sun.ejb.containers.TimerLocal,method=public abstract void com.sun.ejb.containers.TimerLocal.cancel(com.sun.ejb.containers.TimerPrimaryKey) throws java.lang.Exception,ejb=com.sun.ejb.containers.TimerBean@651bf11f,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:42:27.311+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=138;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.BaseContainer;MethodName=postInvoke;|Leaving BaseContainer::postInvoke : EjbInvocation componentId=TimerTest_TimerTest-ejb.jar_TimerSvcEjb_ejb.TimerSvcEjb87955009790541824,isLocal=false,isRemote=false,isBusinessInterface=false,isWebService=false,isMessageDriven=false,isHome=false,clientInterface=null,method=public void test.timer.ejb.TimerSvcBean.onTaskTimer(javax.ejb.Timer),ejb=test.timer.ejb.TimerSvcBean@5ab476b9,exception=null,exceptionFromBeanMethod=null,invId=0,wasCancelCalled=false,yetToSubmitStatus=true|#]

[#|2012-07-13T05:45:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=172;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize started at: Fri Jul 13 05:45:53 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T05:45:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=172;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize:: reducing pool size by: 2|#]

[#|2012-07-13T05:45:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=172;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize completed at: Fri Jul 13 05:45:53 CEST 2012; after reSize: [Pool-TimerBean] CC=11; DC=9; CS=2; SS=0; MS=32;|#]

[#|2012-07-13T05:45:53.644+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=172;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize took: 0.0 seconds.|#]

[#|2012-07-13T05:51:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=177;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize started at: Fri Jul 13 05:51:39 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T05:51:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=177;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize:: reducing pool size by: 2|#]

[#|2012-07-13T05:51:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=177;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize completed at: Fri Jul 13 05:51:39 CEST 2012; after reSize: [Pool-TimerSvcEjb] CC=2; DC=0; CS=2; SS=0; MS=32;|#]

[#|2012-07-13T05:51:39.584+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=177;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize took: 0.0 seconds.|#]

[#|2012-07-13T05:55:53.642+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=173;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize started at: Fri Jul 13 05:55:53 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T05:55:53.642+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=173;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize:: reducing pool size by: 2|#]

[#|2012-07-13T05:55:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=173;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize completed at: Fri Jul 13 05:55:53 CEST 2012; after reSize: [Pool-TimerBean] CC=11; DC=11; CS=0; SS=0; MS=32;|#]

[#|2012-07-13T05:55:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=173;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize took: 0.001 seconds.|#]

[#|2012-07-13T06:01:39.582+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=169;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize started at: Fri Jul 13 06:01:39 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T06:01:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=169;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize:: reducing pool size by: 2|#]

[#|2012-07-13T06:01:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=169;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize completed at: Fri Jul 13 06:01:39 CEST 2012; after reSize: [Pool-TimerSvcEjb] CC=2; DC=2; CS=0; SS=0; MS=32;|#]

[#|2012-07-13T06:01:39.584+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=169;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize took: 0.0 seconds.|#]

[#|2012-07-13T06:05:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=171;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize started at: Fri Jul 13 06:05:53 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T06:05:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=171;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize completed at: Fri Jul 13 06:05:53 CEST 2012; after reSize: [Pool-TimerBean] CC=11; DC=11; CS=0; SS=0; MS=32;|#]

[#|2012-07-13T06:05:53.643+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=171;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerBean]: Resize took: 0.0 seconds.|#]

[#|2012-07-13T06:11:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=170;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize started at: Fri Jul 13 06:11:39 CEST 2012 steadyPoolSize ::0 resizeQuantity ::8 maxPoolSize ::32|#]

[#|2012-07-13T06:11:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=170;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize completed at: Fri Jul 13 06:11:39 CEST 2012; after reSize: [Pool-TimerSvcEjb] CC=2; DC=2; CS=0; SS=0; MS=32;|#]

[#|2012-07-13T06:11:39.583+0200|FINE|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=170;_ThreadName=Thread-2;ClassName=com.sun.ejb.containers.util.pool.NonBlockingPool;MethodName=doResize;|[Pool-TimerSvcEjb]: Resize took: 0.0 seconds.|#]

Comment by marina vatkina [ 13/Jul/12 ]

The fact that you can reproduce it on 1.6 is a good news.

Now let's try this:

  • stop the server. Un-jar the glassfish3/glassfish//lib/install/applications/ejb-timer-service-app.war and update its WEB-INF/classes/META-INF/persistence.xml to have FINE log level for EclipseLink. Jar it back and restart the server - that will show the db operations;
  • instead if the ejb-container, change 'jta' and 'transaction' logging level to FINE - let's see if the last transaction is rolled back.
Comment by rik72 [ 13/Jul/12 ]

I redeployed the app with your changes applied on GF.
After a few hours of working OK it reverted to a problematic state.
Now it stops regularly after a few iterations.

I've not seen rollbacks, but the last - blocking - iteration shows a sudden stop in the operations, right before the commit phase:

[#|2012-07-13T14:28:49.952+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionImpl;MethodName=commit;|--In JavaEETransactionImpl.commit, jtsTx=null nonXAResource=null|#]

[#|2012-07-13T14:28:49.953+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getStatus;|TM: status: Active|#]

[#|2012-07-13T14:28:49.953+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getStatus;|TM: status: Active|#]

LAST ITERATION STOPS HERE

[#|2012-07-13T14:28:49.953+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=JavaEETransactionImpl: txId=44431 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@35869796, org.eclipse.persistence.transaction.JTASynchronizationListener@174a144e], tm=com.sun.jts.jta.TransactionManagerImpl@299430f6|#]

[#|2012-07-13T14:28:49.954+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=JavaEETransactionImpl: txId=44431 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@35869796, org.eclipse.persistence.transaction.JTASynchronizationListener@174a144e], tm=com.sun.jts.jta.TransactionManagerImpl@299430f6|#]

[#|2012-07-13T14:28:49.954+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionManagerSimplified;MethodName=enlistResource;|

In JavaEETransactionManagerSimplified.enlistResource, h=667 h.xares=com.sun.gjc.spi.XAResourceImpl@4da5138c tx=JavaEETransactionImpl: txId=44431 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@35869796, org.eclipse.persistence.transaction.JTASynchronizationListener@174a144e]|#]

[#|2012-07-13T14:28:49.954+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=setTransactionManager;|TM: setTransactionManager: tm=com.sun.jts.jta.TransactionManagerImpl@299430f6|#]

[#|2012-07-13T14:28:49.954+0200|FINE|glassfish3.1.2|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=91;_ThreadName=Thread-2;ClassName=TransactionFactoryImpl;MethodName=localCreate();|Control object :com.sun.jts.CosTransactions.ControlImpl@387ac601 corresponding to this transaction has been createdGTID is : 58AD0000BF211E7F6D756E63686965732D67616D6573727630312E696E7472616E65742C7365727665722C5033373030|#]

[#|2012-07-13T14:28:49.955+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionManagerSimplified;MethodName=enlistXAResource;|TM: enlistResource|#]

[#|2012-07-13T14:28:49.955+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionImpl;MethodName=enlistResource;|--In JavaEETransactionImpl.enlistResource, jtsTx=com.sun.jts.jta.TransactionImpl@52cd9150 nonXAResource=null|#]

[#|2012-07-13T14:28:49.955+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionImpl;MethodName=registerSynchronization;|--In JavaEETransactionImpl.registerSynchronization, jtsTx=com.sun.jts.jta.TransactionImpl@52cd9150 nonXAResource=null|#]

[#|2012-07-13T14:28:49.956+0200|FINE|glassfish3.1.2|org.eclipse.persistence.session.file:/dati/ogp/glassfish3/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.sql|ThreadID=91;_ThreadName=Thread-2;ClassName=null;MethodName=null;|UPDATE "EJBTIMER_TBL" SET "STATE" = ? WHERE ("TIMERID" = ?)
bind => [2 parameters bound]|#]

[#|2012-07-13T14:28:49.956+0200|FINE|glassfish3.1.2|org.eclipse.persistence.session.file:/dati/ogp/glassfish3/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.sql|ThreadID=91;_ThreadName=Thread-2;ClassName=null;MethodName=null;|INSERT INTO "EJBTIMER_TBL" ("TIMERID", "APPLICATIONID", "BLOB", "CONTAINERID", "CREATIONTIMERAW", "INITIALEXPIRATIONRAW", "INTERVALDURATION", "LASTEXPIRATIONRAW", "OWNERID", "PKHASHCODE", "SCHEDULE", "STATE") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
bind => [12 parameters bound]|#]

[#|2012-07-13T14:28:49.957+0200|FINE|glassfish3.1.2|org.eclipse.persistence.session.file:/dati/ogp/glassfish3/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.sql|ThreadID=91;_ThreadName=Thread-2;ClassName=null;MethodName=null;|DELETE FROM "EJBTIMER_TBL" WHERE ("TIMERID" = ?)
bind => [1 parameter bound]|#]

[#|2012-07-13T14:28:49.958+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=JavaEETransactionImpl: txId=44431 nonXAResource=null jtsTx=com.sun.jts.jta.TransactionImpl@52cd9150 localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@35869796, org.eclipse.persistence.transaction.JTASynchronizationListener@174a144e], tm=com.sun.jts.jta.TransactionManagerImpl@299430f6|#]

[#|2012-07-13T14:28:49.958+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.JavaEETransactionManagerSimplified;MethodName=delistJTSResource;|TM: delistResource|#]

[#|2012-07-13T14:28:49.960+0200|FINE|glassfish3.1.2|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=91;_ThreadName=Thread-2;ClassName=com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate;MethodName=getTransaction;|TM: getTransaction: tx=null, tm=com.sun.jts.jta.TransactionManagerImpl@299430f6|#]

Comment by marina vatkina [ 13/Jul/12 ]

May be there is a deadlock? What does the thread dump say?

Comment by rik72 [ 14/Jul/12 ]

I used jstack right after the block and found no deadlock.

Comment by marina vatkina [ 17/Jul/12 ]

That's strange. Can you attach it anyway?

Please also enable 'transaction' FINE logging to see what the XA code is doing.

Comment by rik72 [ 17/Jul/12 ]

I've attached two jstack dumps obtained after a block, with different jdk environments:

  • jstack_long_1.log => 1.7.0_04
  • jstack_long_2.log => 1.6.0_25 (a 1.6 jdk I didn't mention before since I tried it in these last days)
Comment by rik72 [ 18/Jul/12 ]

Hello,
since I don't think many others are having the same issues with timers I think there must be some subtle problem with my timer usage pattern.
This problem MUST be subtle, since the application at times works ok for hours or even a few days before showing the block.
What would you suggest looking for in order to find a workaround? Maybe the @Schedule annotation? What I fear is that low level implementation would be the same, since you told me that java.util timers are used in the end...

Comment by marina vatkina [ 18/Jul/12 ]

Did you try to see if transaction was committed after the last removed/added call?

What are you trying to achieve by the pattern that you are using? If there are no difference between the timers, will a plain interval timer be a simpler solution?

Comment by rik72 [ 18/Jul/12 ]

Did you try to see if transaction was committed after the last removed/added call?

Excuse me, I forgot to answer you again on this: I had already brought "transaction" to FINE, look for my post @ 13/Jul/12 01:57 PM.

What are you trying to achieve by the pattern that you are using? If there are no difference between the timers, will a plain interval timer be a simpler solution?

I am simply trying to achieve the periodic execution of tasks... at each @Timeout call I simply create a new timer in order to trigger the same call next time. This is achieved with some structure, but that should be only for the sake of generality in my application framework. As simple as that, is it not a plain interval timer?
I will try to build an even simpler example, in order to test its behaviour on my box.

Comment by marina vatkina [ 18/Jul/12 ]

Can you try to store the timers in a different database?

Comment by rik72 [ 19/Jul/12 ]

I moved the timer table to a mysql instance. Let's see.
Thank you very much.

Comment by rik72 [ 20/Jul/12 ]

Same.

Comment by marina vatkina [ 20/Jul/12 ]

weird





[GLASSFISH-17010] [JMX] Multiple [2] JMX MBeanServer instances exist Created: 11/Jul/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: amx, ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ancoron Assignee: prasads
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On a 3.1.1 promoted build I currently get those warnings when the EJBTimer application is starting up:

WARNING: Multiple [2] JMX MBeanServer instances exist, we will use the server at index [0] : [com.sun.enterprise.v3.admin.DynamicInterceptor@43c0ae76].
WARNING: JMX MBeanServer in use: [com.sun.enterprise.v3.admin.DynamicInterceptor@43c0ae76] from index [0] 
WARNING: JMX MBeanServer in use: [com.sun.jmx.mbeanserver.JmxMBeanServer@bbe5d86] from index [1]

It doesn't seem to affect functionality. Therefore lower priority.



 Comments   
Comment by alan94539 [ 14/Aug/11 ]

I agree it is minor, but is there a workaround to make this stop coming up? I suspect there is a configuration parameter somewhere to set which MBeanServer to use but I can't find it.

Comment by anlog [ 29/Sep/11 ]

I have found a workaround to continue: I get the ResultList size before get the element list.

int it = emf.createEntityManager().createNamedQuery("User.findAll").getResultList().size();
String users = "";
for( int i=0; i<it; i++)

{ User user = (User)emf.createEntityManager().createNamedQuery("User.findAll").getResultList().get(i); users += "id: " + user.getId() + " - "; users += "username: " + user.getUsername() + " - "; users += "<br>"; }




[GLASSFISH-17385] asadmin stop-domain does not end cleanly for MDB's Created: 06/Oct/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: tchng Assignee: marina vatkina
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File facelet.jar    
Tags: 3_1_x-exclude

 Description   

When trying to shut down glassfish using the command:

asadmin stop-domain --force=false

Looking at our logs, our Message Driven Beans will throw the following error when trying to finish processing by retrieving the messages that have been placed on the queue:

onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1995) [ejb-container.jar:3.1.1]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990) [ejb-container.jar:3.1.1]

When stopping our domain, we are unable to finish processing gracefully if this exception occurs.

Please advise.

Thanks!



 Comments   
Comment by tchng [ 06/Oct/11 ]

The feature we are looking for is:

"shutdown when work completes"

Comment by tchng [ 11/Oct/11 ]

This exception behavior still happens in Glassfish version 3.2-b06
15:20:17.360 [30b96561-d0d5-4cd8-a36d-dd8a5a610afb] [p: thread-pool-1; w: 17] ERROR c.b.z.s.w.SyncWorkflowMessageListener - onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222) ~[ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88) ~[ejb-container.jar:3.2-b06]
il.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) ~[na:na]

Comment by tchng [ 12/Oct/11 ]

We are able to simulate this problem beyond mdb's

Using a facelet page, that hits a JSF Managed bean which then iterates 40 times with a 1 second sleep hitting an EJB session bean, we then invoke:

asadmin stop-domain --force=false

The result of this creates the same exception:

[#|2011-10-12T14:58:09.808+0000|SEVERE|glassfish3.2|javax.enterprise.resource.webcontainer.jsf.application|_ThreadID=41;_ThreadName=Thread-2;|Error Rendering View[/index.xhtml]
javax.el.ELException: /index.xhtml: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1562)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:345)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
at org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
at java.lang.Thread.run(Thread.java:680)
Caused by: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy313.getCounterValue(Unknown Source)
at com.test.bean._EJB31_GeneratedCounterSessionBeanIntf__Bean_.getCounterValue(Unknown Source)
at com.test.MyJSFManagedBean.getCount(MyJSFManagedBean.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:224)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:148)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)

It seems that the challenge is that when the web container invokes upon the ejb container while we are seeking to stop glassfish gracefully, this exception occurs which is not a graceful shut down.

The facelet skeleton project is an attachment.

Comment by tchng [ 12/Oct/11 ]

The facelet skeleton project that simulates this problem which occurs during the exection of:

asadmin stop-domain --force=false

That if a thread in the web-container is invoking something in the ejb-container in glassfish, we get the exception: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

Which when executing an mdb, the thread is expected to finish cleanly.

Comment by Satish Kumar [ 18/Nov/11 ]

Reassigning to Marina since this issue is related to the MDB container...

Comment by Cheng Fang [ 12/Dec/11 ]

A somewhat related issue is 17315 (cannot call EJB method from method sessionDestroyed (session listener) when web container wants undeploy enterprise application.), which has to do with the stop ordering between ejb container and web container.

Graceful shutdown of ejb container involves coordiation with other modules (JMS, JCA, etc). Also need to understand the level of gracefulness, e.g., do we still accept new method invocation belonging to the same txn, the same session, and shutdown timeout. Exclude it from 3.1.2 release.





[GLASSFISH-17350] NameNotFoundException thrown during undeployment of a WAR containing EJBs annotated with portable global JNDI names Created: 26/Sep/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Vineet Reynolds Assignee: Srini
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive webejbexample.zip    
Tags: 3_1_x-exclude

 Description   

Original Java.net forum thread is http://www.java.net/forum/topic/glassfish/glassfish/namenotfoundexception-thrown-during-undeployment-war-containing-ejbs

The following exception stacktrace was produced during undeployment of a Web Archive containing EJBs with an explicit global and portable JNDI name:

[#|2011-09-26T17:39:47.229+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=20;_ThreadName=Thread-4;|WEB0610: [/WebEJBExample] failed to unbind namespace
javax.naming.NameNotFoundException: Cannot find name to unbind
at com.sun.enterprise.naming.impl.TransientContext.doUnbind(TransientContext.java:398)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2211)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2166)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:459)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

The error appears to occur when Glassfish attempts to undeploy the web module after undeploying the EJB module. The EJB module appears to be the one that owns the portable JNDI name, and when the web module attempts to unbind the non-existent JNDI name, the afore-mentioned exception is thrown. This has grave consequences in a more complicated scenario (like the usage of Hibernate as a JPA provider within the application), as the web-module does not appear to be completely undeployed, resulting in vague exceptions being thrown on a subsequent deployment and use of the application.

Surprisingly, the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation.

A testcase (an Eclipse project) to reproduce this is attached.



 Comments   
Comment by Hong Zhang [ 26/Sep/11 ]

assign to cheng for initial evaluation

Comment by Cheng Fang [ 27/Sep/11 ]

I was able to reproduce it. The use case is valid and should not cause exception logging. However, a cursory look at webModuleContextConfig.unbindFromComponentNamespace(...) method shows it only logs the exception, which shouldn't affect normal application flow. Can you provide more details how other parts of your app is affected?

Re-assign to web container for further evaluation.

From the above forum post, "the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation."

In addition, the exception is not thrown when @EJB is on servlet class.

The exception is thrown when @EJB is on ejb bean class and the ejb is packaged inside war.

Comment by Vineet Reynolds [ 28/Sep/11 ]

I'll attempt to enhance the provided test case with the failures I'm seeing in my application, since no exceptions are being thrown when using the redeployed testcase. My application currently uses Arquillian to deploy a WAR to a Glassfish instance via the REST interface. Manual deployment of the same WAR also gives the same problem, so we could rule out the REST interface. Currently, exceptions like the one shown in the below stacktrace are thrown, when attempting to use the application after redeployment. A restart of Glassfish always resolves this issue.

[#|2011-09-28T10:54:32.943+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=22;_ThreadName=Thread-4;|A system exception occurred during an invocation on EJB GroupRepository method public info.galleria.domain.Group info.galleria.service.jpa.GroupRepository.create(info.galleria.domain.Group)
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean
at com.sun.ejb.containers.BaseContainer.checkExceptionClientTx(BaseContainer.java:5049)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4884)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2039)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:236)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy234.create(Unknown Source)
at info.galleria.service.jpa._EJB31_GeneratedGroupRepositoryIntf__Bean_.create(Unknown Source)
at info.galleria.service.ejb.GroupServiceImpl.createRegisteredUsersGroup(GroupServiceImpl.java:41)
at info.galleria.service.ejb.GroupServiceImpl.getOrCreateRegisteredUsersGroup(GroupServiceImpl.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy237.getOrCreateRegisteredUsersGroup(Unknown Source)
at info.galleria.service.ejb.UserServiceImpl.signupUser(UserServiceImpl.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy239.signupUser(Unknown Source)
at info.galleria.view.user.UserManager.signupUser(UserManager.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at info.galleria.filters.UserRedirectFilter.doFilter(UserRedirectFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1179)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1112)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1118)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:618)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:269)
at info.galleria.service.jpa.GroupRepository.create(GroupRepository.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
... 104 more
Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:62)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getIdentifier(AbstractEntityTuplizer.java:230)
at org.hibernate.persister.entity.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:3852)
at org.hibernate.persister.entity.AbstractEntityPersister.isTransient(AbstractEntityPersister.java:3560)
at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:532)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:102)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:800)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:774)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:778)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:612)
... 128 more
Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field info.galleria.domain.Group.groupId to info.galleria.domain.Group
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:18)
at java.lang.reflect.Field.get(Field.java:358)
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:59)
... 139 more

#]
Comment by Shing Wai Chan [ 11/Oct/11 ]

From the debugger, I see that "GreetingManager" was unbind twice and hence has the exception in the second invocation. Web container only logs the exception as it wants the undeployment to continue in this case.

The following are the two calling stack:
1. at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.ejb.containers.BaseContainer$JndiInfo.unpublish(BaseContainer.java:5636)
at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4318)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4222)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:305)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

2. at com.sun.enterprise.naming.impl.TransientContext.doUnbind(TransientContext.java:398)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2216)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2171)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

The "GreetingManager" was unbind twice as the ejb reference presents in both ejb and web bundle descriptors. Note that those descriptors are from annotation processing for ejb in war.

Comment by Cheng Fang [ 08/Nov/11 ]

Added tag 3_1_x-exclude. There are various workaround as described in previous comments. The logged stack trace is only warning message and should not affect normal app functioning.

Comment by markokanala [ 20/Mar/13 ]

I stumbled upon this issue. I can confirm this breaks the redeploy cycle as the deploy after this exception fails. This very annoying in development use.

I'm not really sure what exactly breaks but it seems that injecting EJB's on redeploy fails.

[#|2013-03-20T15:18:25.528+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-3;|WebModule[/api]PWC1270: Exception starting filter VirtualHostingFilter
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:124)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class our.application.api.security.VirtualHostingFilter
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:315)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:745)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Local ejb-ref name= ... into nto class our.application.api.security.VirtualHostingFilter: Can not set our.application.core.service.CompanyService field our.application.api.security.VirtualHostingFilter.companyService to our.application.api.security.VirtualHostingFilter

and

[#|2013-03-20T15:18:25.919+0200|SEVERE|glassfish3.1.2|com.sun.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer|_ThreadID=19;_ThreadName=Thread-3;|Error when configuring to use the EJB interceptor binding API. JAX-RS EJB support is disabled.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer.initialize(EJBComponentProviderFactoryInitilizer.java:80)

Comment by klaasjanelzinga [ 03/Sep/13 ]

My redeployment cycle worked again after adding the messagelistener to the ejb-jar.xml:

<enterprise-beans>
<message-driven>
<ejb-name>...</ejb-name>
<ejb-class>...</ejb-class>
</message-driven>
</enterprise-beans>

Only the @MessageDriven with beans.xml caused the JAX-RS EJB support is disabled.

Comment by marina vatkina [ 03/Sep/13 ]

This seems very similar to https://java.net/jira/browse/GLASSFISH-20616





[GLASSFISH-15394] Embedded EJB Container should modify only config that is being used (server by default) Created: 30/Dec/10  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1_dev
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

The less we modify domain.xml, the less it's error-prone...






[GLASSFISH-21495] Transaction Rolled back due to timeout Created: 26/Jan/16  Updated: 19/Oct/16

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

Type: Bug Priority: Major
Reporter: cghislai Assignee: Srini
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

After upgrade from GF 4.1 to Glassfish 4.1.1, I get timed out transactions, with a warning in the log:
Warning: EJB5123:Rolling back timed out transaction [JavaEETransactionImpl: txId=51 nonXAResource=9 jtsTx=null localTxStatus=1 syncs=[com.sun.ejb.containers.SimpleEjbResourceHandlerImpl@2df56bef, com.sun.ejb.containers.ContainerSynchronization@3f02d7bb, org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper$1@5fd05f0e, org.eclipse.persistence.transaction.JTASynchronizationListener@6a5a3c2b, com.sun.enterprise.resource.pool.PoolManagerImpl$SynchronizationListener@6cf6889c, org.eclipse.persistence.transaction.JTASynchronizationListener@456035b6]] for [PlaineService]

The method triggering this rollback imports a fair amount of data and regularly flushes the persistence context. Yet, once completed after several minutes, the warning and rollback occur.

The presence of @Asynchronous or @TransactionAttribute annotations to the method does not seem to have any impact on this issue.

Using GF 4.1, the method worked correctly.



 Comments   
Comment by napu [ 12/Feb/16 ]

I can confirm the same issue.

Comment by iordannalbantov [ 25/Feb/16 ]

We have it too. The consequent problem is that our timers are expunged afterwards which makes it critical for us. Downgrade is not an option because we will hit other critical bugs which were already fixed. Unfortunately setting Maximum Redeliveries of the EJB Timer Service to a higher number doesn't work neither.

Comment by douglasjunior [ 20/Apr/16 ]

I also have a method that persists much data.

It displays Warn, but the data is successfully persisted. Exception is not thrown. This Warn has caused problems for you?

I can ignore it?

Comment by fgonzales [ 25/May/16 ]

We are running into the same issue. I also verified that Glassfish 4.1 does not have this problem. It looks specific to 4.1.1.

Comment by lprimak [ 28/May/16 ]

I suggest you open a Payara issue for this.
It would help also if you have a ready reproducer application available.

Comment by rgrashel [ 23/Sep/16 ]

Is there any movement on this issue? if <cmt-timeout-in-seconds> can be used to extend the transaction timeout of an EJB timer, can someone please post an example of what the glassfish-ejb-jar.xml file looks like? I have tried variations and simply cannot get it to work. For long-running jobs, this is absolutely a critical issue if you cannot use an EJB Timer with a long-running job.

Comment by lprimak [ 25/Sep/16 ]

Both GlassFish and Payara are actually functioning property in this instance.
The solution for this is either to extend the tx timeout via cmt-timeout-in-seconds or via domain configuration.

Or break up the service into multiple EJBs, base with no tx that calls others that manipulate the database.

Comment by fgonzales [ 25/Sep/16 ]

In EJBContainerTransactionManager, cmtTimeoutInSeconds is hardcoded to 120 seconds. This was a change made in 4.1.1. This hard-coded value cannot be over-ridden via the domain configuration. It can only be overridden individually for each EJB, which is not very practical if you have a lot of them.

Comment by lprimak [ 25/Sep/16 ]

I'm pretty sure I configured 30 minutes and it works in Payara with the domain configuration, it I'll re-test

Comment by lprimak [ 26/Sep/16 ]

I have just re-tested Tx timeouts with the latest Payara, and they are confirmed to work as designed.
I changed Transaction Service -> Transaction Timeout from non-zero to 30 seconds, and it times out after 30 seconds,
and if it's at zero, it doesn't time out (unless you count esoteric stuff like CORBA which times out after 30 minutes)

Comment by fgonzales [ 26/Sep/16 ]

So this is already fixed in Payara? In Glassfish 4.1.1 this issue definitely exists.

Comment by rgrashel [ 26/Sep/16 ]

If this works in Payara, great. But this defect is about upstream Glassfish. My question to the Glassfish team – when is a fix for this going to be issued? It is not reasonable to ask users to declare methods as TransactionAttribute.NOT_SUPPORTED because they have long-running methods. Nor is it reasonable to ask users to break apart EJBs in strange ways simply to isolate intentionally long-running EJB methods.

Comment by dirkroets [ 19/Oct/16 ]

We've ran into this issue on GF 4.1.1 as well. I've looked through the source code and this bug was introduced with the code changes that fixed GLASSFISH-21175

Setting the default TX timeout back to 0 (disabled) is trivial, so we've compiled a new version of <gf home>/glassfish/modules/ejb-container.jar that fixes the problem for us.





[GLASSFISH-21108] PostgreSQL XA transactions are not supported Created: 27/Jun/14  Updated: 27/Apr/16

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

Type: Bug Priority: Critical
Reporter: sergey.s.sazonov Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

postgresql-9.3-1101.jdbc4.jar



 Description   

We are trying to use XA transactions in PostgreSQL and facing with strange behaviour. We have many parallel EJB requests and small part of them fail due to business logic rules, exception goes up through nested EJBs and transaction rolles back. It works fine most of the time but sometimes request ends with HTTP 500 and we see these errors in log. Could you please check that. In administration guide PostgreSQL XA driver is not mentioned, so maybe it is just not supported yet.

[2014-06-26T20:53:40.677+0400] [glassfish 4.0] [WARNING] [jts.exception_on_resource_operation] [javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620677] [levelValue: 900] [[
  JTS5031: Exception [java.lang.RuntimeException: org.postgresql.xa.PGXAException: Error preparing transaction] on Resource [prepare] operation.]]

[2014-06-26T20:53:40.678+0400] [glassfish 4.0] [WARNING] [jts.unexpected_error_occurred_twopc_rollback] [javax.enterprise.system.core.transaction.com.sun.jts.jtsxa] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620678] [levelValue: 900] [[
  JTS5068: Unexpected error occurred in rollback
org.postgresql.xa.PGXAException: Error rolling back prepared transaction
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:418)
	at com.sun.gjc.spi.XAResourceImpl.rollback(XAResourceImpl.java:195)
	at com.sun.jts.jta.TransactionState._rollback(TransactionState.java:202)
	at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:180)
	at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:333)
	at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1040)
	at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:391)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:122)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	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.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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: org.postgresql.util.PSQLException: ERROR: prepared transaction with identifier "4871251_UhsAAL/TCNl0ZXN0LmJ0Zi5sb2NhbCxzZXJ2ZXIsUDEwMA==_dGVzdC5idGYubG9jYWwsc2VydmVyLFAzNzAwLAA=" does not exist
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:559)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:331)
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:406)
	... 73 more
]]

[2014-06-26T20:53:40.693+0400] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620693] [levelValue: 900] [[
  EJB5184:A system exception occurred during an invocation on EJB CommandEndpoint, method: public void com.btf.soesg.api.CommandEndpoint.updateIssue(java.lang.String,com.btf.soesg.api.dto.UpdateIssueParam) throws com.btf.soesg.api.APIException]]

[2014-06-26T20:53:40.694+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620694] [levelValue: 900] [[
  
javax.ejb.EJBException: Transaction aborted
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:725)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	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.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	... 61 more
]]

[2014-06-26T20:53:40.697+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620697] [levelValue: 900] [[
  StandardWrapperValve[com.btf.soesg.api.rest.App]: Servlet.service() for servlet com.btf.soesg.api.rest.App threw exception
javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	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.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	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.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	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)
]]


 Comments   
Comment by MarioLovisi [ 27/Apr/16 ]

Hi please try to set 'max_prepared_transactions' in the local postgres.config to the max numbers of connection in the connection pool.

see doc. http://www.postgresql.org/docs/9.4/static/runtime-config-resource.html
" you will probably want max_prepared_transactions to be at least as large as max_connections, so that every session can have a prepared transaction pending."





[GLASSFISH-4628] Inconsistent bean cache/pool attribute defaults Created: 06/Apr/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: dinglemouse Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,628

 Description   

There seem to be ejb-container and mdb-container attribute default
inconsistencies between the documentation and the admin GUI for the following:

1. ejb-container
steady-pool-size: 32/0
pool-resize-quantity: 16/8
max-pool-size: 64/32

2. mdb-container
steady-pool-size: 10/0
pool-resize-quantity: 2/8
max-pool-size: 60/32

Furthermore, the MDB source code at
appserv-core\src\java\com\sun\ejb\containers\MessageBeanContainer.java has coded
defaults which are also different again in some cases:

private static final int DEFAULT_RESIZE_QUANTITY = 1;
private static final int DEFAULT_STEADY_SIZE = 10;
private static final int DEFAULT_MAX_POOL_SIZE = 60;
private static final int DEFAULT_IDLE_TIMEOUT = 600;
private static final int MIN_IDLE_TIMEOUT = 1;



 Comments   
Comment by dinglemouse [ 06/Apr/08 ]

Sorry - should have said 9.1 ur1

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ksak [ 28/Jan/09 ]

Reassigning bugs from Mahesh

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by marina vatkina [ 08/Mar/12 ]

Let's verify this





[GLASSFISH-9950] EJB-5-5 Embedded EJB Container: need to find available ports for remote EJBs and JMS Created: 02/Oct/09  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
blocks GLASSFISH-12202 EJB-5 Full EJB 3.1 API support in Emb... Open
Issuezilla Id: 9,950

 Description   

Remote EJBs and JMS have port conflicts in embedded mode if GF instance is running



 Comments   
Comment by ksak [ 23/Oct/09 ]
      • Issue 10527 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 26/Oct/09 ]

rfe





[GLASSFISH-15144] <post-construct> in web.xml doesn't apply to EJB classes Created: 13/Dec/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude

 Description   

If I add a <post-construct> entry to web.xml, it doesn't apply to any EJB classes in the war file.

Currently, all post-construct (and pre-destroy) information for an EJB is stored in the
EJBDescriptor. Because of this, these entries in web.xml aren't visible.

Storing the post-construct information in the WebBundleDescriptor caused other failures.
If a superclass and EJB subclass both have the same @PostConstruct method, it was being
called twice. It wasn't properly computing the visibility of methods and which apply;
that seems to only be done in ComponentDefinition when processing EJB annotations. I wasn't
able to figure out exactly why it was going wrong in this case, so the post-construct
information was left at the EJBDescriptor level until this could be fixed. The consequence
of that is this bug.



 Comments   
Comment by marina vatkina [ 20/Dec/10 ]

Not enough time to address it in 3.1





[GLASSFISH-13848] Provide CLI to restart timer service Created: 06/Oct/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,848

 Description   

This might be needed after database restart



 Comments   
Comment by marina vatkina [ 06/Oct/10 ]

Next release





[GLASSFISH-19546] TimerHandle can be passed through EJB's remote interface Created: 17/Jan/13  Updated: 21/Sep/15

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

Type: Bug Priority: Major
Reporter: amy.yang Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

TimerHandle can be passed through EJB's remote interface, which is forbidden by EJB Spec.






[GLASSFISH-12202] EJB-5 Full EJB 3.1 API support in Embeddable EJB API Created: 09/Jun/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issue Links:
Dependency
depends on GLASSFISH-12151 EJB-5-1 Support libraries in classpat... Resolved
depends on GLASSFISH-9950 EJB-5-5 Embedded EJB Container: need ... Open
Issuezilla Id: 12,202

 Description   

Add support for missing EJB 3.1 functionality ( Web Service endpoints, MDBs,
Timer Service ) in Embeddable EJB API



 Comments   
Comment by marina vatkina [ 09/Jun/10 ]

...

Comment by marina vatkina [ 29/Jun/10 ]

EJB Timer service is fully supported.

EJBs in a .war file (or an exploded directory) are supported as following:

  • If there is only 1 web app with EJBs, libraries are ignored.
  • If there are other EJB modules, a temp ear is created.

Note that to test EJBs in a war, the client code needs to use EJBs with
intefaces (those ejbs are not part of the classpath, and can't be loaded by the
client class loader) or a version of the EJB without annotations (so it's not
treated as another EJB module).

Webservices are supported when they are packaged in a war file with the
static-shell.jar ONLY.

Comment by marina vatkina [ 29/Jun/10 ]

One more note: To test webservices, a property
"org.glassfish.ejb.embedded.glassfish.web.http.port" must be passed to
createEJBContainer() call. For the pre-installed GlassFish, the value of the
property can be any non-empty string, but the actual value is ignored.

Comment by marina vatkina [ 01/Oct/10 ]

Postpone...





[GLASSFISH-12007] lib/databases should be moved to a different directory Created: 24/May/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Critical
Reporter: Bill Shannon Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 12,007

 Description   

The only thing in the "lib" directory that shouldn't be synchronized to
an instance of a cluster is the lib/databases directory. We should move
this directory to a different location, perhaps a top level "databases"
directory.

This would involved an upgrade service to rename the directory, as well as
changes in the base configuraiton to use the directory in its new location.



 Comments   
Comment by marina vatkina [ 25/May/10 ]

...

Comment by marina vatkina [ 05/Oct/10 ]

Let's first stabilize the current upgrade of the timer service, then look at the
right place for its database files





[GLASSFISH-4021] Resouce Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) Created: 21/Jan/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Critical
Reporter: gfuser9999 Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,021
Tags: 3_1-exclude, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

--------
Problem
--------
1. Resource injections fails when using HandlerChain that have a
EJB/Resource injected that is an EJB/JNDI. And one gets
"Handler xxxxx instance injection failed : Exception attempting to inject
Resolved Ejb-Ref xxxx/bean@jndi: - > xxxxx]

The issues is that assuming we have 2 EJB and we want to have

  • EJB B exposed as Webservice and handle a HandlerChain handler
    So we have
    @Stateless
    @WebService
    @HandlerChain(file = "handle.xml")
    public void EJBBBean { ... }
  • We do not care above EJB A
  • Note that the handler is
    public class handler implements SOAPHanlder { @EJB EJBBBean bean; .... }
  • Now when one deploy this depending on the ordering
    of initialization of EJB, sometimes
    EJBA, EJBB and this works but if sometimes it is
    EJBB, EJBA then resource injection fails
  • The issues is that the following happens where it seems when
    a EJB is exposed as WebService and have a handler,
    a) The EJB is created and the handler is created
    b) The handler will be injected but then the issue is
    that THERE is IT may be possible that at the time
    the dependency is not met (since EJBA is not loaded or initialized
    nor registered to the JNDI even)

com.sun.enterprise.InjectionException: Exception attempting to inject Resolved
Ejb-Ref org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler
at
com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:391)
at
com.sun.enterprise.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:206)
at
com.sun.enterprise.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:100)
at
com.sun.enterprise.webservice.WsUtil.processConfiguredHandlers(WsUtil.java:2529)
at
com.sun.enterprise.webservice.WsUtil.configureJAXWSServiceHandlers(WsUtil.java:2570)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:294)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:342)
at
com.sun.enterprise.webservice.WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint(WebServiceEjbEndpointRegistry.java:122)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:329)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:345)
at
com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:550)
at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)

  • Now, this problem does not seems to be that the system does not resolve ordering
    Since writing more EJB seems to say that the GF system tends to order the EJB
    module
    However, there seems to be some race or data structure ordering issue since
    that the EJB module loading sequence on every stop/start is different and
    it is possible to get a EJB processing order that does not work.

--------------------
Testcase and details
--------------------
1. Get the attached NB6 ejbdeptest.zip and deploy
This testcase have many a few EJB modules to make this easier to hit this
Deploy ejbdeptest.ear

2. Stop/Start (asadmin stop-domain/start-domain)
and look for the injection failure. (REPEAT until failure is SEEN)
(grep SEVERE)

3. [Unpredictable and repeat (2) until SEVERE happens like below]

[#......|SEVERE|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=20;_ThreadName=httpSSLWorkerThread-14849-2;_RequestID=3a6b0964-02e0-419f-acc0-49c651e2916b;|Handler
org.test.ws.FailInjectionHandler instance injection failed : Exception
attempting to inject Resolved Ejb-Ref
org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler|#]

3. Note some tracing does indicate that Bean processing via getEjbDescriptors()
varies sometimes and below is a failure sequence. (It is unknown
why the behaviour on the EJB processed changes sometimes)

[#.....|INFO|sun-appserver9.1|javax.enterprise.system.co
re.classloading|_ThreadID=10;_ThreadName=main;|[DEBUG] AbstractLoader org.test.s
lsb.e0Bean org.test.slsb.b6Bean org.test.slsb.b3Bean org.test.slsb.b2Bean or
g.test.slsb.b4Bean org.test.slsb.b1Bean org.test.slsb.b5Bean org.test.slsb.b0
Bean org.test.slsb.e1Bean org.test.slsb.zfailBean org.test.slsb.z0Bean org.t
est.slsb.z1Bean org.test.slsb.e2Bean |#]



 Comments   
Comment by Hong Zhang [ 22/Jan/08 ]

Assign to Mahesh for initial investigation. Also addding Bhakti to the Cc.

Attaching CWeng's suggested solutions below:
=============================================
And so i suppose plain common-sense must be used (which would then indicate the
system should be able to tell that a Handler class is used by WebserviceX and
the Handler class need Y, so Y must be initialized by X.

Even if there is no LOAD order, one may presume that creation of ALL EJB should
be done first and then on 2nd part the creation of all Webservices that those
EJB expose is done.
At this point the EJB and Webservice step for a EJB is coupled together....

Comment by Mahesh Kannan [ 14/Feb/08 ]

The problem is that the handlers are created probably way too early.

The Container calls
WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint() during container
initialization time which causes the handlers to be instantiated (which inturn
causes injection). We need to delay the instantiation of the handlers till the
dependent EJBs are processed.

One way to do that is to provide two methods:
1. One to register the the EjbService endpoint which WILL NOT call
WsUtil.processConfiguredHandlers()

2. The other method (say createConfiguredHandlers()) can create and call
InjectionManager.injectInstance(handler)

Once the above methods are in place the StatelessContainer can call the second
method from doAfterApplicationDeployed().

I am assigning this to Bhakti to implement the above two methods.

Comment by Bhakti Mehta [ 15/Feb/08 ]

Looking into it

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ramapulavarthi [ 01/Dec/10 ]

I have n't run any tests but seeing the code in v3.1, we should run into the same problem.
Can't forward port the patches CR6653050 and CR6750245 as the code in v3 is little different from v2.1.
The fix needs to go into EJB container code to change the way we intialize and load the ejb web services.

Comment by Bhakti Mehta [ 08/Dec/10 ]

Reassigning to Rama since he has already looked into this issue . My inclination is to exclude this for this release but will wait for Rama's input

Comment by ramapulavarthi [ 21/Dec/10 ]

This requires changes in EJB Container to change the way EJB ws are loaded and needs coordination with EJB team. Adding V3.1 excludes as this is risky to make this change now.

Comment by Nazrul [ 23/Dec/10 ]

This bug has been around for few releases now. Based on inputs from Bill, I am setting target for 3.2 release with P2 priority so that it gets fixed. If we do not want to fix this bug, please close it.

Comment by 8086 [ 25/Mar/12 ]

We have been waiting for a fix for three years now. As of now, our application needs to be redeployed until it works. This might take anywhere from 1 redeploy to 15 redeploys to get it working.

If you are not fixing it, is there a way to work around it in our code that can remove the pain of innumerous redeploys?

Comment by kumara [ 26/Mar/12 ]

-> Martin Grebac for evaluation.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

Resource Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) (4021)

Description
EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services.

Workaround
EJB initialization usually happens in alphabetical order. Rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

In the following example, B is initialized first together with handler X, which expects C to be available but it is not, and deployment fails. The workaround is to rename B to D (for example), so lexicographically it follows C, in which case C should be initialized first and be available for injection to X.

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

</jws:handler-chains>
@EJB private C;
...}

Comment by Gail Risdal [ 05/Jun/13 ]

Fixed the example in the release notes (first line in the "Handler" section; release notes document has proper formatting/indentation):

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

public class X implements SOAPHandler<SOAPMessageContext>

{ @EJB private C; ...}




[GLASSFISH-12634] Make 'glassfish.embedded.tmpdir' available as a parameter to EJBContainer.createEJBContainer Created: 13/Jul/10  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: szczyp Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,634

 Description   

Currently the 'glassfish.embedded.tmpdir' setting is only used if it is a system
property. Please make it available as a parameter to
EJBContainer.createEJBContainer.
Using this settings helps keeping the workspace clean (for example, the temp dir
can be set to be within the 'target' directory within the maven build structure.
When it is required as a system property, it might come in the way for maven
surefire users as it requires to fork surefire or use an alternative command
line, which has its limitations. If this was a parameters to the mentioned
method, it would be much easier.



 Comments   
Comment by sirajg [ 13/Jul/10 ]

These properties are used by the createEJBContainer API.

Comment by szczyp [ 13/Jul/10 ]

When I am in the main Gf 3.1 build 09 directory and issue a command:
grep -R 'glassfish.embedded.tmpdir' *
to recursively search for any use of the property, the only thing that is found is:
common/glassfish-api/src/main/java/org/glassfish/api/embedded/Server.java:
String tmpDir = System.getProperty("glassfish.embedded.tmpdir");

I also tested this before I came up with this simple test, and it didn't work.

Comment by szczyp [ 14/Jul/10 ]

Please go to https://glassfish.dev.java.net/issues/show_bug.cgi?id=12658,
download the attachment and run it (it will fail).
It tries to set the tmpdir property to the EJBContainer.createEJBContainer, and
if you debug and stop in the middle, you will note that the property is not
used. If it is set on the cmdline in surefire, it works fine.
I also try to use another property
(org.glassfish.ejb.embedded.keep-temporary-files) which I found in
EJBContainerProviderImpl, but it also seems not to work, or I don't know how to
use it. It is package private so it might mean I am not supposed to use it at
all. My test with the 'grep' tool also shows that it is only used as a system
property.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5068] Covariant return type don't work in EJB 2.1 compatibility view Created: 27/May/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: mkarg Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,068

 Description   

Java SE 5 has the nice feature of covariant return types. The idea is to narrow
down the actual return type of a method that was defined too wide by the super
class.

If a session bean provides an EJB 2.1 compatibility view, it is in theory
possible to inherit the EJB 2.1 compatibility home interface from a super
interface, which in turn extends EJBHome.

Imagine the case that the super interface defines the necessary create method in
this way:

public SuperRemote create() throws CreateException, RemoteException;

and the sub class re-defines it using a covariant return type:

public CovariantRemote create() throws CreateException, RemoteException;

where CovariantRemote extends SuperRemote, and SuperRemote extends EJBObject.

From the logical aspect, this should work. Also I do not see that the spec would
prohibit that.

The compiler doesn't complaint.

The verifier.bat doesn't complaint about it (0 Failures, 0 Warning, 0 Errors).

But: When deploying on GlassFish, you will find a lot of exceptions in the log
and the application is NOT loaded.

I think that is a bug and since I need covariant return types, for me it is a
showstopper.

Here is the problem from the log:

UnExpected error occured while creating ejb container
java.lang.IllegalStateException: Error : methods public abstract
de.quipsy.sessions.folder.FolderRemote
de.quipsy.sessions.folder.FolderHome.create() throws
javax.ejb.CreateException,java.rmi.RemoteException and public abstract
de.quipsy.sessions.contactpersonmanager.ContactPersonManagerRemote
de.quipsy.sessions.contactpersonmanager.ContactPersonManagerHome.create() throws
java.rmi.RemoteException,javax.ejb.CreateException both result in IDL name
'create__' at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.buildNameTranslation(IDLNameTranslatorImpl.java:407)
at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.<init>(IDLNameTranslatorImpl.java:221)
at
com.sun.corba.ee.impl.presentation.rmi.IDLNameTranslatorImpl.get(IDLNameTranslatorImpl.java:169)
at
com.sun.corba.ee.impl.presentation.rmi.PresentationManagerImpl$ClassDataImpl.<init>(PresentationManagerImpl.java:153)
at
com.sun.corba.ee.impl.presentation.rmi.PresentationManagerImpl.getClassData(PresentationManagerImpl.java:125)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.setTarget(ReflectiveTie.java:97)
at
com.sun.enterprise.iiop.POAProtocolMgr.validateTargetObjectInterfaces(POAProtocolMgr.java:198)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:916)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:232)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:654)
at com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:536) at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)
at
com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244) at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at
com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at
sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90) at
$Proxy1.invoke(Unknown Source) at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by marina vatkina [ 27/May/08 ]

Making it a regular RFE according to the comment from Ken:
It's not required by the spec. The EJB 2.x view requirements were written
before support for covariant return types was added to Java SE 5.0. It's
something that would need to be explicitly added as a requirement to the EJB 3.1
spec. That's unlikely for the EJB 2.x view since that's essentially frozen.
It's a possibility for the EJB 3.x view.

Comment by mkarg [ 28/May/08 ]
      • Issue 5068 has been confirmed by votes. ***
Comment by mkarg [ 28/May/08 ]

I do not share that it is not a bug but a RFE.

The compiler allows it, also the verifier allows it. Also the server doesn't
show an error message, only a warning.

It is possible to do it in GlassFish right now, so it should work, or GlassFish
should give an error message explaining a good reason why it is not working.

I do not see the reason right now. If I see it correctly the only problem is
that the method name is not unique. So just make it unique and it will work.

The spec says that Java SE 5 is to be supported. It does not explicitely exclude
EJB 2.1 Compatibility Views. If there would be such an exclusion, the spec must
explicitely tell that for EJB 2.1 Compatibility Views only Java SE 4 is to be
supported, but not 5. Unless such an exclusion is found in the spec, it has to work.

Comment by marina vatkina [ 17/Mar/11 ]

Cheng, you were looking at similar issues...

Comment by mkarg [ 07/Jul/11 ]

V3.1 is out since months and still covariant return types are not working. Still for me this is nothing else but a BUG and should get fixed ASAP. It times of Java SE 6u26 and Java EE 6 it is just ridiculous and a shame for GFv3 that a language feature (not even a EE feature!) is not supported and leads to an error message!

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Tom Mueller [ 15/Feb/13 ]

Reassigning to component lead as the assignee is no longer with the project.





[GLASSFISH-16282] Passivation batching is not predictable Created: 29/Mar/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 4.1.1

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

Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

The batch scheduled for passivation is not closed for additions, so usually 1 or 2 extra instances are passivated instead of the batch size. To reproduce - increase the number of beans in ejb31/full/passact/client/Client.java






[GLASSFISH-931] annotations ignored on ejb3 business method with covariant return type Created: 14/Aug/06  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: Cheng Fang Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 931

 Description   

When I use such a business method in a simple ejb3 stateless session bean, it
works fine

@Remote
public interface EchoRemote {
void echo();
void echo2();
Object getMessage();
}
------------------
@Stateless
public class EchoBean implements com.foo.ejb.EchoRemote {
...

public String getMessage()

{ //String, instead of Object, is returned return "A message from EchoBean"; }
}

When I apply a @TransactionAttribute(TransactionAttributeType.MANDATORY) on this
business method, the annotation is ignored.
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public String getMessage() { //String, instead of Object, is returned return "A message from EchoBean"; }

I expect a TransactionRequiredException or the like, since my web client doesn't
start transaction, but no exception occurred. The generated ejb-jar.xml after
deployment contains no transaction attribute for any methods. So the default
REQUIRED is always used.

If I change the return type to Object, I got the expected exception.

I suspect all method-level annotation on such methods are ignored, though I
haven't tested other annotations.
This looks like a bug, unless ejb spec has special restrictions on covariant
return type.

The root cause is in
annotation-framework/src/java/com/sun/enterprise/deployment/annotation/impl/ComponentDefinition.java:
private void initializeMethods() {
for (Class cl: classes) {
for (Method method : cl.getDeclaredMethods()) {
MethodKey mk = new MethodKey(method);
if(methodMap.containsKey(mk))

{ methodMap.get(mk)); }

methodMap.put(mk, method);
}
}
}

For EchoBean.class, getDeclaredMethods() contains both Object getMessage(); and
String getMessage(). Although no order is guaranteed, the Object one happens to
be after the String one. So the Object one will always overwrite the existing
binding for the String one in methodMap, since their MethodKey are the same.
Therefore, any annotations on String getMessage() are ignored.

I don't know why here we need a custom equals method for Method. For this
particular issue, we could modify MethodKey.equals() to distinguish return type.
Another options is to check methodMap.contains(methodKey) before overwriting
any existing bindings, and choose the method with the most specific return type.

I'd suggest we add this feature. JBoss supports this or will support this.

I also noticed while debugging this, ComponentDefinition.initializeMethods() is
called twice in a row, doing exactly the same thing. May be of interest.



 Comments   
Comment by ksak [ 15/Aug/06 ]

In addition to the ComponentDefinition.initializeMethods() issue, the logic in
com.sun.enterprise.TypeUtil.sameMethodSignature() will need to be revisited. This method is called
during the processing of tx and security method annotations and is used to compare an interface method
with a method on an implementation class. In its current form, it expects return types to be exactly the
same, which will need to be relaxed in order to achieve the correct semantics.

Comment by gfbugbridge [ 10/Nov/06 ]

<BT6492478>

Comment by gfbugbridge [ 11/Nov/06 ]

<BT6492714>

Comment by Hong Zhang [ 30/Jan/07 ]

accepted

Comment by Hong Zhang [ 15/Feb/07 ]

Downgrade to P4 after discussing with cheng.

Comment by Cheng Fang [ 14/May/09 ]

This issue still exists in V3.

Comment by Hong Zhang [ 14/May/09 ]

ken: I vaguely remember you said something about covariant methods might not
make sense and you may clarify it in EJB3.1 spec?

Comment by Hong Zhang [ 22/Sep/09 ]

ken: any update on the spec w.r.t co-variant return type?

Comment by ksak [ 22/Sep/09 ]

It's not something we'll be able to address in EJB 3.1 so it will continue to be non-portable. Changing to
RFE to be considered in a future release.

Comment by ksak [ 22/Sep/09 ]

Changing ownership.

Comment by marina vatkina [ 25/Mar/11 ]

Cheng,

Check if it is already fixed...

Comment by Cheng Fang [ 26/Mar/11 ]

This problem still exists in 3.2 trunk.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Tom Mueller [ 15/Feb/13 ]

Reassigning to component lead as the assignee is no longer with the project.





[GLASSFISH-21369] MDBs with no-methods listener interface don't work with Bean-managed transactions Created: 01/Jun/15  Updated: 01/Jul/15

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

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the EJB 3.2 specification, section 5.4.3 "Message-Driven Bean with No-Methods Listener Interface" states

A message-driven bean is permitted to implement a listener interface with no methods.

and that

The resource adapter determines which message listener method is invoked according to its implementation logic.

However if a resource adapter is deployed which makes use of this feature, and a MDB is deployed which is configured to use bean-managed transactions, then the following exception is thrown when the resource adapter attempts to deliver a message to the MDB proxy provided by the EJB container:

Caused by: javax.ejb.EJBException: Transaction Attribute not found for methodpublic abstract void jms.jms21.mdb.mdb3.ejb.__EJB32_Generated__MyMessageBean__Intf__.giveMeAMessage(javax.jms.Message)
  at com.sun.ejb.containers.BaseContainer.getTxAttr(BaseContainer.java:2826)
  at org.glassfish.ejb.mdb.MessageBeanContainer.containerStartsTx(MessageBeanContainer.java:416)
  at org.glassfish.ejb.mdb.MessageBeanContainer.isDeliveryTransacted(MessageBeanContainer.java:718)
  at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:173)
  at com.sun.proxy.$Proxy261.giveMeAMessage(Unknown Source)
  at jms.jms21.mdb.mdb3.ejb.__EJB32_Generated__MyMessageBean__Intf____Bean__.giveMeAMessage(Unknown Source)
  ... 8 more

(In this example, the listener method invoked by the resource adapter is called giveMeAMessage).

This exception only occurs if the MDB is configured with bean-managed transactions, using the annotation

@TransactionManagement(value = TransactionManagementType.BEAN)

The cause seems to be the following code in org.glassfish.ejb.mdb.MessageBeanContainer, which cannot cope with the case where the listener interface has no methods:

// Register the tx attribute for each method on MessageListener
// interface. NOTE : These method objects MUST come from the
// MessageListener interface, NOT the bean class itself. This
// is because the message bean container clients do not have
// access to the message bean class.
Method[] msgListenerMethods = 
   msgBeanDesc.getMessageListenerInterfaceMethods(loader);

for (int i = 0; i < msgListenerMethods.length; i++) {
  Method next = msgListenerMethods[i];
  addInvocationInfo(next, MethodDescriptor.EJB_BEAN, null);
}

The premise of this method seems to be wrong. With a MDB, whether or not the container needs to start a transaction is defined for the MDB class as a whole, not for individual methods. (See EJB 3.2 section 5.4.13). So there should be no need for the EJB container to know what the listener method is. All it needs to know is whether the MDB as a whole is configured to use container-manager or bean-managed transactions.



 Comments   
Comment by Debayan_Gupta [ 18/Jun/15 ]

Could you please provide a test case for this for better debugging and testing? I guess the example app will do fine. Just provide the module and usage instruction.

Comment by Debayan_Gupta [ 22/Jun/15 ]

Requesting again :
Could you please provide a test case for this for better debugging and testing? I guess the example app will do fine. Just provide the module and usage instruction. It'll be faster from our side to debug the problem with unit test.

Comment by Nigel Deakin [ 01/Jul/15 ]

I have a GlassFish devtest I can send you. However this requires an updated version of the MQ resource adapter jmsra that is built into GlassFish. This has been modified to support a no-methods listener interface. Let me know if you wish me to send you this: you will need to replace the version in your GlassFish installation with this new version. There are also some small changes to GlassFish that will be necessary to allow this to be used.

Is there an existing GlassFish test which tests support for MDBs with a non-methods listener interface? If there is such a test, then is it possible to extend it this to use bean-managed transactions?





[GLASSFISH-21384] Calling an @Asynchronous method in @Startup @Singleton EJB causes Classloader leak Created: 01/Jul/15  Updated: 01/Jul/15

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

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


 Description   

Trying to trace down a Classloader leak in a larger project, I managed to create a minimal setup that triggers it.

Basically, I have two EJBs that look like this:

@javax.ejb.Singleton
@Startup
@DependsOn( "Singleton2" )
public class Singleton1
{
@EJB
private Singleton2 s2;

@PostConstruct
public void init()

{ s2.leakTest(); }

}

@javax.ejb.Singleton
@Startup
public class Singleton2
{
@Asynchronous
public void leakTest()

{ System.out.println( Thread.currentThread().getName() ); }

}

If I repeatedly redeploy a WAR file containing those two classes, a heap dump reveals that for each deployment, a new org.glassfish.web.loader.WebappClassLoader is retained. I analyzed the heap dump with the Eclipse Memory Analyzer and found the GC root of those leftover WebappClassLoader instances to be a Thread, namely the EJB pool thread that ran the asynchronous method (as verified by the console output), e.g. "_ejb_thread_pool1", then "_ejb_thread_pool2" etc.

There are actually two fields that have a reference chain to the retained WebappClassLoader: for one, the "inheritedAccessControlContext", for two, a ThreadLocal entry that goes through HandlerData, EjbInvocation, and finally what must be the proxied EJB.

I have uploaded screenshots of the relevant parts of the heap dump analysis here: http://i.imgur.com/gmnSXFA.png and here: http://i.imgur.com/xrRhN5j.png. This is after re-deploying 3 times, so there are 3 leaked Classloader instances. The other two have the same structure as the one shown in the second screenshot.

I did not test (yet) whether this occurs with a non-Startup/Singleton EJB too.






[GLASSFISH-21368] Glassfish embedded ejb container hangs until restart. Created: 30/May/15  Updated: 30/May/15

Status: Open
Project: glassfish
Component/s: ejb_container, embedded
Affects Version/s: 4.0, 4.1
Fix Version/s: None

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

Windows 8.1, Glassfish 4.1



 Description   

When attempting to run unit tests using the embedded ejb container, I am only able to run the tests once, then when attempting to run the tests again deploying to the EJB Container hangs. It remains frozen until I restart my computer.

Here is the stack trace of a successful run:

May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying app: org.glassfish.embeddable.archive.ScatteredArchive@470b5213
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] GlassFish status: STARTED
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying as a ScatteredArchive
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle <init>
INFO: Java security manager is disabled.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: Entering Security Startup Service.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.PolicyLoader loadPolicy
INFO: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
May 29, 2015 10:13:40 PM com.sun.enterprise.security.SecurityLifecycle onInitialization
INFO: Security Service(s) started successfully.

A hanging run would freeze as so:

May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying app: org.glassfish.embeddable.archive.ScatteredArchive@470b5213
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] GlassFish status: STARTED
May 29, 2015 10:13:25 PM org.glassfish.ejb.embedded.EJBContainerImpl deploy
INFO: [EJBContainerImpl] Deploying as a ScatteredArchive

I was curious about the java security manager disabled portion, so I enabled the java security manager in the admin panel and the EJB container just fails when deploying. I suspect that there is something going on with the security lifecycle but I am unsure.

Any help is greatly appreciated.






[GLASSFISH-21087]  ManagedExecutorService does not execute tasks submitted during application startup Created: 12/Jun/14  Updated: 01/May/15

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

Type: Bug Priority: Major
Reporter: tomdcc Assignee: Srini
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0, Java 7, currently testing on Windows 7



 Description   

I'm attempting to schedule a task from inside a singleton bean which is initialised at startup:

@Singleton
@Startup
public class StartupSingleton {
      @Resource
      ManagedExecutorService executorService;

      @PostConstruct
      public void init() {
            System.out.println("init");
            Future<?> future = executorService.submit(new Runnable() {
                  public void run() {
                        System.out.println("run");
                  }
            });
            
            try {
                  Thread.sleep(1000);
                  if(future.isDone()) {
                        future.get();
                        System.out.println("ok");
                  } else {
                        System.out.println("not run");
                  }
            } catch (Exception e) {
                  e.printStackTrace();
            }
      }
}

I then get the following in the logs:

2014-06-10T15:45:07.497+0930|Info: init
2014-06-10T15:45:08.499+0930|Severe: java.util.concurrent.ExecutionException: javax.enterprise.concurrent.AbortedException: Module glassfish-executor-test is disabled
      at java.util.concurrent.FutureTask.report(FutureTask.java:122)
      at java.util.concurrent.FutureTask.get(FutureTask.java:188)
      at foo.StartupSingleton.init(StartupSingleton.java:33)
      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.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
      at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
      at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
      at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
      at sun.reflect.GeneratedMethodAccessor129.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.CallbackInterceptor.intercept(InterceptorManager.java:986)
      at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
      at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
      at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
      at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
      at sun.reflect.GeneratedMethodAccessor130.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.CallbackInterceptor.intercept(InterceptorManager.java:986)
      at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
      at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
      at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
      at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:1949)
      at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:475)
      at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:81)
      at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:654)
      at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:396)
      at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
      at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
      at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
      at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
      at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
      at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
      at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
      at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
      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 com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
      at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
      at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
      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:744)
Caused by: javax.enterprise.concurrent.AbortedException: Module glassfish-executor-test is disabled
      at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:146)
      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)

And the submitted task is not run. (glassfish-executor-test is just the name of the standalone test case that I created).

Surely either the executor service should be initialized and available by the time @PostConstruct stuff is executed, or it should queue submitted tasks and execute them once the application is started.

This is just using the default managed executor service in a default domain.xml file.



 Comments   
Comment by kingsob [ 23/Jun/14 ]

I am seeing the same thing. Is this a bug? How else would I add a task to the executor on ejb start up?

Comment by mreichman [ 14/Jul/14 ]

Also seeing the same in 4.0.1b8, from an @Asynchronous method called from a @PostConstruct.

Was able to work around it by throwing a Thread.sleep in my @Asynchronous method, but that is certainly not a workable solution.

Comment by afcarv [ 17/Dec/14 ]

Got the same issue. Are you using module/application versioning?

Cause appears to be some mix-up at "org.glassfish.concurrent.runtime.ContextSetupProviderImpl"; method "isApplicationEnabled" checks to see if the current context application is enabled, but I think the app name contains only the base name (e.g. "my-application") while the app list contains the full name (e.g. "my-application:1.0.0"). So no match is found.

I was able to work around by deploying the app without the version but the obvious consequence is losing the versioning feature. Not sure if there's a better way.

Comment by jiggster [ 28/Apr/15 ]

You can configure the deployment order of the ManagedExecutorService resource. Set it to some low value (e.g. 0, by default it's 100), restart the server and check if that helped.

Comment by payara_steve [ 01/May/15 ]

This is a related issue with the same cause https://java.net/jira/browse/GLASSFISH-21216





[GLASSFISH-21327] EJB Timer application won't deploy to a stand-alone GF server instance using Derby Created: 12/Mar/15  Updated: 12/Mar/15

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

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

RHEL v6.6 (Santiago)
Java v1.8.0_40



 Description   

When trying to move the EJB Timer application to a GF stand-alone instance using the Derby database, a java.sql.SQLException is thrown because of the inability by Derby to create a(n ejbtimer) database in GF_HOME/nodes/localhost-<domainname>/<server_name>/lib/databases/ejbtimer. The top-level exception is thrown while trying to creating a resource for the __TimerPool with the inability to create the appropriate Derby database files seeming to be the culprit.






[GLASSFISH-21290] Returned value from SLSB takes minutes to the caller Created: 18/Jan/15  Updated: 21/Jan/15

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

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


 Description   

We moved an EAR project containing an EJB module and an ACC module from GF 4.0 to GF 4.1.

When we make a remote call from the ACC client (Java Swing App started via webstart) on GF 4.0, the duration is about 2 secs and on GF 4.1 about 120 seconds.

The EJB makes some JPA calls (Hibernate 4.3) and returns a fairly complex entity, but as we have seen very fast. The times gets lost after the EJB method return.

So what happens after the EJB return - marshalling of the returned value? Can anybody point me to a topic, where I can further look at?

Thanks, Andreas



 Comments   
Comment by anowac01 [ 21/Jan/15 ]

You may want to look at GLASSFISH-21285 and the thread linked there, which sounds like a similar issue, though I don't believe there is much in the way of solutions identified there yet.





[GLASSFISH-21277] RMI/IIOP calls include the "local classpath" instead of the remote classpath, incurring in performance penalties without apparent benefits Created: 22/Dec/14  Updated: 22/Dec/14

Status: Open
Project: glassfish
Component/s: ejb_container, orb
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: moonysun Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 11, Linux 3.6+, JDK 1.7.0_62



 Description   

We've noticed (by capturing with snoop and tcpdump) that a glassfish v3.1.2.2 being called by an external client or glassfish v3.1.2.2 calling other application server via RMI/IIOP sends and/or receives CORBA messages that include gf classpath pointers.

Example:
getParametroByPeriodo.......................................NEO...................'~file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/slf4j-api-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-jpa-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-io-2.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-service-export-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-servlet-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-core-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logging-adapter-slf4j-1.0.2.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-config-prettyfaces-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-cas-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-layouts-3.5.25d-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-fileupload-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/generated/ejb/fc// file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/cas-client-core-3.2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/IIESCommons-2.0.14.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ehcache-2.8.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-api-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/sicc-service-export-2.0.197b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logback-classic-1.1.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-integration-cdi-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gson-2.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-utilities-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/joda-time-2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ehcache-jgroupsreplication-1.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-main-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-guicomponents-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-beanutils-1.8.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-cdi-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-ehcache-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-lang3-3.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/framework-server-2.0.69c.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-primefaces-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/groovy-all-2.0.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEGIOP............B-INF/lib/hibernate-envers-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jul-to-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/primefaces-3.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/logback-core-1.1.0.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-jsf-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/dom4j-1.6.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-script-it-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/guava-16.0.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-service-export-3.0.19b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/myfaces-extcdi-bundle-jsf20-1.0.6.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-grs-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-core-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-collections-3.2.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jcl-over-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/resources-codemirror-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/primefaces-extensions-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-batch-3.5.25d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-codec-1.8.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/generated/fc/ file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/xmlsec-1.4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-webapp-3.0.19b-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jgroups-3.1.0.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/resources-ckeditor-0.7.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/cmp-service-export-2.0.20h.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/rewrite-integration-faces-2.0.6.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-web-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/siccservicos-service-export-2.0.31a.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-accesslog-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jboss-logging-3.1.0.GA.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/idq-service-export-2.0.238b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/micap-service-export-2.0.40d.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/httpclient-4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/shiro-ehcache-1.2.2.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/jollyday-0.4.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-jpa-2.0-api-1.0.1.Final.jar file:/var/opGIOP............t/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-security-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-entitymanager-4.2.7.SP1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-agenda-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gcservicos-service-export-2.0.135.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/log4j-over-slf4j-1.7.5.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/public-api-3.6.20e.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/opensaml-1.1.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/app-api-3.0.19b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/classes/ file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-api-3.2.8p.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/hibernate-commons-annotations-4.0.2.Final.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/gfct-webresources-3.5.25d-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/antlr-2.7.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/omnifaces-1.7.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/fraw-messaging-3.2.8p-web-fragment.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/ssn-service-export-2.8.49b.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/httpcore-4.3.jar file:/var/opt/glassfish3/nodes/localhost-domain_gf3_1/instance2/applications/fc/WEB-INF/lib/commons-logging-1.1.1.jar.as...URMI:pt.segsocial.idq.service.export.vo.ParametroVO:EF7D3D9277551DC8:6EAB90E26C3A7990.r f...
...:RMI:java.util.Hashtable:86573568A211C011:13BB0F25214AE4B8.li......s/?@.........

This increases the average size of each message and doesn't provide a way for remote class loading to actually occur, since, generally, the client/server does not have access to the classpath of the gf3 container.

We've implemented a workaround/fix for this issue and saw a reduction in message size of about 75% for small requests/replies.

The workaround is basically the implementation of the following class:

package pt.segsocial.corba;

import java.net.MalformedURLException;
import java.rmi.server.RMIClassLoader;
import java.rmi.server.RMIClassLoaderSpi;

public class CodebaseSpeedupRMIClassLoaderSpi extends RMIClassLoaderSpi {

private RMIClassLoaderSpi defaultProviderInstance;

public CodebaseSpeedupRMIClassLoaderSpi()

{ defaultProviderInstance = RMIClassLoader.getDefaultProviderInstance(); }

@Override
public String getClassAnnotation(Class<?> cl)

{ return null; }

@Override
public Class<?> loadClass(String codebase, String name, ClassLoader defaultLoader) throws MalformedURLException, ClassNotFoundException

{ return defaultProviderInstance.loadClass(codebase, name, defaultLoader); }

@Override
public Class<?> loadProxyClass(String codebase, String[] interfaces, ClassLoader defaultLoader) throws MalformedURLException,
ClassNotFoundException

{ return defaultProviderInstance.loadProxyClass(codebase, interfaces, defaultLoader); }

@Override
public ClassLoader getClassLoader(String codebase) throws MalformedURLException

{ return defaultProviderInstance.getClassLoader(codebase); }

}

and providing a file META-INF/services/java.rmi.server.RMIClassLoaderSpi on the created jar with the contents

pt.segsocial.corba.CodebaseSpeedupRMIClassLoaderSpi

This implementation is based on the documentation at
http://docs.oracle.com/javase/1.5.0/docs/api/java/rmi/server/RMIClassLoader.html
and
http://docs.oracle.com/javase/1.5.0/docs/api/java/rmi/server/RMIClassLoaderSpi.html

Then we place the created jar in $GLASSFISH_HOME/glassfish/modules/endorsed and it works as expected.

Are there any potential pitfalls we should be aware of? What other tests should we account for in this scenario? Why isn't this provided by default?

We also saw that SunOne 8.2 doesn't seem to have this issue, so another question is regarding if this is a bug, a regression or caused by other glassfish corba orb improvments?






[GLASSFISH-21274] EJB container threads carry wrong transactional context Created: 18/Dec/14  Updated: 18/Dec/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0, 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pranahata Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Guys.

I sure there is an issue in the ejb container by which invocations from either batch jobs (@Schedule) or @Asynchronous that happen on threads from the ejb-thread-pool carry stale transactional information.

I have seen things like:

@TransactionAttribute(TransactionAttributeType.NEVER)
@Schedule(minute = "", second = "/10", dayOfMonth = "", month = "", year = "", hour = "", dayOfWeek = "*", persistent = false)
public void cleanupSessions(Timer timer) {

This method only gets invoked by the container and some times, mostly under a bit of load i see things like

Warning: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:357)
at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:251)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4433)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1921)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3990)
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:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Alsoooo.......

I have seen an @Asynchronous method marked as @TransactionAttribute(TransactionAttributeType.NEVER)

calling another @Asynchronous method also marked as @TransactionAttribute(TransactionAttributeType.NEVER)

and the invocation on the second method failing with an error saying the method is marked as NEVER but there is a transasction in progress

It only seems to happen with threds from the ejb thread pool






[GLASSFISH-20727] The value of victim-selection-policy is not output to server.log Created: 26/Jul/13  Updated: 19/Sep/14

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

Type: Bug Priority: Trivial
Reporter: tak09 Assignee: ying.x.hu
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b02-07_24_2013
Windows 7
Java 1.7.0_17



 Description   

The value of victim-selection-policy is not output to server.log.

In the sun-ejb-jar.xml file, you can set victim-selection-policy.
<victim-selection-policy>LRU</victim-selection-policy>

One of these can be set for victim-selection-policy.

  • An invalid value(such as hoge)
  • LRU
  • FIFO
  • NRU

The victim-selection-policy is added in the error message in server.log as shown below.
The issue is that when LRU is set, the value of victim-selection-policy is not written in server.log. In all other cases, the value of victim-selection-policy is written.

When an invalid value is set, [NRU-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:23:20.338+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=114 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1374801800338] [levelValue: 1000] [[
[NRU-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from BACKUPSTORE FOR Key: <[890857700a21f-18914a92-0]>]]

When FIFO is set, [FIFO-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:34:13.335+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=114 _ThreadName=p: thread-pool-1; w: 2] [timeMillis: 1374802453335] [levelValue: 1000] [[
  [FIFO-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18996a3b-1]>]]

When LRU is set, [samples.ejb.stateful.simple.ejb.CartBean]. Why LRU is not displayed?

[2013-07-26T11:41:33.026+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1374802893026] [levelValue: 1000] [[
  [samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18a2a469-0]>]]

When NRU is set, [NRU-samples.ejb.stateful.simple.ejb.CartBean]

[2013-07-26T11:24:49.911+1000] [glassfish 4.0] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1374801889911] [levelValue: 1000] [[
  [NRU-samples.ejb.stateful.simple.ejb.CartBean]: Cannot load from  BACKUPSTORE FOR Key: <[890857700a21f-18914a92-1]>]]

To reproduce the issue,

1.Update stateful-simple.ear\stateful-simpleEjb.jar\META-INF\sun-ejb-jar.xml
Change <victim-selection-policy> to hoge, LRU, FIFO or NRU.

2.Deploy application.
asadmin deploy stateful-simple.ear

3.Run batch file.
run_client.bat

4.Check server.log

5. Undeploy application
asadmin undeploy stateful-simple

6. Repeat Step 1-5



 Comments   
Comment by tak09 [ 26/Jul/13 ]

Please download the test application here.

https://www.dropbox.com/s/q76jns25obt4s02/apps.zip

Test application stateful-simple.ear is contained in \build\assemble\ear

Thank you.





[GLASSFISH-21203] Shared entity Manager on high concurrency Created: 17/Sep/14  Updated: 17/Sep/14

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

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

Windows XP, Oracle 12c



 Description   

Hi I am using GlassFish Server Open Source Edition 3.1.2 (build 23) with Oracle Database 12c Enterprise Edition 12.1.0.1.0 64bit Production. I have in Persistence.xml only (Shared Cache is enabled to all Entities):

<shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
I have observed this while making a remote call to pooled Stateless EJB. can anyone tell me if this is correct or if it is a bug ? It could make sense to think that this drives to a:

[EclipseLink-2004] org.eclipse.persistence.exceptions.ConcurrencyException Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to commit or rollback a transaction before it was started, or to rollback a transaction twice.

I was testing the PersistenceContext propagation to ApplicationScoped CDI Beans, and i have used this 2 implementations, both of them instantiate the EntityManager via @PersistenceContext :

@ApplicationScoped
public class ApplicationScoped1 {...

@Stateless
public class TestFacadeImpl implements TestFacade {
I have printed as (more or less) the following on each call on each Implementation:

JpaEntityManager delegate = (JpaEntityManager) em.getDelegate();
Session activeSession = delegate.getActiveSession();
IdentityMapAccessor identityMapAccessor = activeSession.getIdentityMapAccessor();
LOGGER.info("delegate: " + delegate);
LOGGER.info("identityMapAccessor: " + identityMapAccessor);
TestFacadeImpl is triggered in parallel remotely from a client, and log delegate and identityMapAccessor.

I divide the results in 3 chunks

First Fine, not really parallel, Propagation Fine and each thread has his EntityManagerImpl instance and UnitOfWorkIdentityMapAccessor (can say that is L1/WorkUnit Cache right)

2014-09-09 10:22:20.997 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@5b86a92d (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:20.997 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@65ccf84c (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.003 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@5b86a92d (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.004 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@65ccf84c (com.foo.blah..impl.systemtests.ApplicationScoped1)

2014-09-09 10:22:21.009 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@4fff8693 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.009 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@10dc45ed (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.015 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@4fff8693 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.016 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@10dc45ed (com.foo.blah..impl.systemtests.ApplicationScoped1)
Second Fine, In the same millisecond each Thread has his own EntityManagerImpl and UnitOfWorkIdentityMapAccessor

2014-09-09 10:22:21.051 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@2b917db5 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.052 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@657b7469 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.051 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@5cd40c6b (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.052 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@c17cd8c (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.057 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2b917db5 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.057 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@5cd40c6b (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.058 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@657b7469 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.058 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@c17cd8c (com.foo.blah..impl.systemtests.ApplicationScoped1)
Third, a bit strange, 2 Threads from the EJB pool get the same EntityManagerImpl and 2 different UnitOfWorkIdentityMapAccessor

2014-09-09 10:22:21.075 INFO 36 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 37 delegate Trigger : org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 36 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@28af5636 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.075 INFO 37 identityMapAccessor Trigger: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@f450818 (com.foo.blah..impl.systemtests.TestFacadeImpl)
2014-09-09 10:22:21.081 INFO 37 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 36 delegate: org.eclipse.persistence.internal.jpa.EntityManagerImpl@6d198dd7 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 37 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@f450818 (com.foo.blah..impl.systemtests.ApplicationScoped1)
2014-09-09 10:22:21.081 INFO 36 identityMapAccessor: org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor@28af5636 (com.foo.blah..impl.systemtests.ApplicationScoped1)






[GLASSFISH-21167] Resource injection not working when empty <absoluteOrdering> is used in web.xml, for classes packed as jars in lib folder Created: 20/Aug/14  Updated: 08/Sep/14

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: 4.0
Fix Version/s: None

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

OS: Windows 7 64bit. Java: 7u67 (also 7u51, 8u11).
Glassfish: 4.0, 4.1-b12 (nightly build)



 Description   

Resource injection does not work, in EJBs of an application (in war format), when these 2 conditions are both met:

1) The application uses, in web.xml file, an empty <absoluteOrdering> tag
2) The code (classes) of the application are all packed as jar archives in the [war]\WEB-INF\lib\ folder, instead of included them unpacked in the [war]\WEB-INF\classes\ folder

(purpose for doing this:

  • 1: for disabling altogether the scanning for web-fragment.xml files in all of the included library jar files, as not necessary;
  • 2: for applications with a big codebase, which is structured in separate modules, easy to pack as separate jars)

When the 2 conditions are met, resource injection does not work.
This is visible for example in EJBs marked with @Singleton @Startup, which have fields marked with @EJB or @Resource:

  • the Singleton beans are identified and constructed by the container
  • then resource injection for fields is skipped ?
  • then the methods marked with @PostConstruct are identified and called, but they may result in NullPointerException if using the fields expected to be injected by now.

If any of the 2 conditions is changed (either remove <absoluteOrdering/> tag OR include the ejb classes unpacked, in the WEB-INF\classes folder), injection works as it should.

This works well on older Glassfish 3.1.2.2 version.
Fails on 4.0 version; also tested on latest promoted nightly build, 4.1-b12, and still fails.



 Comments   
Comment by cristim1979 [ 20/Aug/14 ]

Test example:

1) Have a simple application with just 2 Singleton EJBs:
TestSingleton1.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import javax.ejb.EJB;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TimerService;

@Singleton
@Startup
public class TestSingleton1 {
    @Resource
    public TimerService timerService;
    @EJB
    public TestSingleton2 testSingleton2;

    public TestSingleton1() {
        System.out.println("In TestSingleton1 constructor: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }

    @PostConstruct
    public void init() {
        System.out.println("In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }
}

TestSingleton2.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;

@Singleton
public class TestSingleton2 {
    public TestSingleton2() {
        System.out.println("TestSingleton2 constructor called.");
    }

    @PostConstruct
    public void init() {
        System.out.println("TestSingleton2 @PostConstruct method called.");
    }
}

2) Define also a web.xml file for the app:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <!-- Just to ignore / not scan any web-fragment.xml files from jar files -->
    <absolute-ordering/>

</web-app>

3) Compile classes and pack the application as a war with this structure:

  • [test_app.war] (exploded, as folder)
    • in WEB-INF folder: the web.xml file
    • in WEB-INF\lib\ folder: a jar archive, test_app.jar, containing the compiled singleton classes

Testing:
Deploy the test application war on GF 4.0, and check console/log output related to the test singletons:

a) Incorrect output - when run on current GF 4.0 (note the null values on last line):

  EJB5181:Portable JNDI names for EJB TestSingleton1: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1!com.spmsoftware.test.TestSingleton1, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1]
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  EJB5181:Portable JNDI names for EJB TestSingleton2: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2!com.spmsoftware.test.TestSingleton2, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2]
  TestSingleton2 constructor called.
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=null; @EJB testSingleton2=null

b) Correct output - when run on GF 3.1.2.2 (or on GF 4 with one of the 2 conditions changed) - similar, except for the last line:

  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=com.sun.ejb.containers.EJBTimerServiceWrapper@7ec0c910; @EJB testSingleton2=com.spmsoftware.test.TestSingleton2@22d07a73
Comment by cristim1979 [ 08/Sep/14 ]

Any update on this / any plans to handle it in 4.1 release ?





[GLASSFISH-21186] EJB Timer cannot mirgrate correctly Created: 07/Sep/14  Updated: 07/Sep/14

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

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

Debian 7.5 64bit
JDK 7 u51 64bit
Glassfish 4.1 b13



 Description   

I setup a cluster include 2 instances : instance1 and instance2

When I start cluster, EJB Timer run on instance2, when I stop instance2, default EJB Timer will change to instance1 automatically, but when I trace log from instance1, it show below:

[2014-09-07T12:03:20.720+0700] [glassfish 4.1] [INFO] [view.window.view.change] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200720] [levelValue: 800] [[
GMS1092: GMS View Change Received for group: gbcluster : Members in view for PEER_STOP_EVENT(before change analysis) are :
1: MemberId: instance1, MemberType: CORE, Address: 10.43.3.10:10032:228.9.3.1:2048:gbcluster:instance1
2: MemberId: server, MemberType: SPECTATOR, Address: 10.43.3.16:10049:228.9.3.1:2048:gbcluster:server
]]

[2014-09-07T12:03:20.721+0700] [glassfish 4.1] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200721] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: PEER_STOP_EVENT for member: instance2 of group: gbcluster]]

[2014-09-07T12:03:20.721+0700] [glassfish 4.1] [INFO] [plannedshutdownevent.announcement] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200721] [levelValue: 800] [[
GMS1017: Received PlannedShutdownEvent Announcement from member: instance2 with shutdown type: INSTANCE_SHUTDOWN of group: gbcluster]]

[2014-09-07T12:03:20.723+0700] [glassfish 4.1] [INFO] [plannedshutdownsignals.send.member] [ShoalLogger] [tid: _ThreadID=22 _ThreadName=GMS SignalHandler for Group-gbcluster thread] [timeMillis: 1410066200723] [levelValue: 800] [[
GMS1008: Sending PlannedShutdownSignals to registered Actions for shutdownType INSTANCE_SHUTDOWN member: instance2 ...]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200725] [levelValue: 800] [[
[DistributedEJBTimerService] migrating timers from instance2]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [ShoalLogger] [tid: _ThreadID=62 _ThreadName=GMS-processNotify-Group-gbcluster-thread-3] [timeMillis: 1410066200725] [levelValue: 800] [[
**VIEW: prevViewId: 2; curViewID: 3; signal: com.sun.enterprise.ee.cms.impl.common.PlannedShutdownSignalImpl@1e749200 [current: instance1] [previous: instance1, instance2]]]

[2014-09-07T12:03:20.725+0700] [glassfish 4.1] [INFO] [] [ShoalLogger] [tid: _ThreadID=62 _ThreadName=GMS-processNotify-Group-gbcluster-thread-3] [timeMillis: 1410066200725] [levelValue: 800] [[
**********************************************************************]]

[2014-09-07T12:03:20.726+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200726] [levelValue: 800] [[
Beginning timer migration process from owner instance2 to instance1]]

[2014-09-07T12:03:20.816+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200816] [levelValue: 800] [[
Timer migration phase 1 complete. Changed ownership of 2 timers. Now reactivating timers...]]

[2014-09-07T12:03:20.818+0700] [glassfish 4.1] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=60 _ThreadName=GMS-processNotify-Group-gbcluster-thread-1] [timeMillis: 1410066200818] [levelValue: 800] [[
Rescheduling missed expiration for periodic timer '1@@1410066146328@@instance2@@instance2' 'TimedObject = IpoScheduleGbJobEJB' 'Application = gbeearipo' 'CREATED' 'PERIODIC' 'Container ID = 92405000009744396' 'Sun Sep 07 12:02:26 ICT 2014' '500' . Last timer expiration occurred at Sun Sep 07 12:03:16 ICT 2014]]


Result is EJB Timer cannot active on instance1

I also trace log on instance2:
[2014-09-07T12:03:16.779+0700] [glassfish 4.1] [INFO] [AS_ACDEPL-00104] [javax.enterprise.system.container.appclient] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066196779] [levelValue: 800] [[
Java Web Start services stopped for the app client gbear/eclipselink.jar]]

[2014-09-07T12:03:17.199+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbear/gbeejb_jar/_gbePU.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197199] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbear/gbeejb_jar/_gbePU logout successful]]

[2014-09-07T12:03:17.216+0700] [glassfish 4.1] [INFO] [AS_ACDEPL-00104] [javax.enterprise.system.container.appclient] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197216] [levelValue: 800] [[
Java Web Start services stopped for the app client gbeearipo/eclipselink.jar]]

[2014-09-07T12:03:17.400+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbeearipo/ipoejb_jar/_gbeipoPU.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197400] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/gbeearipo/ipoejb_jar/_gbeipoPU logout successful]]

[2014-09-07T12:03:17.433+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197433] [levelValue: 800] [[
file:/home/gbsofts/glassfish4/glassfish/nodes/srv2.gbsofts.com/instance2/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App logout successful]]

[2014-09-07T12:03:17.439+0700] [glassfish 4.1] [INFO] [ejb.timer_service_shutdown_msg] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=12622 _ThreadName=RunLevelControllerThread-1410066190958] [timeMillis: 1410066197439] [levelValue: 800] [[
EJB5122:EJB Timer Service shutdown at [2014/09/07 12:03:17]]]

[2014-09-07T12:03:17.455+0700] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=12622 _ThreadName=Thread-8] [timeMillis: 1410066197455] [levelValue: 800] [[
JdbcRuntimeExtension, getAllSystemRAResourcesAndPools = [GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcConnectionPool, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource, GlassFishConfigBean.org.glassfish.jdbc.config.JdbcResource]]]

[2014-09-07T12:03:17.477+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12694 _ThreadName=Thread-157] [timeMillis: 1410066197477] [levelValue: 800] [[
RAR7094: __xa_jdbc_ra shutdown successful.]]

[2014-09-07T12:03:17.477+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12695 _ThreadName=Thread-158] [timeMillis: 1410066197477] [levelValue: 800] [[
RAR7094: __ds_jdbc_ra shutdown successful.]]

[2014-09-07T12:03:17.478+0700] [glassfish 4.1] [INFO] [] [javax.resourceadapter.mqjmsra.lifecycle] [tid: _ThreadID=12698 _ThreadName=Thread-160] [timeMillis: 1410066197478] [levelValue: 800] [[
MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter stopping...]]

[2014-09-07T12:03:20.695+0700] [glassfish 4.1] [INFO] [] [javax.resourceadapter.mqjmsra.lifecycle] [tid: _ThreadID=12698 _ThreadName=Thread-160] [timeMillis: 1410066200695] [levelValue: 800] [[
MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter stopped.]]

[2014-09-07T12:03:20.696+0700] [glassfish 4.1] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=12693 _ThreadName=Thread-156] [timeMillis: 1410066200696] [levelValue: 800] [[
RAR7094: jmsra shutdown successful.]]

[2014-09-07T12:03:20.696+0700] [glassfish 4.1] [INFO] [NCLS-CLSTR-10108] [javax.enterprise.cluster.gms] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200696] [levelValue: 800] [[
GMSAdapter for member: instance2 group: gbcluster received GlassfishEventType: server_shutdown]]

[2014-09-07T12:03:20.697+0700] [glassfish 4.1] [INFO] [gms.leave] [ShoalLogger] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200697] [levelValue: 800] [[
GMS1096: member: instance2 is leaving group: gbcluster]]

[2014-09-07T12:03:20.697+0700] [glassfish 4.1] [INFO] [shutdown.instanceshutdown] [ShoalLogger] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200697] [levelValue: 800] [[
GMS1010: Leaving GMS group: gbcluster with shutdown type set to InstanceShutdown]]

[2014-09-07T12:03:20.698+0700] [glassfish 4.1] [CONFIG] [mgmt.masternode.processmsgcompleted] [ShoalLogger] [tid: _ThreadID=55 _ThreadName=GMS MasterNode processOutstandingChangeEvents Group-gbcluster] [timeMillis: 1410066200698] [levelValue: 700] [[
GMS1065: Completed processing outstanding master node messages for member: instance2 group: gbcluster outstandingMessages to process: 0]]

[2014-09-07T12:03:20.701+0700] [glassfish 4.1] [INFO] [] [ShoalLogger.monitor] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200701] [levelValue: 800] [[
BlockingIOMulicastSender monitoring stats: received: 256 core poolsize:10 largest pool size:10 task count:256 max queue size:0 rejected execution:0]]

[2014-09-07T12:03:20.701+0700] [glassfish 4.1] [INFO] [mgmt.blockingiomulticast.threadcomplete] [ShoalLogger] [tid: _ThreadID=53 _ThreadName=IP Multicast Listener for /228.9.3.1:2048] [timeMillis: 1410066200701] [levelValue: 800] [[
GMS1110: Thread IP Multicast Listener for /228.9.3.1:2048 has completed.]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [router.stats.monitor.msgqueue.high.water] [ShoalLogger.monitor] [tid: _ThreadID=12618 _ThreadName=Thread-82] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1115: router signal queue high water mark: 0 signal queue capacity: 600]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [sig.handler.thread.terminated] [ShoalLogger] [tid: _ThreadID=22 _ThreadName=GMS SignalHandler for Group-gbcluster thread] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1107: SignalHandler task named GMS SignalHandler for Group-gbcluster thread exiting]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [view.window.thread.terminated] [ShoalLogger] [tid: _ThreadID=23 _ThreadName=GMS ViewWindowThread Group-gbcluster] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1091: View Window event processing thread for group: gbcluster terminated normally]]

[2014-09-07T12:03:20.704+0700] [glassfish 4.1] [INFO] [msg.wdw.thread.terminated] [ShoalLogger] [tid: _ThreadID=24 _ThreadName=GMS MessageWindowThread Group-gbcluster] [timeMillis: 1410066200704] [levelValue: 800] [[
GMS1088: MessageWindow thread for group: gbcluster terminated due to shutdown notification]]

How can I resolve this problem?






[GLASSFISH-20899] @PrePassivate / @PostActivate get called on every bean invocation when Availability is enabled Created: 14/Nov/13  Updated: 24/Aug/14

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

Type: Bug Priority: Critical
Reporter: lprimak Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ALL


Tags: availability, ejb, sfsb

 Description   

When running on GF 3.1, everything works fine,
but when upgraded to GF 4.0, @Stateful bean's @PrePassivate / @PostActivate
calls get invoked for every bean method invocation, which isn't good

This only happens when Availability is enabled for the application.
When it's not, everything works fine as well.



 Comments   
Comment by lprimak [ 19/Nov/13 ]

When using passivationCapable = false, the behavior is correct,
leading me to believe that this is a simple bug vs. ejb spec issue

Comment by lprimak [ 19/Nov/13 ]

Related Issue:
https://java.net/jira/browse/EJB_SPEC-116

Comment by lprimak [ 19/Nov/13 ]

Also, transient fields get lost on failover in GF 4.0:

@Stateful
public class MyBean implements Serializable
{
private String myState;
private final transient Set<String> myTransient = new HashSet<>();
}

When HA-failover happens to a copy of MyBean on another cluster node,
myTransient is null

which is a regression from GF 3.1 and is how I found this error in the first place

Comment by marina vatkina [ 19/Nov/13 ]

When passivationCapable = false the HA is not happening - see EJB 3.2 spec for the warning

Comment by lprimak [ 20/Nov/13 ]

Also, in the code above, the SFSB implements Serializable.
This is related to another issue with Glassfish.
SFSBs should not have to implement Serializable. But, in HA, if they don't another exception is thrown.

Related JIRA:
https://java.net/jira/browse/GLASSFISH-20892

Comment by lprimak [ 24/Aug/14 ]

How does this relate to this bug?
https://java.net/jira/browse/GLASSFISH-20318
According to that bug non-serializable SFSB should work,
Does this deal with transient fields correctly?

Comment by lprimak [ 24/Aug/14 ]

This is not completely fixed. As of GF 4.1 August 21, 2014,
when trying to access not-serializable SFSBs in Availability HA cluster configuration,
I get the exceptions below:
Related issues:
https://java.net/jira/browse/GLASSFISH-20892
https://java.net/jira/browse/GLASSFISH-20899
---------------------------
[2014-08-24T15:36:28.304-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988304] [levelValue: 900] [[
javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]
[2014-08-24T15:36:28.307-0400] [glassfish 4.1] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988307] [levelValue: 1000] [[
Error Rendering View[/index.xhtml]
javax.el.ELException: /resources/templates/layout.xhtml @194,60 rendered="#

{layout.statsEnabled}

": javax.ejb.EJBException
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:114)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.el.ELException: javax.ejb.EJBException
at javax.el.BeanELResolver.getValue(BeanELResolver.java:368)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
... 92 more
Caused by: javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:515)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1853)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
... 99 more
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 107 more
]]
[2014-08-24T15:36:28.338-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=99 _ThreadName=ajp-listener-1(5)] [timeMillis: 1408908988338] [levelValue: 900] [[
StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.flowlogix.security.ShiroSecurityInterceptor.propagateShiroSecurity(ShiroSecurityInterceptor.java:64)
at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.isDisableStats(Unknown Source)
at com.baw.website.beans.ui.layout.Layout.isStatsEnabled(Layout.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:457)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:852)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:56)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:130)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.filters.EjbPingFilter.doFilter(EjbPingFilter.java:44)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:115)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:90)
at com.flowlogix.security.WebSecurityFilter$1.call(WebSecurityFilter.java:84)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at com.flowlogix.security.WebSecurityFilter.doFilter(WebSecurityFilter.java:83)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.baw.website.filters.ShiroInitFilter.doFilter(ShiroInitFilter.java:41)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:77)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:175)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]
[2014-08-24T15:36:39.431-0400] [glassfish 4.1] [SEVERE] [AS-EJB-00004] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999431] [levelValue: 1000] [[
[NRU-com.baw.website.beans.sfsb.impl.SharedWebstats]: Cannot load from BACKUPSTORE FOR Key: <[1f00900a0983b5c6-ee0001103a22bcb3-1]>]]
[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[
A system exception occurred during an invocation on EJB SharedWebstats, method: public void com.baw.website.beans.sfsb.impl.SharedWebstats.ping()]]
[2014-08-24T15:36:39.432-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=97 _ThreadName=ajp-listener-1(3)] [timeMillis: 1408908999432] [levelValue: 900] [[
javax.ejb.NoSuchObjectLocalException: The EJB does not exist. session-key: 1f00900a0983b5c6-ee0001103a22bcb3-1
at com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1626)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2579)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1971)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy798.ping(Unknown Source)
at com.flowlogix.ejb.StatefulUtil.pingStateful(StatefulUtil.java:68)
at com.flowlogix.web.services.EjbModule$1.service(EjbModule.java:46)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.got5.tapestry5.jquery.services.AjaxUploadServletRequestFilter.service(AjaxUploadServletRequestFilter.java:27)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:56)
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:54)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54)
at $HttpServletRequestFilter_584822218a2dab.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_584822218a2d9e.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
at $HttpServletRequestHandler_584822218a2dad.service(Unknown Source)
at $HttpServletRequestHandler_584822218a2d9d.service(Unknown Source)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
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:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]





[GLASSFISH-21162] Future.get() Doesn't block Created: 11/Aug/14  Updated: 11/Aug/14

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

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

NetBeans 8 and JDK 1.8.0_11 and Glassfish 4.1 promoted build 11 on Win8.1 Pro 64

&

JDK 1.8.0_11 and Glassfish 4.1 promoted build 11 on Ubuntu 14.04



 Description   

Code Snippet Below.

When I call (A) refresh from another class using @Schedule (in my ejb) the value of count in refresh is correct and statement (B.1) executes before (A.1).

However, when I call (A) refresh from an @ApplicationScoped bean (in my war) the value of count in refresh is incorrect and statement (A.1) executes before (B.1). Most of the time (B.1) doesn't execute at all. In this scenario count always has a different count.

No exception is thrown.

Method that kicks off the process
(A) public void refresh(String usr)

{ // ... count = count + processRelatedProjectData(); //... logger.log(Level.INFO, "\tExit refresh"); <-- Last statement before exit (A.1) }

Method that uses the @Asynchronous methods
(B) private Integer processRelatedProjectData() {

Future futureA = processProject.processData(Constant.COMPANY_A);
Future futureB = processProject.processData(Constant.COMPANY_B);
Future futureC = processProject.processData(Constant.COMPANY_C);
//... A bunch of these

try

{ count = count + (Integer) futureA.get(); count = count + (Integer) futureB.get(); count = count + (Integer) futureC.get(); //... A bunch of these }

catch (InterruptedException | ExecutionException | CancellationException ex)

{ throw new IllegalStateException("Cannot get the answer", ex); }

logger.log(Level.INFO, "\tEnter processRelatedProjectData"); <-- Last statement before exit (B.1)
}






[GLASSFISH-21157] RuntimeException in TimerService Created: 07/Aug/14  Updated: 07/Aug/14

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

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

Mac OS X, Java EE 7



 Description   

When a system exception occurs during invocation of an EJB (Stateless / Singleton) TimerService, it is discarded and TimerService is not loaded again.

Example:

import java.util.logging.Logger;

import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

@Startup
@Singleton
public class TestTimerService {

/**

  • LOG
    */
    private static final Logger LOG = Logger.getLogger(TestTimerService.class.getName());

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@Schedule(minute = "/1", hour = "", persistent = false)
public void schedule()

{ LOG.info("Timer test............"); Integer.valueOf(1 / 0); // Force RuntimeException }

}

}






[GLASSFISH-21156] Allow disabling iiop-service when MDBs present Created: 06/Aug/14  Updated: 06/Aug/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

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

Glassfish 4.0
Java 7u40



 Description   

Currently it is not possible to deploy an MDB and disable all iiop listeners.

This happens due to the following line;

http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.main.ejb/ejb-full-container/4.0/org/glassfish/ejb/mdb/MessageBeanContainer.java#167

I am not sure if iiop is deemed a hard dependency of mdbs as issues such as GLASSFISH-12669 have brought it up in the past but been closed. If this is the case feel free to close the issue.






[GLASSFISH-21132] java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory in case when persistence.xml inside EJB module Created: 16/Jul/14  Updated: 18/Jul/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: alexander.v.morozov Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1 Pro x64, JDK 7u13 x64, Maven 3.1



 Description   

I have very strange exception in out EE applications, then persistence.xml resides in EJB-jar. I use CDI+EJB in dev environment and qualifies each EntityManager with own CDI qualifer. If I make EntityManager producer bean EJB-bean (@Stateless), every works fine, but if I change it to Managed Bean (@ApplicationScoped) - got the exception below.

Sample application is attached. Have both maven profiles "glassfish3" and "glassfish4".

javax.ejb.EJBException: null
	at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5113) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4915) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2045) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.proxy.$Proxy178.process(Unknown Source) [na:na]
	at my.domain.application.__EJB31_Generated__TimerBean__Intf____Bean__.process(Unknown Source) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at my.domain.application.TimerBean.onTimeout(TimerBean.java:42) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49) [weld-osgi-bundle.jar:20120429-1045]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4058) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1832) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2646) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_15]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [na:1.7.0_15]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [na:1.7.0_15]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_15]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_15]
	at java.lang.Thread.run(Thread.java:722) [na:1.7.0_15]
Caused by: java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory for unitName ModulePU
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.init(EntityManagerWrapper.java:132) ~[container-common.jar:3.1.2.1-SNAPSHOT]
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.getEntityManagerFactory(EntityManagerWrapper.java:875) ~[container-common.jar:3.1.2.1-SNAPSHOT]
	at my.mydomain.module.ModuleEntityManagerProducer.getEntityManager(ModuleEntityManagerProducer.java:21) ~[module-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) ~[na:na]
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) ~[na:na]
	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:137) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ProducerMethod$ProducerMethodProducer.produce(ProducerMethod.java:136) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:319) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:307) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) ~[na:na]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134) ~[weld-integration.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90) ~[weld-osgi-bundle.jar:20120429-1045]
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) ~[weld-osgi-bundle.jar:20120429-1045]
	at my.mydomain.module.JpaDomainRepository$Proxy$_$$_WeldClientProxy.add(JpaDomainRepository$Proxy$_$$_WeldClientProxy.java) ~[module-ejb-1.0-SNAPSHOT_jar/:na]
	at my.domain.application.TimerBean.process(TimerBean.java:51) [application-ejb-1.0-SNAPSHOT_jar/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:42) [weld-osgi-bundle.jar:20120429-1045]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_15]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_15]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_15]
	at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_15]
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214) [ejb-container.jar:3.1.2.1-SNAPSHOT]
	... 43 common frames omitted



 Comments   
Comment by alexander.v.morozov [ 16/Jul/14 ]

Sample application archive is here https://www.sendspace.com/file/dra7f2





[GLASSFISH-21135] EJB TimerThread dies on RejectedExecutionException from EJB thread pool Created: 18/Jul/14  Updated: 18/Jul/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

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


 Description   

If there are not enough threads in the EJB thread pool, EJB Timers (non persistent?) stop to be executed.
The problem is that the EJB timer thread dies when RejectedExecutionException is thrown.
This happens in com.sun.ejb.containers.EJBTimerService#taskExpired method. The call ejbContainerUtil.addWork(work); does not catch RejectedExecutionException and it kills the thread. After that no EJB timer is executed. The solution would be to surround the code with an appropriate try-catch and log a warning.
We observed this bug on 3.1.2.2. But in 4.0 the code did not change, so I assume that the problem exists in 4.0 as well.






[GLASSFISH-21072] NullPointerException at com.sun.enterprise.resource.pool.PoolManagerImpl.handleLazilyAssociatedConnectionPools(PoolManagerImpl.java:623) Created: 26/May/14  Updated: 13/Jun/14

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

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


 Description   

We have a message processing application that receives messages via a message queue.
So there is a MDB that receives messages from this queue and forwards them to a singleton EJB for further processing.

Transactions:
MDB: @TransactionManagement(TransactionManagementType.BEAN)
Singleton EJB: @ConcurrencyManagement(ConcurrencyManagementType.BEAN)

After a few hours of load testing we continuously get exceptions in GF when MDB invokes a local call to Singleton EJB (MDB00037). After that the JMS message redelivered (MQJMSRA_MR2001) is received.

Exception snippet:
=============================================================================

[#|2014-05-23T12:01:16.698+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=752;_ThreadName=Thread-2;|MDB00037: [ht-ear-2.7.0-SNAPSHOT-PRETTY-7527:ObdMessageBean]: Message-driven bean invocation exception: [javax.ejb.EJBException]|#]

[#|2014-05-23T12:01:16.699+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=752;_ThreadName=Thread-2;|javax.ejb.EJBException
javax.ejb.EJBException
at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215)
at com.sun.ejb.containers.BaseContainer.checkExceptionNoTx(BaseContainer.java:5044)
at com.sun.ejb.containers.BaseContainer.checkExceptionBeanMgTx(BaseContainer.java:4965)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4865)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1211)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1186)
at com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:86)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:190)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.resource.pool.PoolManagerImpl.handleLazilyAssociatedConnectionPools(PoolManagerImpl.java:623)
at com.sun.enterprise.resource.pool.PoolManagerImpl.postInvoke(PoolManagerImpl.java:601)
at com.sun.enterprise.resource.pool.PoolManagerImpl.afterPostInvoke(PoolManagerImpl.java:580)
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:220)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2021)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
at com.sun.proxy.$Proxy566.receiveMessages(Unknown Source)
at com.ht.ms.obd.ObdMessageBean.processMessage(ObdMessageBean.java:115)
at com.ht.ms.obd.ObdMessageBean.onMessage(ObdMessageBean.java:70)
at sun.reflect.GeneratedMethodAccessor1959.invoke(Unknown Source)
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:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
... 5 more

#]

[#|2014-05-23T12:01:16.702+0200|INFO|glassfish3.1.2|com.ht.message.logic.MessageValidationBean|_ThreadID=679;_ThreadName=Thread-2;|Validating message Message[id=12792, obdId=null]|#]

[#|2014-05-23T12:01:16.703+0200|INFO|glassfish3.1.2|com.ht.logic.equipmentdetection.EquipmentDetectionProcessorBean|_ThreadID=679;_ThreadName=Thread-2;|No equipment processing for Message[id=12792], does not contain equipment couple info.|#]

[#|2014-05-23T12:01:16.704+0200|INFO|glassfish3.1.2|com.ht.logic.message.MessageProcessorBean|_ThreadID=679;_ThreadName=Thread-2;|Finished processing of Message[id=12792, obdId=null]|#]

[#|2014-05-23T12:01:16.701+0200|WARNING|glassfish3.1.2|javax.resourceadapter.mqjmsra.inbound.message|_ThreadID=752;_ThreadName=Thread-2;|MQJMSRA_MR2001: run:Caught Exception from onMessage():Redelivering:
javax.ejb.EJBException: message-driven bean method public abstract void javax.jms.MessageListener.onMessage(javax.jms.Message) system exception
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1134)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.resource.pool.PoolManagerImpl.handleLazilyAssociatedConnectionPools(PoolManagerImpl.java:623)
at com.sun.enterprise.resource.pool.PoolManagerImpl.postInvoke(PoolManagerImpl.java:601)
at com.sun.enterprise.resource.pool.PoolManagerImpl.afterPostInvoke(PoolManagerImpl.java:580)
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:220)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2021)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1994)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
at com.sun.proxy.$Proxy566.receiveMessages(Unknown Source)
at com.ht.ms.obd.ObdMessageBean.processMessage(ObdMessageBean.java:115)
at com.ht.ms.obd.ObdMessageBean.onMessage(ObdMessageBean.java:70)
at sun.reflect.GeneratedMethodAccessor1959.invoke(Unknown Source)
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:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
... 7 more

#]
=============================================================================


 Comments   
Comment by alebor [ 27/May/14 ]

Environment: CentOS release 6.4 (Final), Glassfish 3.1.2.2

Comment by alebor [ 11/Jun/14 ]

I have created a patch on

PoolManagerImpl.java

(connectors-runtime in https://svn.java.net/svn/glassfish~svn/tags/3.1.2.2-no-delete) to avoid this NullPointerException.

The lazy connection disassociation is skipped in case ResourceHandle or ResourceSpec (from ResourceHandle) are NULL.

PATCH START
===========

Index: PoolManagerImpl.java
===================================================================
--- PoolManagerImpl.java	(revision 63349)
+++ PoolManagerImpl.java	(working copy)
@@ -41,41 +41,48 @@
 package com.sun.enterprise.resource.pool;
 
 import com.sun.appserv.connectors.internal.api.ConnectorConstants.PoolType;
-import org.glassfish.resource.common.PoolInfo;
+import com.sun.appserv.connectors.internal.api.ConnectorRuntime;
 import com.sun.appserv.connectors.internal.api.PoolingException;
-import com.sun.appserv.connectors.internal.api.ConnectorRuntime;
 import com.sun.appserv.connectors.internal.spi.MCFLifecycleListener;
+import com.sun.enterprise.connectors.ConnectorConnectionPool;
 import com.sun.enterprise.connectors.ConnectorRegistry;
 import com.sun.enterprise.deployment.ResourceReferenceDescriptor;
 import com.sun.enterprise.resource.ClientSecurityInfo;
+import com.sun.enterprise.resource.ResourceHandle;
 import com.sun.enterprise.resource.ResourceSpec;
-import com.sun.enterprise.resource.ResourceHandle;
 import com.sun.enterprise.resource.allocator.ResourceAllocator;
 import com.sun.enterprise.resource.listener.PoolLifeCycle;
-import com.sun.enterprise.resource.rm.*;
+import com.sun.enterprise.resource.rm.LazyEnlistableResourceManagerImpl;
+import com.sun.enterprise.resource.rm.NoTxResourceManagerImpl;
+import com.sun.enterprise.resource.rm.ResourceManager;
+import com.sun.enterprise.resource.rm.ResourceManagerImpl;
+import com.sun.enterprise.resource.rm.SystemResourceManagerImpl;
 import com.sun.enterprise.transaction.api.JavaEETransaction;
 import com.sun.enterprise.transaction.api.JavaEETransactionManager;
+import com.sun.enterprise.util.i18n.StringManager;
 import com.sun.logging.LogDomains;
-import org.jvnet.hk2.annotations.Service;
-import org.jvnet.hk2.annotations.Inject;
-import org.jvnet.hk2.component.Habitat;
-import org.glassfish.api.invocation.InvocationException;
-import org.glassfish.api.invocation.ComponentInvocation;
-import org.glassfish.api.invocation.ComponentInvocationHandler;
-import com.sun.enterprise.connectors.ConnectorConnectionPool;
-
+import java.util.ArrayList;
+import java.util.Hashtable;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+import javax.resource.ResourceException;
+import javax.resource.spi.ManagedConnection;
 import javax.resource.spi.ManagedConnectionFactory;
 import javax.resource.spi.RetryableUnavailableException;
+import javax.transaction.Synchronization;
 import javax.transaction.Transaction;
-import javax.transaction.Synchronization;
 import javax.transaction.xa.XAResource;
-import javax.resource.spi.ManagedConnection;
-import javax.resource.ResourceException;
-import java.util.*;
-import java.util.concurrent.ConcurrentHashMap;
-import java.util.logging.Level;
-import java.util.logging.Logger;
-import com.sun.enterprise.util.i18n.StringManager;
+import org.glassfish.api.invocation.ComponentInvocation;
+import org.glassfish.api.invocation.ComponentInvocationHandler;
+import org.glassfish.api.invocation.InvocationException;
+import org.glassfish.resource.common.PoolInfo;
+import org.jvnet.hk2.annotations.Inject;
+import org.jvnet.hk2.annotations.Service;
+import org.jvnet.hk2.component.Habitat;
 
 /**
  * @author Tony Ng, Aditya Gore
@@ -204,7 +211,7 @@
             if (handle.getResourceState().isUnenlisted()) {
                 //The spec being used here is the spec with the updated
                 //lazy enlistment info
-                //Here's the real place where we care about the correct 
+                //Here's the real place where we care about the correct
                 //resource manager (which in turn depends upon the ResourceSpec)
                 //and that's because if lazy enlistment needs to be done
                 //we need to get the LazyEnlistableResourceManager
@@ -369,7 +376,7 @@
     public void unregisterPoolLifeCycleListener() {
         listener = null;
     }
-    
+
     public void unregisterResource(com.sun.appserv.connectors.internal.api.ResourceHandle resource, int xaresFlag) {
         ResourceHandle h = (ResourceHandle)resource;
         ResourceManager rm = getResourceManager(h.getResourceSpec());
@@ -513,7 +520,7 @@
                }
            }
        }
-    
+
     public ResourceReferenceDescriptor getResourceReference(String jndiName, String logicalName) {
         Set descriptors = getConnectorRuntime().getResourceReferenceDescriptor();
         List matchingRefs = new ArrayList();
@@ -617,10 +624,24 @@
 
         if (list.size() == 0) return;
 
-        ResourceHandle[] handles = (ResourceHandle[]) list.toArray(
-                new ResourceHandle[0]);
+        ResourceHandle[] handles = (ResourceHandle[]) list.toArray(new ResourceHandle[list.size()]);
+
         for (ResourceHandle h : handles) {
+            if (h == null) {
+                if (_logger.isLoggable(Level.INFO)) {
+                    _logger.info("Skipping lazy connection disassociation due to RecourceHandle: null");
+                }
+                continue;
+            }
+
             ResourceSpec spec = h.getResourceSpec();
+            if (spec == null) {
+                if (_logger.isLoggable(Level.INFO)) {
+                    _logger.info("Skipping lazy connection disassociation due to Recource Spec: null");
+                }
+                continue;
+            }
+
             if (spec.isLazyAssociatable()) {
                 //In this case we are assured that the managedConnection is
                 //of type DissociatableManagedConnection
@@ -675,11 +696,11 @@
         ResourcePool pool = getPool( poolInfo );
         if (pool != null ) {
             pool.reconfigurePool( ccp );
-        }        
+        }
     }
 
     /**
-     * Flush Connection pool by reinitializing the connections 
+     * Flush Connection pool by reinitializing the connections
      * established in the pool.
      * @param poolInfo
      * @throws com.sun.appserv.connectors.internal.api.PoolingException

===========
PATCH END

Does anyone know if this is sufficient to get rid of this NPE?
Maybe the side effects?

Please let me know.





[GLASSFISH-21088] EJB invocations from a JBatch ChunkStep bundled within an EAR are incorrectly cast as SERVLET_INVOCATIONs within EntityManagerFactoryWrapper Created: 12/Jun/14  Updated: 12/Jun/14

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

Type: Bug Priority: Minor
Reporter: cstraw Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Tags: entitymanager, jbatch

 Description   

EntityManagerFactoryWrapper.lookupEntityManagerFactory casts 'descriptor' to WebBundleDescriptor when the ComponentInvocationType is SERVLET_INVOCATION without first checking if the descriptor is of this type.

For whatever reason, jbatch chunk steps bundled within an EAR that execute an EJB are currently considered type "SERVLET_INVOCATION", resulting in a ClassCastException, e.g.:

Failure in Read-Process-Write Loop
com.ibm.jbatch.container.exception.BatchContainerRuntimeException: java.lang.ClassCastException: org.glassfish.ejb.deployment.descriptor.EjbSessionDescriptor cannot be cast to com.sun.enterprise.deployment.WebBundleDescriptor

Bundling everything in a WAR appears to avoid this bug.

An potential fix is to pull the "case SERVLET_INVOCATION" up immediately after the "case EJB_INVOCATION" line so that the instanceof EjbDescriptor test is executed in both instances.

Similar issue was described online here:
https://www.java.net/forum/topic/glassfish/glassfish/jsr352-classcastexception-glassfish-v40






[GLASSFISH-21060] EntityManager injected twice into single stateless session bean method when deployment descriptor exists. Created: 05/May/14  Updated: 04/Jun/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Stephen Davies Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, RHEL, Java 1.6.0_45, Postgres 9.x, EclipseLink 2.0


Tags: 4_0_1-approved

 Description   

I've inherited a fairly convoluted code base that is using separate databases for regular data and archived data (postgres 9.x). There are two connection pools and two datasources defined in GF.

The app uses JPA 2.0 (EclipseLink) over Postgres as its persistence layer and a persistence.xml file contains two persistence contexts. A stateless session bean is used to manage interactions with JPA and the 'regular' database. A second SLSB manages interactions with the 'archive' database. The archive bean inherits from the regular bean.

A single EntityManager field is declared by the parent as protected. The parent defines a setter with a @PersistenceContext annotation referencing the regular persistence unit. The child bean overrides the parents setter method and is annotated with @PersistenceContext referencing the archive persistence unit.

When the above is deployed as a .war, an EntityManager for archive is injected ONCE into the child session bean. i.e. system behaves as expected.

If a deployment descriptor declaring the session beans (ejb-jar.xml) is added to the mix then the child session bean will have TWO distinct EntityManagers injected, archive followed by regular.



 Comments   
Comment by Stephen Davies [ 05/May/14 ]

@Stateless(name = "ParentBean")
@LocalBean
public class ParentBean {

protected EntityManager em;

@PersistenceContext(unitName = "regular")
public void setEntityManager(EntityManager em)

{ this.em = em; }

public void doIt() {}

}

Comment by Stephen Davies [ 05/May/14 ]

@Stateless(name = "ChildBean")
@LocalBean
public class ChildBean extends ParentBean {

@PersistenceContext(unitName = "archive")
@Override
public void setEntityManager(EntityManager em)

{ ServerSession session = ((EntityManagerFactoryImpl)em.getEntityManagerFactory()).getServerSession(); System.out.println("### Session name ###"); System.out.println(session.getName()); this.em = em; }

}

Comment by Stephen Davies [ 05/May/14 ]

@Singleton
@LocalBean
@Startup
public class Launch {

@EJB
private ChildBean cb;

@PostConstruct
public void init()

{ cb.doIt(); }

}

Comment by Stephen Davies [ 05/May/14 ]

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar
xmlns = "http://java.sun.com/xml/ns/javaee"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version = "3.1">

<enterprise-beans>

<session>
<ejb-name>ParentBean</ejb-name>
<ejb-class>jpa.test.ParentBean</ejb-class>
<session-type>Stateless</session-type>
</session>

<session>
<ejb-name>ChildBean</ejb-name>
<ejb-class>jpa.test.ChildBean</ejb-class>
<session-type>Stateless</session-type>
</session>

</enterprise-beans>

</ejb-jar>





[GLASSFISH-20970] Classloader leak in PoolResizeTimerTask Created: 04/Feb/14  Updated: 03/Jun/14

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

Type: Bug Priority: Critical
Reporter: electricsam Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-evangelists, 4_0_1-reviewed

 Description   

There is a classloader leak in the com.sun.ejb.containers.util.pool.NonBlockingPool and com.sun.ejb.containers.util.pool.NonBlockingPool$PoolResizeTimerTask.

When a application is re-deployed instances of these two classes are created as described in https://java.net/jira/browse/GLASSFISH-16676

This also leads to a classloader leak, which eventually prevents re-deployment of applications.



 Comments   
Comment by electricsam [ 04/Feb/14 ]

Here is the reference tree to the GC root:

this - EarClassLoader

  • parent - WebappClassLoader
    • <classloader> - GenericEJBHome_Generated
      • cls - PresentationManagerImpl$ClassDataImpl
        • value - WeakHashMapSafeReadLock$Entry
          • [] - WeakHashMapSafeReadLock$Entry[]
            • table - WeakHashMapSafeReadLock
              • map - PresentationManagerImpl$1
                • classToClassData - PresentationManagerImpl
                  • presentationMgr - POAProtocolMgr
                    • protocolMgr - StatelessSessionContainer
                      • this$0 - StatelessSessionContainer$SessionContextFactory
                        • factory - NonBlockingPool
                          • this$0 - NonBlockingPool$PoolResizeTimerTask
Comment by electricsam [ 05/Feb/14 ]

I think the actual issue is that there is a hard reference in the dictionary map in PresentationManagerImpl$ClassDataImpl

Here is some cleanup code that I've tried running in the @PreDestroy method of a singleton startup bean to try to clean up classloader leaks. This seems to get rid of many of them. This is just test code.

public abstract class ClassLoaderCleaner {

    private static final Logger logger = Logger.getLogger(ClassLoaderCleaner.class.getName());

    private ClassLoader loader = null;

    protected void destroy() {
        try {
            loader = getClass().getClassLoader();
            cleanUp();
        } catch (Throwable e) {
            logger.log(Level.SEVERE, null, e);
        }
    }

    private Thread[] getThreads() {
        ThreadGroup rootGroup = Thread.currentThread().getThreadGroup();
        ThreadGroup parentGroup;
        while ((parentGroup = rootGroup.getParent()) != null) {
            rootGroup = parentGroup;
        }

        Thread[] threads = new Thread[rootGroup.activeCount()];
        while (rootGroup.enumerate(threads, true) == threads.length) {
            threads = new Thread[threads.length * 2];
        }
        return threads;
    }

    private boolean loaderRemovable(ClassLoader cl) {
        if (cl == null) {
            return false;
        }
        Object isDoneCalled = getObject(cl, "doneCalled");
        if (cl.getClass().getName().equals(loader.getClass().getName())
                && isDoneCalled instanceof Boolean && (Boolean) isDoneCalled) {
            return true;
        }
        return loader == cl;
    }

    private Field getField(Class clazz, String fieldName) {
        Field f = null;
        try {
            f = clazz.getDeclaredField(fieldName);
        } catch (NoSuchFieldException ex) {

        } catch (SecurityException ex) {
            logger.log(Level.WARNING, "Unable to get field " + fieldName + " on " + clazz.getName(), ex);
        }

        if (f == null) {
            Class parent = clazz.getSuperclass();
            if (parent != null) {
                f = getField(parent, fieldName);
            }
        }
        if (f != null) {
            f.setAccessible(true);
        }
        return f;
    }

    private Object getObject(Object instance, String fieldName) {
        Class clazz = instance.getClass();
        Field f = getField(clazz, fieldName);
        if (f != null) {
            try {
                return f.get(instance);
            } catch (IllegalArgumentException | IllegalAccessException ex) {
                logger.log(Level.WARNING, "Unable to get " + fieldName + " on " + clazz.getName(), ex);
            }
        }
        return null;
    }

    private void cleanUp() {
        Thread[] threads = getThreads();
        for (Thread thread : threads) {
            if (thread != null) {
                cleanContextClassLoader(thread);
                cleanOrb(thread);
                cleanThreadLocal(thread);
                cleanTimers(thread);
            }

        }
    }

    private void cleanContextClassLoader(Thread thread) {
        if (loaderRemovable(thread.getContextClassLoader())) {
            thread.setContextClassLoader(null);
            logger.log(Level.INFO, "Cleaned context classloader {0}", thread.getName());
        }
    }

    private void cleanOrb(Thread thread) {
        Object currentWork = getObject(thread, "currentWork");
        if (currentWork != null) {
            Object orb = getObject(currentWork, "orb");
            if (orb != null) {
                Object transportManager = getObject(orb, "transportManager");
                if (transportManager != null) {
                    Thread selector = (Thread) getObject(transportManager, "selector");
                    if (selector != null && loaderRemovable(selector.getContextClassLoader())) {
                        selector.setContextClassLoader(null);
                        logger.log(Level.INFO, "Cleaned orb ref {0}", thread.getName());
                    }
                }
            }
        }
    }

    private void removeThreadLocal(Object entry, Object threadLocals, Thread thread) {
        ThreadLocal threadLocal = (ThreadLocal) getObject(entry, "referent");
        if (threadLocal != null) {
            Class clazz = null;
            try {
                clazz = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
            } catch (ClassNotFoundException ex) {
                logger.log(Level.WARNING, null, ex);
            }
            if (clazz != null) {
                Method removeMethod = null;
                Method[] methods = clazz.getDeclaredMethods();
                if (methods != null) {
                    for (Method method : methods) {
                        if (method.getName().equals("remove")) {
                            removeMethod = method;
                            removeMethod.setAccessible(true);
                            break;
                        }
                    }
                }
                if (removeMethod != null) {
                    try {
                        removeMethod.invoke(threadLocals, threadLocal);
                        logger.log(Level.INFO, "Cleaned threadlocal {0}", thread.getName());
                    } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                        logger.log(Level.SEVERE, null, ex);
                    }
                }

            }

        }
    }

    private void cleanThreadLocal(Thread thread) {
        Object threadLocals = getObject(thread, "threadLocals");
        if (threadLocals != null) {
            Object table = getObject(threadLocals, "table");
            if (table != null) {
                int size = Array.getLength(table);
                for (int i = 0; i < size; i++) {
                    Object entry = Array.get(table, i);
                    if (entry != null) {
                        Field valueField = getField(entry.getClass(), "value");
                        if (valueField != null) {
                            try {
                                Object value = valueField.get(entry);
                                if (value != null && value instanceof ClassLoader && loaderRemovable((ClassLoader) value)) {
                                    removeThreadLocal(entry, threadLocals, thread);
                                }
                            } catch (IllegalArgumentException | IllegalAccessException ex) {
                                logger.log(Level.WARNING, "Unable to get threadlocal value", ex);
                            }

                        }
                    }

                }
            }
        }
    }

    private void cleanTimers(Thread thread) {
        Object queue = getObject(thread, "queue");
        if (queue != null) {
            Object queue2 = getObject(queue, "queue");
            if (queue2 != null) {
                Object[] taskArray = (Object[]) queue2;
                for (Object timerTask : taskArray) {
                    if (timerTask != null) {
                        Object timerService = getObject(timerTask, "timerService_");
                        if (timerService != null) {
                            Object ejbContainerUtil = getObject(timerService, "ejbContainerUtil");
                            if (ejbContainerUtil != null) {

                                Object orbHelper = getObject(ejbContainerUtil, "orbHelper");
                                if (orbHelper != null) {
                                    Object protocolManager = getObject(orbHelper, "protocolManager");
                                    if (protocolManager != null) {
                                        Object presentationMgr = getObject(protocolManager, "presentationMgr");
                                        if (presentationMgr != null) {
                                            //PresentationManagerImpl$1
                                            Object classToClassData = getObject(presentationMgr, "classToClassData");
                                            if (classToClassData != null) {
                                                Object lock = getObject(classToClassData, "lock");
                                                //WeakHashMapSafeReadLock
                                                Object map = getObject(classToClassData, "map");
                                                if (lock != null && lock instanceof ReentrantReadWriteLock && map != null && map instanceof Map) {
                                                    ReentrantReadWriteLock theLock = (ReentrantReadWriteLock) lock;
                                                    Set<Object> toBeRemoved = new HashSet<>();
                                                    synchronized (presentationMgr) {
                                                        synchronized (classToClassData) {
                                                            theLock.writeLock().lock();
                                                            try {
                                                                Map theMap = (Map) map;
                                                                for (Object key : theMap.keySet()) {
                                                                    if (key != null) {
                                                                        //PresentationManagerImpl$ClassDataImpl
                                                                        Object value = theMap.get(key);

                                                                        if (value != null) {
                                                                            Object cls = getObject(value, "cls");
                                                                            if (cls != null && cls instanceof Class) {
                                                                                ClassLoader cl = ((Class) cls).getClassLoader();
                                                                                if (cl != null) {
                                                                                    if (loaderRemovable(cl) || loaderRemovable(cl.getParent())) {
                                                                                        toBeRemoved.add(key);
                                                                                    }
                                                                                }
                                                                            }

                                                                            Object dictionary = getObject(value, "dictionary");
                                                                            if (dictionary != null && dictionary instanceof Map) {
                                                                                Iterator it = ((Map) dictionary).values().iterator();
                                                                                while (it.hasNext()) {
                                                                                    Object o = it.next();
                                                                                    if (o != null  && o instanceof Class) {
                                                                                        ClassLoader cl = ((Class) o).getClassLoader();
                                                                                        if (cl != null) {
                                                                                            if (loaderRemovable(cl) || loaderRemovable(cl.getParent())) {
                                                                                                it.remove();
                                                                                                logger.log(Level.INFO, "Cleaned dictionary: {0}", thread.getName());
                                                                                            }
                                                                                        }
                                                                                    }
                                                                                }

                                                                            }

                                                                        }
                                                                    }
                                                                }

                                                            } finally {
                                                                theLock.writeLock().unlock();
                                                            }
                                                        }
                                                    }

                                                    Method removeMethod = null;
                                                    Method[] methods = presentationMgr.getClass().getDeclaredMethods();
                                                    if (methods != null) {
                                                        for (Method method : methods) {
                                                            if (method.getName().equals("flushClass")) {
                                                                removeMethod = method;
                                                                removeMethod.setAccessible(true);
                                                                break;
                                                            }
                                                        }
                                                    }
                                                    if (removeMethod != null) {
                                                        for (Object cls : toBeRemoved) {
                                                            try {
                                                                removeMethod.invoke(presentationMgr, cls);
                                                                logger.log(Level.INFO, "Cleaned classToClassData: {0}", thread.getName());
                                                            } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                                                                logger.log(Level.SEVERE, null, ex);
                                                            }
                                                        }
                                                    }

                                                }

                                            }
                                        }
                                    }
                                }

                                Object timer = getObject(ejbContainerUtil, "_timer");
                                if (timer != null && timer instanceof Timer) {
                                    int purged = ((Timer) timer).purge();
                                    logger.log(Level.INFO, "Cleaned timer {0}. Purged {1} tasks.", new Object[]{thread.getName(), purged});
                                }
                            }
                        }
                    }
                }
            }
        }
    }

}

There is still a leak in a thread local with the following tree

this     - value: org.glassfish.javaee.full.deployment.EarClassLoader #6
 <- loader     - class: com.sun.ejb.containers.CMCSingletonContainer, value: org.glassfish.javaee.full.deployment.EarClassLoader #6
  <- container     - class: com.sun.ejb.containers.EJBLocalObjectInvocationHandler, value: com.sun.ejb.containers.CMCSingletonContainer #9
   <- optionalEjbLocalBusinessObjectImpl     - class: com.sun.ejb.containers.SingletonContextImpl, value: com.sun.ejb.containers.EJBLocalObjectInvocationHandler #12
    <- [0]     - class: java.lang.Object[], value: com.sun.ejb.containers.SingletonContextImpl #10
     <- elementData     - class: java.util.ArrayList, value: java.lang.Object[] #96711
      <- beans     - class: com.sun.ejb.containers.ContainerSynchronization, value: java.util.ArrayList #97409
       <- sync     - class: com.sun.ejb.containers.EjbContainerUtilImpl$TxData, value: com.sun.ejb.containers.ContainerSynchronization #2
        <- containerData     - class: com.sun.enterprise.transaction.JavaEETransactionImpl, value: com.sun.ejb.containers.EjbContainerUtilImpl$TxData #2
         <- clientTx     - class: com.sun.ejb.EjbInvocation, value: com.sun.enterprise.transaction.JavaEETransactionImpl #2
          <- inv     - class: com.sun.enterprise.security.authorize.HandlerData, value: com.sun.ejb.EjbInvocation #5
           <- value     - class: java.lang.ThreadLocal$ThreadLocalMap$Entry, value: com.sun.enterprise.security.authorize.HandlerData #6
            <- [121]     - class: java.lang.ThreadLocal$ThreadLocalMap$Entry[], value: java.lang.ThreadLocal$ThreadLocalMap$Entry #1185
             <- table     - class: java.lang.ThreadLocal$ThreadLocalMap, value: java.lang.ThreadLocal$ThreadLocalMap$Entry[] #179
              <- threadLocals (thread object)     - class: java.lang.Thread, value: java.lang.ThreadLocal$ThreadLocalMap #179




[GLASSFISH-21042] Interfaces Specified by RemoteHome or LocalHome Not Resolved in SerialContext.lookup as Business Interfaces on EJB Session Beans, Resulting in NPE in JavaGlobalJndiNamingObjectProxy.create Created: 17/Apr/14  Updated: 03/Jun/14

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

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

Tags: 4_0_1-reviewed, embedded, maven-glassfish-plugin

 Description   

Had the following error in a JUnit test case using the embedded Glassfish 3.1.1 container:

shouldCreateABook(com.coverity.testsuite.ejb.localhome.BookLocalHomeBeanTest):
Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
BookLocalHomeBeanTest.java
package com.coverity.testsuite.ejb.localhome;

import java.io.File;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.xml.ws.WebServiceRef;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

import com.coverity.testsuite.ejb.Book;
import com.coverity.testsuite.ejb.localhome.BookLocal;

import static org.junit.Assert.*;

/**
 *
 * @author pasc
 */
public class BookLocalHomeBeanTest {

    private static EJBContainer ec=null;
    private static Context ctx=null;

    public BookLocalHomeBeanTest() {}

    @BeforeClass
    public static void initContainer() throws Exception {
        Map<String, Object> props=new HashMap<String, Object>();
        props.put(EJBContainer.MODULES, new File("target/embedded-classes"));
        props.put("org.glassfish.ejb.embedded.glassfish.instance.root","./src/test/testing-domain");
        props.put("org.glassfish.ejb.embedded.glassfish.web.http.port","");
        props.put("javax.enterprise.system.container.web", "FINE");
        ec = EJBContainer.createEJBContainer(props);
        ctx = ec.getContext();
    }

    @AfterClass
    public static void closeContainer() throws Exception {
        if(ctx!=null)
            ctx.close();
        if(ec!=null)
            ec.close();
    }

    @Test
    public void shouldCreateABook() throws Exception {
        Book book = new Book();
        book.setTitle("The Hitchhiker's Guide to the Galaxy");
        book.setPrice(12.5F);
        book.setDescription("Scifi book created by Douglas Adams");
        book.setIsbn("1-84023-742-2");
        book.setNbOfPages(354);
        book.setIllustrations(false);

        Object obj = ctx.lookup("java:global/embedded-classes/BookLocalHomeBean");
        BookLocalHome bookHome = (BookLocalHome) obj;
        BookLocal bookLocal = bookHome.createBook(book);
        book = bookLocal.findBookById(book.getId());
        assertNotNull("Book should not be null", book);
        assertNotNull("ID should not be null", book.getId());
    }
}

The application I'm using is a modified version of embedded-glassfish-example:

BookLocal.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.EJBLocalObject;

import com.coverity.testsuite.ejb.Book;

public interface BookLocal extends EJBLocalObject {

    void deleteBook(Book book);

    Book findBookById(Long id);

    List<Book> findBooks();

    Book updateBook(Book book);
}
BookLocalHome.java
package com.coverity.testsuite.ejb.localhome;

import javax.ejb.EJBLocalHome;
import javax.ejb.CreateException;

import com.coverity.testsuite.ejb.Book;

public interface BookLocalHome extends EJBLocalHome {

    public BookLocal createBook(Book book) throws CreateException;
}
BookLocalHomeBean.java
package com.coverity.testsuite.ejb.localhome;

import java.util.List;
import javax.ejb.Stateful;
import javax.ejb.LocalHome;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.annotation.Resource;
import javax.ejb.SessionContext;

import com.coverity.testsuite.ejb.Book;

/**
 *
 * @author pasc
 */
@Stateful
@LocalHome(BookLocalHome.class)
public class BookLocalHomeBean {
    @PersistenceContext(unitName = "bookstore-ejb")
    EntityManager em;

    @Resource
    private SessionContext sessionContext;

    public List<Book> findBooks() {
        return em.createNamedQuery("Book.findAllBooks", Book.class).getResultList();
    }

    public Book findBookById(Long id) {
        return em.find(Book.class, id);
    }

    public void ejbCreateBook(Book book) {
        em.persist(book);
    }

    public void deleteBook(Book book) {
        em.remove(em.merge(book));
    }

    public Book updateBook(Book book) {
        return em.merge(book);
    }
}

The above code hasn't been validated another embedded EJB container, therefore it could be incorrect. It seems correct, based on looking at the JBoss quick start EJB test cases.

I enabled logging within Glassfish by specifying the following in a .properties file:

handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST
com.sun.enterprise.naming.level=FINEST

com.sun.enterprise.naming is specified in LogFacade, used as SerialContext's logger. Passing it to Maven as mvn clean test -Djava.util.logging.config.file=src/test/resources/customlogging.properties results in the nice stack trace, trimmed below:

Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: SerialContext ==> SerialContext instance created : SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
  java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
  java.naming.factory.url.pkgs=com.sun.enterprise.naming}
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext <init>
FINE: Serial Context initializing with process environment org.glassfish.api.admin.ProcessEnvironment@7a341251
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup( java:global/embedded-classes/BookLocalHomeBean)
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: SerialContext ==> lookup relative name : java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContextProviderImpl lookup
FINE:  SerialContextProviderImpl :: lookup java:global/embedded-classes/BookLocalHomeBean
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE: enterprise_naming.serialctx_communication_exception
Apr 16, 2014 11:42:55 AM com.sun.enterprise.naming.impl.SerialContext lookup
FINE:
java.lang.NullPointerException
        at com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(JavaGlobalJndiNamingObjectProxy.java:65)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:507)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)

Kicking up Eclipse and debugging the app showed the following:

com.sun.ejb.containers.JavaGlobalJndiNamingObjectProxy.create(Context)
/*    */   public Object create(Context ic) {
/* 63 */     GenericEJBLocalHome genericLocalHome = this.container.getEJBLocalBusinessHome(this.intfName);
/*    */     
/* 65 */     return genericLocalHome.create(this.intfName);
/*    */   }
  • this.intfName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • genericLocalHome = null

null is being passed into the create call, which triggers the NPE. Looking into `getEJBLocalBusinessHome`:

com.sun.ejb.containers.BaseContainer.getEJBLocalBusinessHome(String)
/*      */   public final GenericEJBLocalHome getEJBLocalBusinessHome(String clientViewClassName)
/*      */   {
/* 1016 */     return isLocalBeanClass(clientViewClassName) ? this.ejbOptionalLocalBusinessHome : this.ejbLocalBusinessHome;
/*      */   }
  • clientViewClassName = com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbOptionalLocalBusinessHome = null
  • this.ejbLocalBusinessHome = null

Both are null. Let's see which one should have been picked:

com.sun.ejb.containers.BaseContainer.isLocalBeanClass(String)
/*      */   boolean isLocalBeanClass(String className)
/*      */   {
/* 1023 */     return (this.hasOptionalLocalBusinessView) && ((className.equals(this.ejbClass.getName())) || (className.equals(this.ejbGeneratedOptionalLocalBusinessIntfClass.getName())));
/*      */   }
  • this.hasOptionalLocalBusinessView = false
  • className == com.coverity.testsuite.ejb.localhome.BookLocalHome
  • this.ejbClass.getName() == com.coverity.testsuite.ejb.localhome.BookLocalHomeBean
  • this.ejbGeneratedOptionalLocalBusinessIntfClass.getName() == null

isLocalBeanClass returns false. Assuming the bug isn't lurking above, this.ejbLocalBusinessHome should not be null.

Now, BaseContainer is the abstract class. Eclipse is telling me the actual type is com.sun.ejb.containers.StatefulSessionContainer. StatefulSessionContext doesn't set the field ejbLocalBusinessHome. Grepping around ejbLocalBusinessHome is set in BaseContainer:

com.sun.ejb.containers.BaseContainer.initializeHome()
/* 1444 */       if (this.hasLocalBusinessView) {
/* 1445 */         this.ejbLocalBusinessHomeImpl = instantiateEJBLocalBusinessHomeImpl();
/*      */         
/* 1447 */         this.ejbLocalBusinessHome = ((GenericEJBLocalHome)this.ejbLocalBusinessHomeImpl.getEJBLocalHome());
/*      */       

To get to that point, isLocal} needs to be true, which it is in this run. For the field to be set, {{this.hasLocalBusinessView needs to be true, which it isn't in this run. BaseContainer sets it only in one spot. (StatefulSessionContainer does reference it; it just doesn't set it.):

com.sun.ejb.containers.BaseContainer.BaseContainer(ContainerType, EjbDescriptor, ClassLoader)
/*  650 */         if (this.ejbDescriptor.isLocalBusinessInterfacesSupported()) {
/*  651 */           this.isLocal = true;
/*  652 */           this.hasLocalBusinessView = true;
  • this.ejbDescriptor = com.sun.enterprise.deployment.EjbSessionDescriptor

And digging into isLocalBusinessInterfacesSupported:

com.sun.enterprise.deployment.EjbAbstractDescriptor.isLocalBusinessInterfacesSupported()
/*     */   public boolean isLocalBusinessInterfacesSupported()
/*     */   {
/* 278 */     return this.localBusinessClassNames.size() > 0;
/*     */   }
  • this.ejbDescriptor.localBusinessClassNames == []

Well, shucks. localBusinessClassNames is set in a ctor and also com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String):

com.sun.enterprise.deployment.EjbAbstractDescriptor.addLocalBusinessClassName(String)
/*     */   public void addLocalBusinessClassName(String className) {
/* 185 */     this.localBusinessClassNames.add(className);
/*     */   }

Eclipse is saying it's only called by org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo), whoop. Debugging that method shows this:

org.glassfish.ejb.deployment.annotation.handlers.AbstractEjbHandler.setBusinessAndHomeInterfaces(EjbDescriptor, AnnotationInfo)
...
/* 452 */     if (localBusIntfs.size() > 0) {
/* 453 */       for (Class next : localBusIntfs) {
/* 454 */         ejbDesc.addLocalBusinessClassName(next.getName());
/*     */       }
/*     */     }

And since the EJB bean doesn't have any business interfaces implemented, (as defined by JSR), localBusIntfs is null. From JSR 318:

While it is expected that the bean class will typically implement its business inter- face(s), if the bean class uses annotations or the deployment descriptor to designate its business interface(s), it is not required that the bean class also be specified as imple- menting the interface(s).

In my test case the EJB doesn't implement the interface. But the only way the logic above would not cause the NPE is if a business interface is found. To me that seems like a bug in Glassfish. I'd think the Local interface would have been returned. I dunno what the right thing is, though. Assuming the code above is valid, then yeah, it's a bug.






[GLASSFISH-21074] Message-driven bean invocation exception: [javax.ejb.EJBException] Created: 27/May/14  Updated: 03/Jun/14

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

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

CentOS release 6.4 (Final), Glassfish 3.1.2.2



 Description   

Following exception occurs in GF logs when running JMS load tests for a couple of hours:

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=714;_ThreadName=Thread-2;|MDB00037: [ht-ear-2.7.0-SNAPSHOT-PRETTY-7527:ObdMessageBean]: Message-driven bean invocation exception: [javax.ejb.EJBException]|#]

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=714;_ThreadName=Thread-2;|javax.ejb.EJBException
javax.ejb.EJBException
at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5215)
at com.sun.ejb.containers.BaseContainer.checkExceptionNoTx(BaseContainer.java:5044)
at com.sun.ejb.containers.BaseContainer.checkExceptionBeanMgTx(BaseContainer.java:4965)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4865)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1211)
at com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1186)
at com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:86)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:190)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException

#]

[#|2014-05-23T23:47:31.035+0200|WARNING|glassfish3.1.2|javax.resourceadapter.mqjmsra.inbound.message|_ThreadID=714;_ThreadName=Thread-2;|MQJMSRA_MR2001: run:Caught Exception from onMessage():Redelivering:
javax.ejb.EJBException: message-driven bean method public abstract void javax.jms.MessageListener.onMessage(javax.jms.Message) system exception
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1134)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at com.sun.proxy.$Proxy669.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException

#]


 Comments   
Comment by alebor [ 03/Jun/14 ]

This issue looks like a duplicate of https://java.net/jira/browse/GLASSFISH-21072 (upper part of the trace from NPE).
I cannot remove it because it do not have the rights.





[GLASSFISH-20295] Keep timers by default Created: 12/Apr/13  Updated: 21/Apr/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: future release
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.1, JDK 1.7.0_17, Windows 7 Pro SP 1, x64



 Description   

Many business applications rely on timers. For example, it is quite typical to have a timer fire up when an insurance contract is to be renewed. Processes like these are usually modelled as MDBs reacting on Create, Update, Delete and Timout Events of the contract. Hence, these timers are business Information. If these get lost, the process is not working anymore, as no timeout is ever fired then.

It is quite typical to install new bug fixes for an application from time to time. The usual way is to do a redeploy. But: Unless "--keepstate" is used, the timers will get lost. Say that loud: Unless the Administrator takes extra care, Business Information is destroyed by GlassFish! But how should the Administrator know? The truth is: He won't. It is quite usual in large companies that a business division obtains a software package, forwards it to the admin to run it, but neither of both ever knows that timers even are used by that software package. How should they?

There are three theoretical solutions to not lose timers:
(1) GlassFish must keep timers by default but never delete them – unless it is explicitly told by a "--keepstate=false". This is true for both, redeploy AND undeploy – the the administrator might want to deploy again on a different GlassFish host accessing the same database, expecting the timers to be untouched inside of the RDBMS! Note that I do not suggest to make "true" the default of --keepstate as the Administrator typically does not want to Keep HTML sessions open but solely wants to rescue persistent timers!
(2) GlassFish team writes on the web site and on the first page of the admin docs a big fat red warning that essential business information is destroyed in the database at undeploy and redeploy, it is essential to use "--keepstate=true" always when using these commands. This is a ridiculous idea.
(3) GlassFish Team writes on the web site and on the first page of the developer docs a big fat red warning that essential Business Information is destroyed in the database at undeploy and redeploy, hence application vendors shall prints a big fat red warning on their boxes and docs, that when the application is run on GlassFish, "--keepstate=true" MUST be used ALWAYS with undeploy and redeploy to prevent data loss. This also is a ridiculous idea.

To sum up, the only real solution working in the real world outside of GlassFish development labs is to ALWAYS keep persistent timers untouched in the database, at least unless explicitly "--keepstate=false" is issued by the Administrator.



 Comments   
Comment by Tom Mueller [ 12/Apr/13 ]

Changing to the ejb_container component since this is related to EJB timers.

Comment by mkarg [ 10/Apr/14 ]

Anybody willing to at least write down an opinion of the EJB team about this proposal after one year since I proposed this feature change?

Comment by reza_rahman [ 10/Apr/14 ]

We are currently prioritizing bugs for the upcoming 4.x release. To tell you the truth I'm not sure we will get to feature requests like this in the near term. I hate to ask this, but would it be possible for you to contribute the feature?

Comment by mkarg [ 12/Apr/14 ]

Let me be frank. This is a really small change for someone who knows the source code well. We don't. For us, it is several days of work to at least be able to compile GlassFish. So we will provide a fix if it will not be in vain only. That means clearly, we need an agreement from your product lead that it is OK for him that we will change the default from "discard timers" to "keep timers". If Oracle agrees to that, we will donate that code change. But see, we will not invest any second as long as the GlassFish team later decide that it actually is UNWANTED to modify this default.

Comment by reza_rahman [ 12/Apr/14 ]

Excellent - this is all good. To get this process started, could you kindly make sure that this change won't be contrary to the EJB/Java EE spec? In the meanwhile, I'll follow up with the respective product/resource manager to see what they think. From our end, the only issue is really proper prioratization. As I stated the current focus is bug fixes but I'm inclined to think we could make room for integrating a good contribution.

Comment by mkarg [ 12/Apr/14 ]

In fact, when I first have noticed that a redeployment will delete all existing triggers at redeployment (which are a kind of business process data actually) I was shocked. For me, this actually is not a feature, but is a really heavy bug in the design of the API. Maybe this changes the product manager's view when he understands that there is no difference between an application storing "end of contract" date in a database compared to "trigger timer at end of contract" and not storing this into the database. While the first survives a redeployment, the second does not. This means, a business process might survice or not simply by going via JPA compared to persistent triggers. This is so weird, that anybody I talked to said: "This MUST be a bug."

Comment by reza_rahman [ 13/Apr/14 ]

The reason I am asking to check the spec is that the spec may have an opinion on what should be done at redeployment. I know you don't see it that way but erasing previous trigger data may be the most conservative approach to deal with potential changes made to triggers as a result of the deployment. This is likely the reason to explicitly make sure the user wants previous triggers preserved.

This all being said, let's see what the product managers think. In the least we could see if things need to be documented better.

Comment by mkarg [ 19/Apr/14 ]

I have not found any mandatory deletion of persistent timers in the EJB 3.2 specification's chapter on EJB Timer Service.

Marina, please kindly also find my eMail just sent about clarifying this in the EJB 3.2 spec's next maintenance release.

Comment by reza_rahman [ 19/Apr/14 ]

Please note that Marina is no longer necessarily assigned to the EJB specification. The best approach is to properly document any possible issues via the EJB spec JIRA.

Comment by mkarg [ 19/Apr/14 ]

I just explained that this might be a severe violation of the EJB specification and people might lose valueable business data, and as a result you reduce severity from "severe" to "unimportant"? I don't get this kind of logic!

Comment by reza_rahman [ 19/Apr/14 ]

I am not sure I have much more to say on this. Bug/feature categorization is already explained on this JIRA system, please take a look. If this matter deserves anything more, I am sure it will be followed up upon at some point (such as documentation tweaks on what type of state is persisted by default on undeployment/redeployment).

Comment by mkarg [ 20/Apr/14 ]

Please also see https://java.net/jira/browse/EJB_SPEC-121.

Comment by mkarg [ 20/Apr/14 ]

Reza, did you find the time to talk to your product manager whether he will accept it if I change the default from "drop timers" to "keep timers" (so I can start coding this contribution)?

Comment by reza_rahman [ 20/Apr/14 ]

The product and resource managers have been notified days ago. I suggest not doing anything until you are properly approached and focusing in other areas that may be a higher priority for the GlassFish and Java EE communities such as clearly identified bugs in the meanwhile.

Comment by mkarg [ 21/Apr/14 ]

The last part of your comment sounds like the GlassFish open source project does not really want feature contributions from the community but instead sees the community solely as a team of beta testers and free bug fixers while Oracle still has sole say in everything, which is hopefully not what you actually wanted to express.

Comment by reza_rahman [ 21/Apr/14 ]

Please take a careful look at earlier comments in the thread. I have already told you we would try to make reasonable accommodations to incorporate any useful contributions that conform to the overall integrity and goals of the GlassFish project - feature or bug fix. I've also made it clear our current focus is primarily bug fixes so any contribution there takes a higher priority.





[GLASSFISH-4292] Support for idempotent methods Created: 28/Feb/08  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Mahesh Kannan Assignee: