[GLASSFISH-11687] Try to recover from corrupted log files Created: 16/Mar/10  Updated: 01/Oct/10

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Critical
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


Issuezilla Id: 11,687

 Description   

In a rare case of a corrupted file under transaction log directory, the
transaction service should rename or delete either those files or the whole
directory to be able to continue. Otherwise all transaction processing would fail.






[GLASSFISH-9856] Monitoring: methodReadyAddEvent, methodReadyRemoveEvent probe is not called for ejb SL bean Created: 29/Sep/09  Updated: 04/Jan/13

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

Type: Improvement Priority: Critical
Reporter: Nazrul 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: 9,856
Status Whiteboard:

v3_exclude, 3.1-exclude


 Description   

We are not firing methodReadyAddEvent and methodReadyRemoveEvent for EJB SL bean.

Refer to http://monaco.sfbay.sun.com/detail.jsf?cr=6886594 for detailed steps.



 Comments   
Comment by Nazrul [ 29/Sep/09 ]

People who are writing JavaScripts or DTrace scripts may run into this issue in
GFv3. We need to document this limitation of the probe and perhaps put it in the
release note.

Comment by marina vatkina [ 29/Sep/09 ]

SLSB in v2 provide only accumulative data, not the points where the data
changes. The probes are available in v3 for the SFSBs.





[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-21412] CLONE - EJB + JAX-RS don't work with updated example Created: 11/Aug/15  Updated: 12/Aug/15

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

Type: Bug Priority: Critical
Reporter: atrajano Assignee: marina vatkina
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-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-15096] Move preInvoke/postInvoke logic from TransactionManagerHelper to JavaEETransactionManagerSimplified to avoid different code paths for lookup vs injection Created: 10/Dec/10  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: V3
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: ee7ri_cleanup_deferred

 Description   

TransactionManagerHelper shouldn't check for the servlet invocation, and be responsible for enlist/delist resources. This might also remove the need for the EJB container to call special preInvoke/postInvoke methods, but do just suspend/resume calls.



 Comments   
Comment by marina vatkina [ 17/Mar/11 ]

See http://java.net/jira/browse/GLASSFISH-11920 for the reason of the latest changes to the TransactionManagerHelper





[GLASSFISH-14812] ThreadContextClassloader should be adjusted in a single location Created: 19/Nov/10  Updated: 05/Oct/11

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
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
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,812
Tags: 3_1-exclude

 Description   

It is currently all over the place in the ejb-container code



 Comments   
Comment by marina vatkina [ 19/Nov/10 ]

Not for 3.1

Comment by Cheng Fang [ 05/Oct/11 ]

Related issue: http://java.net/jira/browse/GLASSFISH-1830 (Fix ContextClassLoader handling)





[GLASSFISH-14768] Config to disable automatic timer migration on instance stop/crash Created: 17/Nov/10  Updated: 13/Dec/10

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

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

Operating System: Linux
Platform: Linux


Issuezilla Id: 14,768

 Description   

Right now, there is no configuration to disable automatic timer migration on
instance stop if GMS is enabled. It would be nice to have that feature so that
user can have choice of using automatic migration of timer or migrate-timers CLI.






[GLASSFISH-9801] Monitoring: Type attribute required for v3 runtime components Created: 28/Sep/09  Updated: 04/Jan/13

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

Type: Bug Priority: Major
Reporter: rajeshwar 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: 9,801
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

In case of v3 runtime tree, there is no way to distinguish between different
components such as modules, beans. We need to provide type attributes for nodes
representing such components. Here is the list of components, the nodes of which
requires type attribute-

Module Node
Type:
Ejb Module
Standalone Ejb Module
Web Module
Standalone Web Module

Bean Node
Type:
Stateful Session Bean
Stateless Session Bean
Entity Bean
Message Driven Bean



 Comments   
Comment by rajeshwar [ 28/Sep/09 ]
      • Issue 8837 has been marked as a duplicate of this issue. ***
Comment by abbagani [ 28/Sep/09 ]

We will need the type attribute at the ejb module level and also at the bean
level. Transferring the bug to Marina.

Comment by Nazrul [ 28/Sep/09 ]

...

Comment by marina vatkina [ 29/Sep/09 ]

Need an API to use, but I can only set the bean node type, not the module type.

Comment by abbagani [ 01/Oct/09 ]

We will need the type attribute under ejb-module and bean level.

Module level
============
ear

RosterApp/RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

We will need to define a new StatsProvider with just one attribute
(module-type). You could do this as an inner class (Would it be in
MonitoringRegistryMediator?). In the above case, we will need this attribute
under 'RosterAppEjb\.jar'. The type would say, if it is a 'standalone ejb' or an
'ejb'. Pick the constants that Deployment or ejb-container might already be using.

standalone module (jar)
------------------------------

RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

Same as in ear. Need a type attribute under 'RosterAppEjb\.jar'

Bean level
========

RosterAppEJB\.jar/LeagueEJB/bean-methods/getCitiesOfThisLeague

We will need an attribute called type (bean-type). This should be easy, since
you already have a StatsProvider for a bean which has some existing attributes.
The bean-type should say what type of bean it is.

I think it should be in EJBStatsProvider (define type as new attribute and set
the type value when you are instantiating one of the derived classes).

Comment by marina vatkina [ 05/Oct/09 ]

monitoring is p3

Comment by marina vatkina [ 10/Nov/09 ]

-> 3.1





[GLASSFISH-11529] [spec request] The global jndi namespace should not contain local session beans if interapplication calls are not supported. Created: 06/Feb/10  Updated: 29/Sep/10

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

Type: Improvement Priority: Major
Reporter: chasetec 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: 11,529

 Description   

This is kind of a follow up to a bug where I was asking for default JNDI names
before EJB 3.1 (https://glassfish.dev.java.net/issues/show_bug.cgi?id=577).

I love the new default JNDI names and I think the different namespaces
(global,app,module) where a great idea however I have one complaint.

The specs don't require support for inter-application calls on local session
beans. Even though some app servers allow it I'm fine with GlassFish not
allowing it. However I think it unnecessary and confusing to publish global JNDI
names for local session beans that can't be called.

I'd like to see the spec and GlassFish only require the creation of global JNDI
names for EJBs that support inter-application calling.



 Comments   
Comment by chasetec [ 06/Feb/10 ]

To clarify "I'd like to see the spec and GlassFish only require the creation of
global JNDI names for EJBs that support inter-application calling."

I mean just the global namespace. There should still be standard jndi names for
local session beans in the app and module namespaces.

Comment by marina vatkina [ 29/Sep/10 ]

The current spec says this: "The container registers a separate JNDI name entry
for each local business interface, each remote business interface, and any
no-interface view, 2.x local home interface, and 2.x remote home interface."





[GLASSFISH-10109] EJB Session Store Statistics are not exposed Created: 08/Oct/09  Updated: 30/Oct/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v2.1.2
Fix Version/s: future release

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
Environment:

Operating System: All
Platform: All
URL: http://docs.oracle.com/cd/E19316-01/820-4335/6nfqc3qpp/index.html#gelnw


Issuezilla Id: 10,109
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude

 Description   

MonitoringRegistryMediator has this line since 9.0:

//FIXME: registry.registerStatefulSessionStoreStats(statsImpl);



 Comments   
Comment by marina vatkina [ 08/Oct/09 ]

v3_exclude

Comment by marina vatkina [ 02/Nov/09 ]
      • Issue 10751 has been marked as a duplicate of this issue. ***




[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-13873] If TS resource had been changed, tables are not created after server restart Created: 07/Oct/10  Updated: 15/Apr/11

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

Type: Bug Priority: Major
Reporter: easarina 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


Attachments: Text File server.log     File timersession.ear    
Issuezilla Id: 13,873
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Build 23 10/07. Solaris 10 Sparc. Installed thid build on one machine. Created a
cluster with two instances. Then started a cluster. After that executed:
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================================

The appclient was executed successfully.

Then I've reinstalled everything and executed such sequence of the commands:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
================================================

In this case not only seconf execution of the appclient totally failed, but also
second deployment failed.

I believe, if once TS did not start successfully and it is not running, then
during next invoke, has be to cleaned everything and TS should be started again.
I've restarted cluster, db, domain, tried to undeploy an app and deploy it
again, but it did not help. So only a full uninstall helps to clean everything.
I've attached timersession.ear and in1 server.log.



 Comments   
Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5096)
timersession.ear

Comment by easarina [ 07/Oct/10 ]

Created an attachment (id=5097)
in1 server.log

Comment by marina vatkina [ 07/Oct/10 ]

As this would be something we didn't provide before, making it an RFE for the
next release.

Comment by easarina [ 07/Oct/10 ]

I believe, that for this release has to be provided at least a work around. I.e.
if first time TS did not start, how to clean everything and make it start next
time without reinstalling the glassfish.

Comment by marina vatkina [ 07/Oct/10 ]

You need to restart the DAS as well

Comment by easarina [ 07/Oct/10 ]

As I've wrote I've restarted DAS, cluster, DB. But it did not help.

Comment by marina vatkina [ 08/Oct/10 ]

This is what's going on:

The 1st time you started, TS was (absolutely fine) deployed to jdbc/__TimerPool,
so after restart, even though the code figured out that it's a different
resource, the file marker left behind said it's a load, not a deploy.

May be the file should contain the last (all?) resources TS was deployed to...

Comment by easarina [ 08/Oct/10 ]

When was added glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-
app, the second deployment/appclient execution were OK. I.e. such sequence of
commands worked:
===================================================
#!/usr/bin/perl
require "./conf.pl";

$out=`$S1AS_HOME/bin/asadmin start-database`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
$out=`$S1AS_HOME/bin/asadmin undeploy --target c1 timersession`;
print $out;
$out=`rm -rf $S1AS_HOME/domains/domain1/generated/ejb-timer-service-app`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin stop-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-domain`;
print $out;
$out=`$S1AS_HOME/bin/asadmin set
configs.config.c1-config.ejb-container.ejb-timer-service.timer-
datasource=jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default`;
print $out;
$out=`$S1AS_HOME/bin/asadmin start-cluster c1`;
print $out;
$out=`$S1AS_HOME/bin/asadmin list-instances`;
print $out;
$out=`$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve .
./timersession.ear`;
print $out;
$out=`$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client
./timersessionClient.jar`;
print $out;
========================================================

But it doesn't work without stop-domain/start-domain.

I believe this sequence of the commands has to work without a domain restating.

Comment by marina vatkina [ 17/Nov/10 ]

Let's RN for this release that if the EJB Timer resource was changed after the
EJB Timer Service was started on a previous resource, a) DAS needs to be
restarted if any automatic timers are to be deployed, and b) unless the EJB
Timer table is created manually, the marker file
glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-app needs to be
removed as well.

Please reassign it back to ejb-container after it is documented

Comment by Paul Davies [ 17/Nov/10 ]

Added 3.1-release-notes keyword to ensure that this issue is documented in the
RN and reset the subcomponent and owner.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.





[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-12633] EJBContainerProviderImpl ignores classpath entries when they are EJB modules but not specified using EJBContainer.MODULES Created: 13/Jul/10  Updated: 05/Oct/10

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

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,633

 Description   

I am using GF 3.1 build 9.
The faulty code is (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary,
lines 281 - 285):

DeploymentElement result = null;
...
if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
}

return result;

The use case: the container is started and the EJB modules are specified:
return EJBContainer.createEJBContainer(parameters);
where parameters contains a mapping EJBContainer.MODULES -> "ejbmodules".

Still, every classpath entry is checked whether it is an EJB module or WAR or
simple lib (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary method) - I
don't think this should happen, it should first check if the classpath entry is
listed in MODULES. But that's not the real problem.

The problem is that some classpath entries can be discivered as EJB modeles, and
not listed in MODULES, so they should be probably treated as plain library
entries. However, the code quoted above fails to do so - in the described test
case, the 'if' will never return true - isEJBModule is true, so it will go on to
the last condition, which checks whether the name is within the required modules

  • and the DeploymentElement will remain null, effectively making the whole
    classpath entry excluded from deployment.

If I use a library that has an EJB for some reason, the described behaviour will
simply ignore it and the application will blow up in runtime.

I think the check whether an EJB module is listed using MODULES should be done
earlier, as if it is not listed, it doesn't really matter if there are EJBs or
not, it should be a plain library entry. If however, for some reason, the name
check is to stay as it is, the quoted 'if' should be changed, something like:

if (isEJBModule && !moduleNames.contains(moduleName)) {
isEJBModule = false; // treat entry as plain library
}
if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
}

or

if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, isEJBModule);
} else if (isEJBModule && !moduleNames.contains(moduleName)) {
result = new DeploymentElement(file, false); // treat the entry as library
}



 Comments   
Comment by sirajg [ 13/Jul/10 ]

transfer

Comment by marina vatkina [ 15/Jul/10 ]

EJB module can't become a library if EJBContainer.MODULES is not empty. But we
can look at introducing a special setting for that.

Comment by szczyp [ 19/Jul/10 ]

Why can it not? If it is not listed in modules, it is not an EJB module and
should not be treated as such. And on no account must it be ignored as it is now.

Sometimes you will not know that a third party library is an EJB jar, and then
suddenly you will get ClassNotFoundExceptions, and will start scratching your
head, as the classes are there on the classpath.

What is wrong with the code sample I included? It seemed to work for me, and you
probably have unit tests to check if this is valid?

Comment by marina vatkina [ 19/Jul/10 ]

Deployment doesn't distinguish between a library and a Java EE module. So if it
contains EJB annotation, it's an EJB module. Does it work differently for you
when you package and deploy your aplication to a regular GF instance?

Comment by szczyp [ 20/Jul/10 ]

I tested this and what I see is that if a lib jar is has an EJB that is not
included in MODULES it is not deployed as one (DeploymentResult returns null).
However, it is on the classpath. Does this mean that for an EJB module that is
in listed in MODULES, it is both included in classpath and deployed, effectively
being on the classpath twice?

"Deployment doesn't distinguish between a library and a Java EE module. So if it
contains EJB annotation, it's an EJB module. Does it work differently for you
when you package and deploy your aplication to a regular GF instance?"
But I think this is against the specs, which says that if MODULES is included,
it specifies EJB modules. When MODULES is specified, GF includes the modules,
and also scans the classpath as if MODULES was not specified. Is this correct in
terms of the specs?





[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-13839] ejb-container should not have hard runtime dependency on persistence Created: 06/Oct/10  Updated: 09/Dec/11

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

Type: Bug Priority: Major
Reporter: Snjezana Sevo-Zenzerovic 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


Issue Links:
Dependency
blocks GLASSFISH-11336 glassfish-ejb-lite has a runtime depe... Open
Issuezilla Id: 13,839
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

Quoting parent issue 11336:

<quote>
The "glassfish-ejb-lite" IPS package contains ejb-container.jar which imports
org.glassfish.persistence.common;version="3.0"

The implementation for org.glassfish.persistence.common is part of the
glassfish-jpa package (persistence-common.jar in fact).
glassfish-jpa also drags along glassfish-jca...

ejb-container.jar should not need to import org.glassfish.persistence.common.
(glassfish-jpa should not need to be present to use glassfish-ejb-lite).
</quote>

Looking at ejb-container/pom.xml file, it seems that this is a regression which
was introduced in order to address timer upgrade issue 9645. Given that timer
support is not included in glassfish-ejb-lite package, is it possible to
refactor the fix and move this dependency into glassfish-ejb package which
contains EJB timer support modules?



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

EJB Lite is part of the Web profile which requires JPA to be supported.

EJB Timer Service is an integral part of the ejb-container, and factoring it out
would be an RFE that if needed will be addressed in a future release. But I can
mark the dependency as provided if it would solve the problem.

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

No, marking dependency as "provided" will not resolve the issue since OSGi layer
will still complain at runtime if jpa library is not there, right?

My take would then be to postpone this issue to future release where we can
separate timer related content and get rid of this dependency and in the
meantime I will set IPS package level dependency of glassfish-ejb-lite to
glassfish-jpa to prevent runtime failure.

Comment by marina vatkina [ 06/Oct/10 ]

What goes into into glassfish-ejb package?

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

This is the content of the latest glassfish-ejb package:

http://pkg.glassfish.org/v3/dev/windows/manifest/0/glassfish-ejb%403.1%2C0-23%3A20101005T101815Z

And, this is the content of glassfish-ejb-lite from the same build:

http://pkg.glassfish.org/v3/dev/windows/manifest/0/glassfish-ejb-lite%403.1%2C0-23%3A20101005T101514Z

Comment by marina vatkina [ 06/Oct/10 ]

Yes, it will require moving code to a separate sub-module unless packager can
pick up specific files for one package or the other.

Comment by Snjezana Sevo-Zenzerovic [ 06/Oct/10 ]

No, I most definitely need two separate jars

Anyway, I'll adjust package dependency in 3.1 and we'll revisit in 3.2





[GLASSFISH-13592] asadmin stop-local-instance does not stop instance with outstanding ejb invocation Created: 23/Sep/10  Updated: 08/Dec/10

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

Type: Bug Priority: Major
Reporter: Stephen DiMilla 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: Linux


Attachments: Text File clientside_output.rtf     Text File pidmonitorscript_and_output.rtf     Text File shutdown_jstack.out    
Issue Links:
Dependency
depends on GLASSFISH-13593 Logging is terminated too early durin... Resolved
Issuezilla Id: 13,592
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude

 Description   

I have a distributed cluster (1 das and 3 instances) all on separate machines.
I deploy a ejb web app to the das and cluster. I then send post messages to the
das and each instance which initiates all the instances to start sending
messages between each other. After 15 seconds I issue a asadmin
stop-local-instance to the second instance. The command returns with the following:

Waiting for the instance to stop
..........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-local-instance failed.

I then issue asadmin list-instances clustername and get back:
ins01 running
ins02 not running
ins03 running

I then issue asadmin get-health clustername and get back:
ins01 started since Thu Sep 23 11:29:58 PDT 2010
ins02 started since Thu Sep 23 11:29:58 PDT 2010
ins03 started since Thu Sep 23 11:29:57 PDT 2010

After this I try to connect to the HTTP port of ins02 (using a browser) and get:
Unable able to connect.

The whole time while this situtation was going on I used a script to
monitor the pids of all the java processes on the machine for ins02 and what I
noticed was that I saw the process for the stop-local-instance start and end but
never did the appserver terminate.

Looking in the DAS server log, I was able to determine that the test running
on ins02 finished it's work and sent a message to the das indicating such.

From all this information it appears that the appserver (ins02) was partially
shutdown via the stop-local-instance but that the GMS process and the ejb
container were not stopped and continued to run leaving the appserver in a
inconsistent state.

Debugging this issue is currently blocked as a result of the limited information
contained in the server log. See dependency bug



 Comments   
Comment by Stephen DiMilla [ 23/Sep/10 ]

Created an attachment (id=4950)
scirpt to monitor pids and the output it generated during test

Comment by Stephen DiMilla [ 23/Sep/10 ]

Created an attachment (id=4951)
client side output with debug turned on for CLI commands

Comment by marina vatkina [ 23/Sep/10 ]

I've noticed that even when stop-local-instance succeeds, some mq processes are
not stopped (no JMS was used by the test app)

Comment by Joe Fialli [ 28/Sep/10 ]

Given that the test case is using stateless EJBs to send GMS messages in a heavy
load, there is a chance that GMS under a heavy load is interferring with asadmin
attempt to shutdown server. Until gf issue 13593, logging stopped at beginning
of shutdown, there is no easy way to investigate this. GMSAdapter has a app
server event listener registered. This listener handles SERVER_READY and
SERVER_SHUTDOWN. GMS leaves its group when the handler is invoked with
SERVER_SHUTDOWN. There is an info log message that would confirm if the
eventhandler is properly getting called.

Here is event handler in question from
v3/cluster/gms-adapter/GMSAdapterImpl.initializeGMS()

glassfishEventListener =
new org.glassfish.api.event.EventListener() {
@Override
public void event(Event event) {
...
if (event.is(EventTypes.SERVER_SHUTDOWN))

{ logger.log(Level.INFO, "gmsservice.server_shutdown.received", ...); gms.shutdown(GMSConstants.shutdownType.INSTANCE_SHUTDOWN); events.unregister(glassfishEventListener); }
Comment by Joe Fialli [ 04/Oct/10 ]

progress is being made on dependent issue 13593.
once that is fixed, we will be able to evaluate this issue.

Comment by Joe Fialli [ 12/Oct/10 ]

We moved group-management-service shutdown from being invoked during SERVER_SHUTDOWN to
PREPARE_SHUTDOWN, and GMS is now properly shutting down for this test case in question.

However, the test case uses a stateful EJB to run the test. One EJB invocation last for the duration of the
test (which is 4 -5 minutes typically). However, in this case, we were shutting down one of the clustered
instances in the middle of the test. I will attach complete jstack of process after asadmin stop-instance
has timed out.

Here are two thread traces relevant to application server being in a half shutdown state.
"GlassFish Shutdown Hook" prio=10 tid=0x0000000057ca0800 nid=0x647f waiting on condition
[0x00000000491cf000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00002aaac3933e68> (a
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchroni
    zer.java:1925)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.completeDestruction(POAImpl.java:735)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.performDestroy(POAImpl.java:702)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.run(POAImpl.java:604)
    at com.sun.corba.ee.impl.oa.poa.POAImpl$DestroyThread.doIt(POAImpl.java:583)
    at com.sun.corba.ee.impl.oa.poa.POAImpl.destroy(POAImpl.java:1003)
    at
    com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryManagerImpl.destroy(ReferenceFactoryManagerImpl.java:
    499)
    at com.sun.corba.ee.impl.oa.rfm.ReferenceFactoryImpl.destroy(ReferenceFactoryImpl.java:66)
    at
    org.glassfish.enterprise.iiop.impl.POARemoteReferenceFactory.destroy(POARemoteReferenceFactory.java
    :555)
    at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4353)
    at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4234)
    at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:311)
    at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
    at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:267)
  • locked <0x00002aaabfd48378> (a org.glassfish.internal.data.ModuleInfo)
    at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:277)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:1824)
    at
    com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:42
    7)
    at
    com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:395)
    at
    com.sun.hk2.component.AbstractWombInhabitantImpl.dispose(AbstractWombInhabitantImpl.java:74)
    at com.sun.hk2.component.SingletonInhabitant.release(SingletonInhabitant.java:78)
  • locked <0x00002aaabf553330> (a com.sun.hk2.component.SingletonInhabitant)
    at com.sun.hk2.component.EventPublishingInhabitant.release(EventPublishingInhabitant.java:105)
    at com.sun.hk2.component.LazyInhabitant.release(LazyInhabitant.java:130)
  • locked <0x00002aaabf5532e0> (a com.sun.hk2.component.LazyInhabitant)
    at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:401)
  • locked <0x00002aaabebe69a8> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
  • locked <0x00002aaabebe6980> (a com.sun.enterprise.glassfish.bootstrap.GlassFishImpl)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:194)

"http-thread-pool-18080(2)" daemon prio=10 tid=0x00002aaae5374800 nid=0x6443 waiting on
condition [0x00000000483bf000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.sun.shoal.test.SendBean.sleep(SendBean.java:927)
at com.sun.shoal.test.SendBean.waitTillDone(SendBean.java:629)
at com.sun.shoal.test.SendBean.sendMessage(SendBean.java:171)
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:5363)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:47)
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:862)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5335)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5323)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate
.java:79)
at $Proxy163.sendMessage(Unknown Source)
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.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandle
rImpl.java:244)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.j
ava:155)
at
com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:229)
at
com.sun.shoal.test._SendIF_Remote_DynamicStub.sendMessage(com/sun/shoal/test/_SendIF_Remote
_DynamicStub.java)
at com.sun.shoal.test._SendIF_Wrapper.sendMessage(com/sun/shoal/test/_SendIF_Wrapper.java)
at org.apache.jsp.test_jsp._jspService(test_jsp.java from :133)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:401)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:483)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1522)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
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.jav
a:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)

One could simply recreate this as an ejb unit test by creating a stateful EJB with one method
that sleeps for 10 minutes. The asadmin stop-instance while the method is still being invoked
will time out. Should a wedged EJB invocation being stopping server shutdown?

We realize that the test EJB question needs some work, but we did want to allow someone from ejb-
container to evaluate impact of pending EJB invocation on shutting down the server.

Comment by Joe Fialli [ 12/Oct/10 ]

Created an attachment (id=5131)
jstack of threads still running after asadmin stop-instance has timed out trying to stop an app server with an active EJB invocation





[GLASSFISH-12298] Support for java:comp/env style lookups Created: 19/Jun/10  Updated: 29/Sep/10

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

Type: Improvement Priority: Major
Reporter: aldaris 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: Linux


Issuezilla Id: 12,298

 Description   

Currently it is not possible to use in testcodes the java:comp/env style JNDI
names, only the global JNDI names are working. If you're using embedded
GlassFish for testing, then this could lead to a serious problem (for example if
the production code is using these JNDI names, then the lookup will fail for
tests, but in standalone environment they are working).



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

Embeddable EJB API access

Comment by marina vatkina [ 29/Sep/10 ]

The restriction for java:global is only for the client code. EJBs can still
access java:comp namespace





[GLASSFISH-12251] Hardcoded message in Java File... Created: 15/Jun/10  Updated: 15/Feb/13

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: naman_mehta 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,251
Tags: 3_1-exclude

 Description   

File Location:
ejb/ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java

this.backingStore = factory == null ? null : factory.createBackingStore(conf);
_logger.log(Level.WARNING, "StatefulContainerbuilder instantiated store: " +
backingStore.getClass().getName() + " ==> " + conf.getStoreName());

Need to use message key here and also provide diagnostic info for the same in
properties file.



 Comments   
Comment by naman_mehta [ 20/Jun/10 ]

List of files which has hardcoded messages:

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Portable JNDI names for EJB " +

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.WARNING, "A system exception occurred during an
invocation on EJB " +

ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
throw new NoSuchObjectLocalException("The EJB does not exist."
ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
"The EJB does not exist. key: " + sessionKey);
ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java:
("The EJB does not exist. session-key: " +
sessionKey);

In statefulSessionContainer.java file TRACE_LEVEL is set to FINE so all messages
need to be part of LogStrings.properties file.

ejb/ejb-container/src/main/java/com/sun/ejb/containers/MessageBeanContainer.java:

_logger.log(
Level.WARNING,
"[MDBContainer] Got exception while trying "
+ "to add task to ContainerWorkPool. Will execute "
+ "cleanupResources on current thread",th);

ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Portable JNDI names for EJB " +
ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.INFO, "Glassfish-specific (Non-portable) JNDI names for
EJB " +
ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java:
_logger.log(Level.FINE, "Internal container JNDI names for EJB " +

Comment by naman_mehta [ 26/Aug/10 ]

More hard coded messages found in the code. Please move it to appropriate
LogStrings.properties file. Assign message key, id and diagnostic info for the same.

ejb/ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java:
_logger.log(Level.INFO, "StatefulContainerBuilder.buildStoreManager()
storeName: " + storeName);

Comment by marina vatkina [ 01/Oct/10 ]

->p3

Comment by marina vatkina [ 17/Nov/10 ]

Will need to wait. There was an attempt to help with this issue from the
community, but it didn't go far...

Comment by Cheng Fang [ 13/Apr/11 ]

Fixed StatefulContainerBuilder, and part of BaseContainer.

Sending ejb-container/src/main/java/com/sun/ejb/containers
Sending ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java
Sending ejb-container/src/main/java/com/sun/ejb/containers/builder/StatefulContainerBuilder.java
Sending ejb-container/src/main/resources/com/sun/ejb/containers/LocalStrings.properties
Sending ejb-container/src/main/resources/com/sun/logging/enterprise/system/container/ejb/LogStrings.properties

Committed revision 46126.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[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-12175] "Count" and description not i18ned Created: 08/Jun/10  Updated: 09/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: simonfojtu 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


Attachments: PNG File gfv3_b19_es_06.png    
Issuezilla Id: 12,175
Status Whiteboard:

3.1-exclude

Tags: 3_1-exclude, 3_1_2-exclude

 Description   

How to reproduce:

Login Glassfish, Click Enterprise Server->Monitor->Server

Column "Value" and "Description" is in english for l10n locales (EN, DE, FR).

Version: gfv3u1 b19



 Comments   
Comment by simonfojtu [ 08/Jun/10 ]

Created an attachment (id=4414)
screenshot

Comment by gmurr [ 07/Oct/10 ]

Please reassign if this is not the correct subcomponent.
The strings are hard coded in
transaction/jta/src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java

Comment by Byron Nevins [ 07/Oct/10 ]

reassign to owner

Comment by marina vatkina [ 07/Oct/10 ]

It's not i18-end in all statistic providers





[GLASSFISH-9133] Manual Recover-Transactions after this server instance crash is not supported Created: 14/Aug/09  Updated: 29/Sep/10

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: v2.1.1
Fix Version/s: future release

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

Operating System: Solaris
Platform: Sun


Issuezilla Id: 9,133

 Description   

I have a setup of DAS server connected to two databases (Java DB). I have
deployed an application which connects to both the databases to update tables in
a user transaction. I have used FailureInducer to induce a wait of 60 seconds in
my application during the commit phase. When the transaction waits in the commit
phase (ie, Prepared State), i bring down the appserver using "kill -9" unix
command. Then i start the application server with automatic-recovery configured
as false. But from the log i can observe that during the application server
start-up it is invoking RecoveryManager.recover method.

The transaction recovery does not happen after the application server is
started. Then i executed the command asadmin recover-transactions command. The
command output is given below

./asadmin recover-transactions server
Command recover-transactions executed successfully.

Though it says the command has executed successfully, the transaction recovery
does not happen. The tables are still locked in the database after the execution
of the command. When i do a select query on the table in any one of the two
databases, i am getting the following error message

Error code -1, SQL state 40XL1: A lock could not be obtained within the time
requested
Line 1, column 1

Execution finished after 0 s, 1 error(s) occurred.

I have provided the server log at Finest level for transaction as shown below

[#|2009-08-14T14:54:05.271-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;transactionapp;|CORE5022:
All ejb(s) of [transactionapp] were unloaded successfully!|#]

[#|2009-08-14T14:54:05.311-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;/var/tmp/s1astempdomain1server416256446/transactionapp.ear;|ADM1064:The
upload file at [/var/tmp/s1astempdomain1server416256446/transactionapp.ear]
exists and will be overwritten.|#]

[#|2009-08-14T14:54:05.312-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;/var/tmp/s1astempdomain1server416256446/transactionapp.ear;|ADM1006:Uploading
the file to:[/var/tmp/s1astempdomain1server416256446/transactionapp.ear]|#]

[#|2009-08-14T14:54:05.975-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.deployment|_ThreadID=20;_ThreadName=Thread-3484;|deployed
with moduleid = transactionapp|#]

[#|2009-08-14T14:54:06.180-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;transactionapp;|LDR5010:
All ejb(s) of [transactionapp] loaded successfully!|#]

[#|2009-08-14T14:54:06.572-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Creating tables|#]

[#|2009-08-14T14:54:06.576-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
tx866128|#]

[#|2009-08-14T14:54:06.577-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Executing create table using query :create table tx866128 (Account VARCHAR
(50),bal INTEGER )|#]

[#|2009-08-14T14:54:06.614-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|

  • Executed create Table |#]

[#|2009-08-14T14:54:06.619-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Executing create table using query :create table tx866128 (name VARCHAR (50),bal
INTEGER )|#]

[#|2009-08-14T14:54:06.677-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|

  • Executed create Table |#]

[#|2009-08-14T14:54:06.677-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Creating TxBean for Commit...|#]

[#|2009-08-14T14:54:06.711-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Getting the User Transaction|#]

[#|2009-08-14T14:54:06.712-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Beginning the Tx|#]

[#|2009-08-14T14:54:06.712-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
tx begin...|#]

[#|2009-08-14T14:54:06.712-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Inserting the data|#]

[#|2009-08-14T14:54:06.712-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
insert in TxBean|#]

[#|2009-08-14T14:54:06.712-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=CurrentImpl;MethodName=begin();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Before
invoking create() on TxFactory|#]

[#|2009-08-14T14:54:06.713-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionFactoryImpl;MethodName=localCreate();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Control
object :com.sun.jts.CosTransactions.ControlImpl@1d344e7 corresponding to this
transaction has been createdGTID is :
0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:06.713-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=CurrentImpl;MethodName=begin();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Before
invoking CurrentTransaction.setCurrent(control,true)|#]

[#|2009-08-14T14:54:06.713-0700|FINER|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TopCoordinator;MethodName=register_synchronization();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|SynchronizationImpl
:com.sun.jts.jta.SynchronizationImpl@150a3dc has been registeredwith
TopCoordinator :GTID is :
0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:06.713-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TopCoordinator;MethodName=register_resource();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|OTSResource
OTSResource : XAResource com.sun.gjc.spi.XAResourceImpl@135ca6c XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

has been registeredGTID
is:0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:06.714-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Got DB Connection Successfully...|#]

[#|2009-08-14T14:54:06.715-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TopCoordinator;MethodName=register_resource();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|OTSResource
OTSResource : XAResource com.sun.gjc.spi.XAResourceImpl@4ee7c0 XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

has been registeredGTID
is:0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:06.719-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Got DB Connection Successfully...|#]

[#|2009-08-14T14:54:06.763-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
Account added Successfully...|#]

[#|2009-08-14T14:54:06.763-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
before committing the tx sleeping for 20 Secs...|#]

[#|2009-08-14T14:54:06.764-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=com.sun.jts.pi.InterceptorImpl;MethodName=send_request;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|
sending_request[42] : _is_a, ThreadName :
Thread[httpSSLWorkerThread-8080-1,10,Grizzly]|#]

[#|2009-08-14T14:54:06.765-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=com.sun.jts.pi.InterceptorImpl;MethodName=receive_request_service_contexts;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|
received_request[42] : _is_a, ThreadName :
Thread[httpSSLWorkerThread-8080-1,10,Grizzly]|#]

[#|2009-08-14T14:54:06.767-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=com.sun.jts.pi.InterceptorImpl;MethodName=send_request;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|
sending_request[43] : getGlobalTID, ThreadName :
Thread[httpSSLWorkerThread-8080-1,10,Grizzly]|#]

[#|2009-08-14T14:54:06.768-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=com.sun.jts.pi.InterceptorImpl;MethodName=receive_request_service_contexts;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|
received_request[43] : getGlobalTID, ThreadName :
Thread[httpSSLWorkerThread-8080-1,10,Grizzly]|#]

[#|2009-08-14T14:54:06.771-0700|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;|
before commit ...|#]

[#|2009-08-14T14:54:06.771-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisterdSyncs;MethodName=distributeBefore();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Before
invoking before_completion() on synchronization object
com.sun.jts.jta.SynchronizationImpl@150a3dc|#]

[#|2009-08-14T14:54:06.775-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisterdSyncs;MethodName=distributeBefore();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|After
invoking before_completion() on synchronization object
com.sun.jts.jta.SynchronizationImpl@150a3dc|#]

[#|2009-08-14T14:54:06.775-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Acquiring
read lock on freeze : state PREPARING|#]

[#|2009-08-14T14:54:06.775-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Acquired
read lock on freeze : state PREPARING|#]

[#|2009-08-14T14:54:06.775-0700|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;0;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|JTS5057:
FailPoint : [0]|#]

[#|2009-08-14T14:54:06.775-0700|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|JTS5057:
FailPoint : [null]|#]

[#|2009-08-14T14:54:06.776-0700|FINER|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisteredResources;MethodName=prepare();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Before
invoking prepare() on resource:OTSResource : XAResource
com.sun.gjc.spi.XAResourceImpl@135ca6c XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

|#]

[#|2009-08-14T14:54:06.780-0700|FINER|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisteredResources;MethodName=prepare();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|After
invoking prepare() on resource:OTSResource : XAResource
com.sun.gjc.spi.XAResourceImpl@135ca6c XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

;This resource voted :
org.omg.CosTransactions.Vote@17750ef|#]

[#|2009-08-14T14:54:06.780-0700|FINER|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisteredResources;MethodName=prepare();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Before
invoking prepare() on resource:OTSResource : XAResource
com.sun.gjc.spi.XAResourceImpl@4ee7c0 XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

|#]

[#|2009-08-14T14:54:06.788-0700|FINER|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=RegisteredResources;MethodName=prepare();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|After
invoking prepare() on resource:OTSResource : XAResource
com.sun.gjc.spi.XAResourceImpl@4ee7c0 XID

{XID: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

;This resource voted :
org.omg.CosTransactions.Vote@17750ef|#]

[#|2009-08-14T14:54:06.788-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Releasing
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:06.788-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Released
read lock on freeze|#]

[#|2009-08-14T14:54:06.788-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Released
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:06.789-0700|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;1;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|JTS5057:
FailPoint : [1]|#]

[#|2009-08-14T14:54:06.797-0700|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|JTS5057:
FailPoint : [null]|#]

[#|2009-08-14T14:54:06.797-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TopCoordinator;MethodName=commit();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Within
TopCoordinator.commit()GTID is
:0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:06.797-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Acquiring
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:06.797-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=TransactionState;MethodName=setState();_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|Acquired
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:06.797-0700|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-1;2;_RequestID=bec4fc9e-9613-46ee-a65c-aa67c0ca4a41;|JTS5057:
FailPoint : [2]|#]

Aug 14, 2009 2:54:31 PM com.sun.enterprise.admin.servermgmt.launch.ASLauncher
buildCommand
INFO:
/usr/jdk/instances/jdk1.5.0/jre/../bin/java
-Dcom.sun.aas.instanceRoot=/export/nachi/V2/Appserver/glassfish/domains/domain1
-Dcom.sun.aas.ClassPathPrefix=
-Dcom.sun.aas.ClassPathSuffix=
-Dcom.sun.aas.ServerClassPath=
-Dcom.sun.aas.classloader.appserverChainJars.ee=
-Dcom.sun.aas.classloader.appserverChainJars=admin-cli.jar,admin-cli-ee.jar,j2ee-svc.jar
-Dcom.sun.aas.classloader.excludesList=admin-cli.jar,appserv-upgrade.jar,sun-appserv-ant.jar
-Dcom.sun.aas.classloader.optionalOverrideableChain.ee=
-Dcom.sun.aas.classloader.optionalOverrideableChain=webservices-rt.jar,webservices-tools.jar
-Dcom.sun.aas.classloader.serverClassPath.ee=/lib/hadbjdbc4.jar,/export/nachi/V2/Appserver/glassfish/lib/SUNWjdmk/5.1/lib/jdmkrt.jar,/lib/dbstate.jar,/lib/hadbm.jar,/lib/hadbmgt.jar,/opt/SUNWmfwk/lib/mfwk_instrum_tk.jar
-Dcom.sun.aas.classloader.serverClassPath=/export/nachi/V2/Appserver/glassfish/lib/install/applications/jmsra/imqjmsra.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/jaxm-api.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/fscontext.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqbroker.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqjmx.jar,/export/nachi/V2/Appserver/glassfish/lib/ant/lib/ant.jar,/export/nachi/V2/Appserver/glassfish/lib/SUNWjdmk/5.1/lib/jdmkrt.jar
-Dcom.sun.aas.classloader.sharedChainJars.ee=appserv-se.jar,appserv-ee.jar,jesmf-plugin.jar,/lib/dbstate.jar,/lib/hadbjdbc4.jar,jgroups-all.jar,/opt/SUNWmfwk/lib/mfwk_instrum_tk.jar
-Dcom.sun.aas.classloader.sharedChainJars=javaee.jar,/usr/jdk/instances/jdk1.5.0/jre/../lib/tools.jar,install/applications/jmsra/imqjmsra.jar,com-sun-commons-launcher.jar,com-sun-commons-logging.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/jaxm-api.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/fscontext.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqbroker.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqjmx.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqxm.jar,webservices-rt.jar,webservices-tools.jar,mail.jar,appserv-jstl.jar,jmxremote_optional.jar,/export/nachi/V2/Appserver/glassfish/lib/SUNWjdmk/5.1/lib/jdmkrt.jar,activation.jar,appserv-rt.jar,appserv-admin.jar,appserv-cmp.jar,/export/nachi/V2/Appserver/glassfish/updatecenter/lib/updatecenter.jar,/export/nachi/V2/Appserver/glassfish/jbi/lib/jbi.jar,/export/nachi/V2/Appserver/glassfish/imq/lib/imqjmx.jar,/export/nachi/V2/Appserver/glassfish/lib/ant/lib/ant.jar,dbschema.jar
-Dcom.sun.aas.configName=server-config
-Dcom.sun.aas.configRoot=/export/nachi/V2/Appserver/glassfish/config
-Dcom.sun.aas.defaultLogFile=/export/nachi/V2/Appserver/glassfish/domains/domain1/logs/server.log
-Dcom.sun.aas.domainName=domain1
-Dcom.sun.aas.installRoot=/export/nachi/V2/Appserver/glassfish
-Dcom.sun.aas.instanceName=server
-Dcom.sun.aas.processLauncher=SE
-Dcom.sun.aas.promptForIdentity=true
-Dcom.sun.appserv.pluggable.features=com.sun.enterprise.ee.server.pluggable.EEPluggableFeatureImpl
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Dcom.sun.enterprise.overrideablejavaxpackages=javax.help,javax.portlet
-Dcom.sun.enterprise.taglibs=appserv-jstl.jar,jsf-impl.jar
-Dcom.sun.enterprise.taglisteners=jsf-impl.jar
-Dcom.sun.updatecenter.home=/export/nachi/V2/Appserver/glassfish/updatecenter
-Ddomain.name=domain1
-Djava.endorsed.dirs=/export/nachi/V2/Appserver/glassfish/lib/endorsed
-Djava.ext.dirs=/usr/jdk/instances/jdk1.5.0/jre/../lib/ext:/usr/jdk/instances/jdk1.5.0/jre/../jre/lib/ext:/export/nachi/V2/Appserver/glassfish/domains/domain1/lib/ext:/export/nachi/V2/Appserver/glassfish/javadb/lib:/export/nachi/V2/Appserver/glassfish/lib/jdbcdrivers
-Djava.library.path=/export/nachi/V2/Appserver/glassfish/lib:/export/nachi/V2/Appserver/glassfish/lib:/export/nachi/V2/Appserver/glassfish/lib
-Djava.security.auth.login.config=/export/nachi/V2/Appserver/glassfish/domains/domain1/config/login.conf
-Djava.security.policy=/export/nachi/V2/Appserver/glassfish/domains/domain1/config/server.policy
-Djava.util.logging.manager=com.sun.enterprise.server.logging.ServerLogManager
-Djavax.management.builder.initial=com.sun.enterprise.ee.admin.AppServerMBeanServerBuilder
-Djavax.net.ssl.keyStore=/export/nachi/V2/Appserver/glassfish/domains/domain1/config/keystore.jks
-Djavax.net.ssl.trustStore=/export/nachi/V2/Appserver/glassfish/domains/domain1/config/cacerts.jks
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Djmx.invoke.getters=true
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-client
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-Xmx512m
-XX:NewRatio=2
-XX:+LogVMOutput
-XX:LogFile=/export/nachi/V2/Appserver/glassfish/domains/domain1/logs/jvm.log
-cp
/export/nachi/V2/Appserver/glassfish/lib/jhall.jar:/export/nachi/V2/Appserver/glassfish/lib/appserv-launch.jar
com.sun.enterprise.server.PELaunch
start
[#|2009-08-14T14:54:33.527-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;Java
HotSpot(TM) Client VM;1.5.0_12;Sun Microsystems Inc.;|CORE5076: Using [Java
HotSpot(TM) Client VM, Version 1.5.0_12] from [Sun Microsystems Inc.]|#]

[#|2009-08-14T14:54:33.593-0700|INFO|sun-appserver2.1|javax.enterprise.resource.jms|_ThreadID=11;_ThreadName=pool-1-thread-7;|Using
MQ RA for Broker lifecycle control|#]

[#|2009-08-14T14:54:33.635-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=12;_ThreadName=pool-1-thread-4;|SEC1002:
Security Manager is OFF.|#]

[#|2009-08-14T14:54:35.671-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;com.sun.enterprise.security.provider.PolicyWrapper;|SEC1143:
Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]

[#|2009-08-14T14:54:36.301-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;server;|WEB0114:
SSO is disabled in virtual server [server]|#]

[#|2009-08-14T14:54:36.313-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|ThreadID=10;_ThreadName=main;_asadmin;|WEB0114:
SSO is disabled in virtual server [__asadmin]|#]

[#|2009-08-14T14:54:36.318-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;com.ericsson.ssa.config.ConvergedContextConfig;|REgistering
Custom ContextConfig|#]

[#|2009-08-14T14:54:36.318-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;com.ericsson.ssa.config.ConvergedContextImpl;|REgistering
Custom Context|#]

[#|2009-08-14T14:54:36.724-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=Configuration;MethodName=setProperties();_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|
Properties set are :

{ [ com.sun.jts.heuristicDirection->rollback ] [ com.sun.jts.logDirectory->/export/nachi/V2/Appserver/glassfish/domains/domain1/logs/server/tx ] [ com.sun.jts.commitRetry->600 ] [ com.sun.jts.keypointCount->65536 ] [ com.sun.jts.persistentServerId->3700 ] [ com.sun.jts.instancename->server ] }|#]

[#|2009-08-14T14:54:37.407-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=com.sun.jts.pi.InterceptorImpl;MethodName=<init>;_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|Transaction
INTEROP Mode: true|#]

[#|2009-08-14T14:54:38.463-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=Configuration;MethodName=setProperties();_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|
Properties set are :{ [ com.sun.jts.heuristicDirection->rollback ] [com.sun.jts.logDirectory->/export/nachi/V2/Appserver/glassfish/domains/domain1/logs/server/tx] [ com.sun.jts.commitRetry->600 ] [ com.sun.jts.keypointCount->65536 ] [com.sun.jts.persistentServerId->3700 ] [ com.sun.jts.instancename->server ] }

|#]

[#|2009-08-14T14:54:38.464-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;3700;|JTS5014:
Recoverable JTS instance, serverId = [3700]|#]

[#|2009-08-14T14:54:38.464-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=com.sun.jts.CosTransactions.Configuration;MethodName=getPropertyValue;_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|Property
:com.sun.jts.instancename has the value : server|#]

[#|2009-08-14T14:54:38.475-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=Configuration;MethodName=getDirectory();_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|Using
directory = /export/nachi/V2/Appserver/glassfish/domains/domain1/logs/server/tx
: provided in configuration|#]

[#|2009-08-14T14:54:38.479-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=Configuration;MethodName=setServerName();_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|
serverName = glassfish-x86-1,server,P3700; isRecoverable = true|#]

[#|2009-08-14T14:54:38.506-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=10;_ThreadName=main;ClassName=RecoveryManager;MethodName=initialise();_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|Before
starting ResyncThread |#]

[#|2009-08-14T14:54:38.507-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=ResyncThread;MethodName=run();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Before
invoking RecoveryManager.recover()|#]

[#|2009-08-14T14:54:38.513-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=com.sun.jts.CosTransactions.Configuration;MethodName=getPropertyValue;_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Property
:com.sun.jts.keypointCount has the value : 65536|#]

[#|2009-08-14T14:54:38.515-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=Configuration;MethodName=getDirectory();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Using
directory = /export/nachi/V2/Appserver/glassfish/domains/domain1/logs/server/tx
: provided in configuration|#]

[#|2009-08-14T14:54:38.549-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=RecoveryManager;MethodName=recover();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Before
invoking proceedWithXARecovery()|#]

[#|2009-08-14T14:54:38.549-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=com.sun.jts.CosTransactions.Configuration;MethodName=getPropertyValue;_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Property
:com.sun.jts.ManualRecovery has the value : null|#]

[#|2009-08-14T14:54:38.550-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=RecoveryManager;MethodName=resync();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Before
invoking commit on the reconstructed coordinatorGTID is:
0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:38.550-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TopCoordinator;MethodName=commit();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Within
TopCoordinator.commit()GTID is
:0300000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:38.551-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Acquiring
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:38.551-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Acquired
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:38.556-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Releasing
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:38.556-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Released
read lock on freeze|#]

[#|2009-08-14T14:54:38.556-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Released
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:38.566-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=RecoveryManager;MethodName=resync();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Before
invoking commit on the reconstructed coordinatorGTID is:
0200000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:38.566-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TopCoordinator;MethodName=commit();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Within
TopCoordinator.commit()GTID is
:0200000000DDBF1A676C617373666973682D7838362D312C7365727665722C5033373030|#]

[#|2009-08-14T14:54:38.567-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Acquiring
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:38.567-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Acquired
read lock on freeze : state COMMITTING|#]

[#|2009-08-14T14:54:38.567-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Releasing
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:38.567-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Released
read lock on freeze|#]

[#|2009-08-14T14:54:38.567-0700|FINEST|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=13;_ThreadName=JTS
Resync
Thread;ClassName=TransactionState;MethodName=setState();_RequestID=c5c179bd-9f91-4f0f-869e-4dd45fb4e903;|Released
read lock on freeze : state Illegal state |#]

[#|2009-08-14T14:54:38.821-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=10;_ThreadName=main;|ADM1079:
Initialization of AMX MBeans started|#]

[#|2009-08-14T14:54:39.090-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=14;_ThreadName=Thread-16;service:jmx:rmi:///jndi/rmi://glassfish-x86-1:8686/jmxrmi;|ADM1504:
Here is the JMXServiceURL for the Standard JMXConnectorServer:
[service:jmx:rmi:///jndi/rmi://glassfish-x86-1:8686/jmxrmi]. This is where the
remote administrative clients should connect using the standard JMX connectors|#]

[#|2009-08-14T14:54:39.090-0700|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=14;_ThreadName=Thread-16;true;|ADM1506:
Status of Standard JMX Connector: Active = [true]|#]

[#|2009-08-14T14:54:39.762-0700|INFO|sun-appserver2.1|javax.enterprise.resource.resourceadapter|_ThreadID=10;_ThreadName=main;|JMS
Service Connection URL is :mq://glassfish-x86-1:7676/|#]

[#|2009-08-14T14:54:39.784-0700|INFO|sun-appserver2.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101:
SJSMQ JMS Resource Adapter starting...|#]

[#|2009-08-14T14:54:40.758-0700|INFO|sun-appserver2.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_EB1101:
EMBEDDED broker started with code =0|#]

[#|2009-08-14T14:54:40.760-0700|INFO|sun-appserver2.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101:
SJSMQ JMSRA Started:DIRECT|#]

[#|2009-08-14T14:54:41.929-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=10;_ThreadName=main;MEjbApp;|LDR5010:
All ejb(s) of [MEjbApp] loaded successfully!|#]

[#|2009-08-14T14:54:42.822-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.ejb|ThreadID=10;_ThreadName=main;jdbc/_TimerPool;|EJB5109:EJB
Timer Service started successfully for datasource [jdbc/__TimerPool]|#]

[#|2009-08-14T14:54:42.822-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.classloading|ThreadID=10;_ThreadName=main;_ejb_container_timer_app;|LDR5010:
All ejb(s) of [__ejb_container_timer_app] loaded successfully!|#]

[#|2009-08-14T14:54:43.127-0700|INFO|sun-appserver2.1|com.sun.jbi.framework|_ThreadID=15;_ThreadName=pool-1-thread-3;|JBIFW0010:
JBI framework ready to accept requests.|#]

[#|2009-08-14T14:54:43.251-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=10;_ThreadName=main;transactionapp;|LDR5010:
All ejb(s) of [transactionapp] loaded successfully!|#]

[#|2009-08-14T14:54:43.261-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;|WEB0302:
Starting Sun-Java-System/Application-Server.|#]

[#|2009-08-14T14:54:43.585-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;8080;|WEB0712:
Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080|#]

[#|2009-08-14T14:54:43.651-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;8181;|WEB0712:
Starting Sun-Java-System/Application-Server HTTP/1.1 on 8181|#]

[#|2009-08-14T14:54:43.663-0700|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;4848;|WEB0712:
Starting Sun-Java-System/Application-Server HTTP/1.1 on 4848|#]

[#|2009-08-14T14:54:44.200-0700|INFO|sun-appserver2.1|javax.enterprise.system.core.selfmanagement|_ThreadID=10;_ThreadName=main;|SMGT0007:
Self Management Rules service is enabled|#]

[#|2009-08-14T14:54:44.654-0700|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=10;_ThreadName=main;_RequestID=8c02f4b9-e82b-476c-b71e-4c6b77e3ef57;|EJBLifeCycle:
Automatic timer migration component not enabled for DAS instance|#]

[#|2009-08-14T14:54:44.674-0700|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Application
server startup complete.|#]

[#|2009-08-14T14:57:49.290-0700|WARNING|sun-appserver2.1|javax.enterprise.resource.resourceadapter|ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_CallFlowPool;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|RAR5005:Error
in accessing XA resource with JNDI name [__CallFlowPool] for recovery|#]

[#|2009-08-14T14:57:49.294-0700|WARNING|sun-appserver2.1|javax.enterprise.resource.resourceadapter|ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_TimerPool;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|RAR5005:Error
in accessing XA resource with JNDI name [__TimerPool] for recovery|#]

[#|2009-08-14T14:57:49.295-0700|INFO|sun-appserver2.1|javax.enterprise.resource.resourceadapter|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;|Recovery
of Inbound Transactions started.|#]

[#|2009-08-14T14:57:49.296-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=getInDoubtXids();_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|Before
receiving inDoubtXids from xaresource = com.sun.gjc.spi.XAResourceImpl@1601539|#]

[#|2009-08-14T14:57:49.298-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=getInDoubtXid();_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|InDoubtXids
returned from xaresource = com.sun.gjc.spi.XAResourceImpl@1601539are: Xid class
name is org.apache.derby.client.ClientXid Number of Xids are 4 [

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 9D753F1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)} {ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(02000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)} {ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(04000000 0EEDF919 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)} {ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

]|#]

[#|2009-08-14T14:57:49.299-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 9D753F1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

|#]

[#|2009-08-14T14:57:49.305-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(02000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

|#]

[#|2009-08-14T14:57:49.305-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(04000000 0EEDF919 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

|#]

[#|2009-08-14T14:57:49.305-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C01)}

|#]

[#|2009-08-14T14:57:49.306-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=getInDoubtXids();_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|Before
receiving inDoubtXids from xaresource = com.sun.gjc.spi.XAResourceImpl@11d3f0b|#]

[#|2009-08-14T14:57:49.306-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=getInDoubtXid();_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|InDoubtXids
returned from xaresource = com.sun.gjc.spi.XAResourceImpl@11d3f0bare: Xid class
name is org.apache.derby.client.ClientXid Number of Xids are 3 [

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 9D753F1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)} {ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(04000000 0EEDF919 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)} {ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

]|#]

[#|2009-08-14T14:57:49.306-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 9D753F1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

|#]

[#|2009-08-14T14:57:49.307-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(04000000 0EEDF919 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

|#]

[#|2009-08-14T14:57:49.307-0700|FINE|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;ClassName=RecoveryManager;MethodName=recoverIncompleteTx;_RequestID=302b7b14-105d-429a-96bd-f952d6676e99;|
This xid is UNIQUE

{ClientXid: formatID(4871251), gtrid_length(36), bqual_length(30), data(03000000 00DDBF1A 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 676C6173 73666973 682D7838 362D312C 73657276 65722C50 33373030 2C00)}

|#]



 Comments   
Comment by marina vatkina [ 17/Aug/09 ]

Can it be the same problem as CR 6673688? The recovery skips resources that are
not up by the time the revovery is happening?

Comment by nachi_glassfish [ 17/Aug/09 ]

This is a different scenario. In this case, the application server is brought
down and started again. The resources are always are up and running.

Comment by marina vatkina [ 17/Aug/09 ]

It might still be an error in Derby with the lock handling

Comment by marina vatkina [ 23/Oct/09 ]

not a blocker

Comment by marina vatkina [ 17/Nov/09 ]

Unfortunately the scenario described in this bug - server crash and automatic
recovery not enabled - is not a supported option.

Manual recovery is supported only for a resource recovery on a live server, that
is when one of the resource manager dies and comes and you want to perform recovery.

I'll file a separate doc bug to document this limitation, but I'm changing this
issue to be an RFE for the next release

Comment by marina vatkina [ 03/Jun/10 ]

The problem applies to non-delegated recovery only





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

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1_ms07
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-14394] Enable EJB Timer Service to start/stop when its resource is enabled/disabled Created: 03/Nov/10  Updated: 13/Dec/10

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

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: Macintosh


Issuezilla Id: 14,394

 Description   

See issues 1132, 13848, and 13127

To avoid some of the problems EJB Timer Service should subscribe to its resource
config changes for enabled=false/true using ConfigListener mechanism.






[GLASSFISH-14188] TM should listen to stop instance event to rollback active transactions Created: 25/Oct/10  Updated: 17/Mar/11

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

Type: Improvement Priority: Major
Reporter: sherryshen 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: 14,188
Tags: 3_1-exclude

 Description   

Inconsistent global tx with stop/start cluster instance
glassfish-3.1-b25.zip

The admincli delegated recovery tests have the cases with kill or stop instance.

Following the suggestion:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=13884
"Please change the test to kill the instance while transaction is
in the prepare phase to test transaction-recovery.
Stopped instance can rollback it's connections."

I disabled the tests with stop instance, the delegated recovery works
fine on oracle db.

With looking into the failure in details, inconsistent global tx
with stop/start cluster instance is observed with or without the delegated recovery.

I created a target to run tests without admincli delegated recovery as below,
and run tests for oracle, mysql, or derby in sqe env.

% cd $SPS_HOME/pe/transaction/recovery/cliweb2
% ant ee oracle4 all_dbg
% ant ee mysql all_dbg
% ant ee all_dbg

where all_dbg target has 2 tests,
t4-stopInstanceNoRecovery
t5-stopStartInstanceRecovery

t4 passed in all 3 runs.
t5 failed in 2 runs, but passed in 1 run.

http://sqe-hudson.sfbay.sun.com:8080/hudson/view/Sherry_v31/job/sherry-txnd-clu-db/

#19 oracle4, cliweb2, run_dbg
DB1=oracle, DB2=derby
[java] Processing line: RESULTS:3
[java] FAILURE
[java] did not get expectedResult=RESULTS:6
[java] - tx-cliweb2-t5-stopStartInstanceRecovery: FAIL -
[#|2010-10-25T10:06:26.478-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
VerifyServlet,type=two|#]
[#|2010-10-25T10:06:26.482-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE1 : BBB480801|#]
[#|2010-10-25T10:06:26.482-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE2 : BBB480802|#]
[#|2010-10-25T10:06:26.482-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE3 : BBB480803|#]
[#|2010-10-25T10:06:26.488-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
-------verifyxa, DB1: 3; DB2: 0|#]
[#|2010-10-25T10:06:26.494-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
two, ret=3|#]

#20 oracle4, cliweb2, run_dbg
DB1=mysql, DB2=derby
[java] - tx-cliweb2-t5-stopStartInstanceRecovery: FAIL -

[#|2010-10-25T10:28:19.767-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
VerifyServlet,type=two|#]
[#|2010-10-25T10:28:22.084-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO1 : BBB480801|#]
[#|2010-10-25T10:28:22.084-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO2 : BBB480802|#]
[#|2010-10-25T10:28:22.084-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO3 : BBB480803|#]
[#|2010-10-25T10:28:22.086-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
-------verifyxa, DB1: 0; DB2: 3|#]
[#|2010-10-25T10:28:22.290-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
two, ret=3|#]

#21, derby, cliweb2, run_dbg
DB1=derby, DB2=derby
[java] - tx-cliweb2-t5-stopStartInstanceRecovery: PASS -

[#|2010-10-25T10:45:05.578-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
VerifyServlet,type=two|#]

[#|2010-10-25T10:45:07.652-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE1 : BBB480801|#]

[#|2010-10-25T10:45:07.653-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE2 : BBB480802|#]

[#|2010-10-25T10:45:07.653-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBONE3 : BBB480803|#]

[#|2010-10-25T10:45:07.699-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO1 : BBB480801|#]

[#|2010-10-25T10:45:07.700-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO2 : BBB480802|#]

[#|2010-10-25T10:45:07.700-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
Found: BAA48080DBTWO3 : BBB480803|#]

[#|2010-10-25T10:45:07.700-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
-------verifyxa, DB1: 3; DB2: 3|#]

[#|2010-10-25T10:45:07.705-0700|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Thread-1;|
two, ret=6|#]



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

I'm not sure I understand where is the problem.

Is it that Oracle rolls back a prepared transaction if the instance is stopped
(i.e. connection.close() is called)?

Comment by marina vatkina [ 28/Oct/10 ]

Will need to look at cleaner tx completion on instance stop. This is the same
behavior as in the prior releases.





[GLASSFISH-7138] EJB-7 ThreadPool for TimerService & Async methods Created: 04/Feb/09  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur2
Fix Version/s: future release

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

Operating System: All
Platform: All


Issuezilla Id: 7,138

 Description   

When scheduling a Timer, it would be ideal if I could specify, one way or
another, which ThreadPool the timer would run in.

This would allow me to schedule many timers without worrying that there could
be 200 timers firing simultaneously, all contending for locks, sockets, memory,
and other resources that could best be used elsewhere given that most of the
timers will contend for the same lock and just block waiting for each other
anyway (in my case).

Ideally this would not be specified on a per-timer or, if that is not possible,
a per-bean basis.



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

Async methods are also requested

Comment by marina vatkina [ 09/Jun/10 ]
      • Issue 11393 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 07/Sep/10 ]

More work than expected

Comment by Cheng Fang [ 15/Nov/11 ]

A related issue http://java.net/jira/browse/GLASSFISH-16735 has been fixed in 3.1.2 and 4.0 to make ejb default thread pool configurable.

More work is needed to support assigning specific thread pool to a bean, or its timeout method.

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-6884] LogFile performance Created: 08/Dec/08  Updated: 08/Nov/10

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: 9.1peur1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: dernasherbrezon 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


Attachments: PNG File perf threads.PNG     PNG File perf threads.PNG    
Issuezilla Id: 6,884

 Description   

Saw picture (in attachement) in profiler.

red - block
orange - wait
green - act
blue - I/O

Some explanation:
when mdb delivery ends (afterDelivery() called) then transaction will be
commited. That cause thread block against com.sun.jts.CosTransactions.LogFile.
In this file all methods are synchronized on this. Additionally profiler says
that all threads waiting the same monitor (the same instance of LogFile)!

There are mutliple LogFile objects must be created or, according to Logfile
source code, com.sun.jts.CosTransactions.LogHandle and LogFile must support
concurrent access.



 Comments   
Comment by dernasherbrezon [ 08/Dec/08 ]

Created an attachment (id=2134)
logfile concurrent usage

Comment by dernasherbrezon [ 08/Dec/08 ]

Created an attachment (id=2135)
logfile concurrent usage

Comment by marina vatkina [ 09/Dec/08 ]

...

Comment by marina vatkina [ 05/Oct/10 ]

This will require complete redesign...

Comment by marina vatkina [ 08/Nov/10 ]
      • Issue 14465 has been marked as a duplicate of this issue. ***




[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-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-7164] RollbackOnly status if transaction is propagated from remote invocation Created: 10/Feb/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: 9.0pe
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: caramis 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: All


Attachments: Zip Archive test7164.zip    
Issuezilla Id: 7,164
Tags: ee7ri_cleanup_deferred

 Description   

RollbackOnly status in required transaction is not propergated from remote.

1. client(remote POJO) : lookup UserTransaction from server
2. client(remote POJO) : begin UserTransaction
3. client(remote POJO) : call stateless session bean in server(CMT, Required)
4. server(EJB) : get SessionContext and call setRollbackOnly() and return
5. client(remote POJO) : get status from UserTransaction
(status is STATUS_ACTIVE(0), I guess it must be STATUS_MARKED_ROLLBACK(1))
6. client(remote POJO) : commit UserTransaction
(no exception is occured, I guess it must throws
javax.transaction.RollbackException)

(If server's session bean throws RemoteException...
client's transaction status is STATUS_MARKED_ROLLBACK and throws
javax.transaction.RollbackException)



 Comments   
Comment by ksak [ 10/Feb/09 ]

The EJBContext.setRollbackOnly() implementation calls setRollbackOnly directly on the transaction
manager. If that information is not propagated to the distributed caller it could be an issue in the
transaction infrastructure. Reassigning to the transaction module for further analysis.

Comment by marina vatkina [ 10/Feb/09 ]

Transaction propagation is not a supported feature, but I'll look at it. Which
exactly version are you using?

Comment by marina vatkina [ 10/Feb/09 ]

I means from a client to the server.

Comment by marina vatkina [ 10/Feb/09 ]

I tested it on v2.1 (9.1.1) and while the status is not propagated back from the
server, the transaction is correctly rolled back and the client got expected
javax.transaction.RollbackException.

Comment by caramis [ 10/Feb/09 ]

I tested it on v2.1 too, and tested it again but I got a same result.
Stand-alone client is on my desktop(eclipse), and server is on remote Linux machine.

It also causes a problem with 'RequiresNew'.
If a session bean throws RemoteException when calling 'RequiresNew' from remote,
local transaction status shows STATUS_MARKED_ROLLBACK.
And, if I try commit, it also gives me RollbackExcetpion.

But, since it's a 'RequiresNew' transaction,
I think the status should be STATUS_ACTIVE and commit should be processed
properly according to the EJB specifications.

Comment by marina vatkina [ 10/Feb/09 ]

Are you using application client or a standalone java client? My test uses
appclient container.

How does your code treat RollbackException from the EJB? Does it ignore it?

It is correct to rollback a transaction if commit fails and throw
RollbackException - the JTA spec says: that it is "Thrown to indicate that the
transaction has been rolled back rather than committed."

Comment by marina vatkina [ 10/Feb/09 ]

Created an attachment (id=2266)
Test case that I used

Comment by caramis [ 12/Feb/09 ]

I use standalone java client.

And... If you tell about second case(RequiresNew)...
You are right, It is correct to rollback a transaction if commit fails and throw
RollbackException.
But in the case of RequiresNew transaction, I think current transaction must be
committed successfully(if there are no other factors) while nested transaction
is rolled back.

Comment by caramis [ 12/Feb/09 ]

Looking at your test case, it seems a client and a server exist in a same JVM
process.
If so, please test them in different JVMs using standalone bare client.

Comment by marina vatkina [ 12/Feb/09 ]

My test runs the client code in the application client container, so a separate JVM.

Comment by marina vatkina [ 11/Jun/09 ]

Status propagation is not a required feature. But we can look at adding it to
the request and response.





[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-17022] 3.1.1 startup/deployment performance - jta.jar Created: 12/Jul/11  Updated: 12/Jul/11

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

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

Attachments: File v1.war    

 Description   

Tom noticed the jta.jar was loaded even the JTA is not used in the application. File the issue to track this and assign to naming module for investigation.
=============================================================================
I noticed that container-common code (com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl) injects a TransactionManager object, and this brings in the jta.jar file, even if JTA is never used in the application. Also, the FactoryForEntityManagerWrapper.create method which uses the injected TransactionManager isn't actually called during server startup.

I don't know what thread this happens on or whether it is on the critical path for server initializaiton, but avoiding this injection might save some time.



 Comments   
Comment by Hong Zhang [ 12/Jul/11 ]

the application used by the performance measurement

Comment by marina vatkina [ 12/Jul/11 ]

jta.jar is loaded for several reasons. To change it is a redesign.

Comment by Hong Zhang [ 12/Jul/11 ]

marina: can you explain more about why this is by design?

Comment by marina vatkina [ 12/Jul/11 ]

1. TransactionRecoveryWrapper is a Startup service. If the recovery is enabled, it needs to be performed before the 1st tx starts (otherwise it becomes too complicated).

2. TransactionNamingProxy registers itself with the naming manager, so that a TM, or UTx, or the newer TransactionSynchronizationRegistry can be looked up.

3. TransactionSynchronizationRegistry also pre-registers "UserTransaction" (and this is why you probably saw the naming dependency as well). Because this name (CCC didn't allow us to drop it) doesn't have "java:" in its prefix, it needs to be pre-registered statically (i.e. at startup)

4. Even if the user code doesn't use transactions, JavaEETransactionManager is injected into various services (why would we have @Inject otherwise?). The impl class for this interface is also in the jta.jar.





[GLASSFISH-17012] server.ejb-container.property.disable-nonportable-jndi-names="true" as the default Created: 11/Jul/11  Updated: 15/Feb/13

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

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:

Win7 Pro SP1 64 Bit de_DE



 Description   

It took me one hour to find out that my EAR cannot be deployed due to "backwards compatibility" of GlassFish. This is not very smart. I understand that there might be people using proprietary stuff like this, but as GF's major target is serving as the RI of Java EE, it should be configured the reverse way: If people need proprietary stuff to run their EARs, THEY should ENABLE it. But the default should be that any proprietary stuff is OFF to prevent people not needing it from getting stuck with deployment of their Java EE complaint EAR.



 Comments   
Comment by Hong Zhang [ 11/Jul/11 ]

assign to ejb team to take a look

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-17120] Cannot use instance name for the cluster of das's Created: 28/Jul/11  Updated: 02/Dec/11

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

Type: New Feature 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   

All instances in a cluster of das's are named "server". Need to use unique names.






[GLASSFISH-18569] Superfluous SFSB being created in Glassfish, thus leaking memory Created: 28/Mar/12  Updated: 28/Mar/12

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

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

Windows 7



 Description   

It seems that injecting a SFSB into a JSF managed bean causes TWO instances of the SFSB to be created. If I hit the page with 100 clients, then 200 SFSBs are created rather than just 100. Details at http://stackoverflow.com/questions/9894243/superfluous-sfsb-being-created-in-glassfish-thus-leaking-memory






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

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b69
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-18566] EJBTimerService should expose an interface for other components Created: 27/Mar/12  Updated: 27/Mar/12

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

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   

Right now ejb-timer-service-app accesses it directly. Need to check all other use cases.






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

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b25
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: 11/Jul/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b44_ms3
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-18885] Created timer sometimes won't pass to scheduled state (with jdk 1.7.0_04) Created: 11/Jul/12  Updated: 20/Jul/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_b23
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-19128] BaseContainer.injectEjbInstance Created: 05/Oct/12  Updated: 15/Oct/12

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

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

cluster


Attachments: Text File server.log     XML File sun-ejb-jar.xml    

 Description   

Sometime, at deployment time (HA cluster) NullPointerException appear.

[#|2012-10-05T14:02:58.392+0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=160;_ThreadName=Thread-2;|java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1696)
at com.sun.ejb.containers.MessageBeanContainer.createMessageDrivenEJB(MessageBeanContainer.java:706)
at com.sun.ejb.containers.MessageBeanContainer.access$100(MessageBeanContainer.java:101)
at com.sun.ejb.containers.MessageBeanContainer$MessageBeanContextFactory.create(MessageBeanContainer.java:483)
at com.sun.ejb.containers.util.pool.NonBlockingPool.preload(NonBlockingPool.java:338)
at com.sun.ejb.containers.util.pool.NonBlockingPool.doResize(NonBlockingPool.java:586)
at com.sun.ejb.containers.util.pool.NonBlockingPool$IdleBeanWork.run(NonBlockingPool.java:684)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)



 Comments   
Comment by marina vatkina [ 08/Oct/12 ]

Need to see why an MDB instance is created before the container is fully initialized

Comment by rzhevskiy [ 11/Oct/12 ]

I can give you ssh access to our cluster servers

Comment by marina vatkina [ 11/Oct/12 ]

What are the pool settings for the MDB?

Comment by marina vatkina [ 11/Oct/12 ]

Can you attach the server.log with the NPE? Even if the pool-idle-timeout-in-seconds is set to 1, the pool resize should kick in after 16+ minutes...

Comment by rzhevskiy [ 12/Oct/12 ]

attached sun-ejb-jar.xml in mdb module

Comment by rzhevskiy [ 12/Oct/12 ]

log file

Comment by marina vatkina [ 12/Oct/12 ]

I think I know what is going on (I'm looking at where the actual bug is and how to see more details): your application fails to start, but the pool wasn't closed, and resizing is still going on every 10 seconds. See these messages in the server.log

[#|2012-10-12T11:25:55.701+0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2012-10-12T11:25:55.730+0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|Exception while shutting down application container|#]

[#|2012-10-12T11:25:55.742+0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|Exception while shutting down application container : java.lang.NullPointerException|#]

Comment by marina vatkina [ 15/Oct/12 ]

Can you try applying the patch attached to http://java.net/jira/browse/GLASSFISH-18599 to your GF install (restart GF after the change)? It will report the actual error at deployment (which might give us a hint on the exact scenario that leads to the situation you are seeing)





[GLASSFISH-18847] Standalone client not usable in RCP applications Created: 25/Jun/12  Updated: 25/Jun/12

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

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

OSX 10.6.8 as client, Debian 6.0 with JDK7_u4 as server



 Description   

If I want to create a standalone client which uses a RCP platform such as Netbeans or Eclipse RCP because the classloader is not respected. For a detailed description and also the solution please look into the comments of netbeans bug http://netbeans.org/bugzilla/show_bug.cgi?id=151368

Basically I checked out the source code of 3.1.2 and changed in EJBUtils.java:

1.) From "return _generate(loader, protectionDomainBase.getProtectionDomain(),.."
To "return _generate(protectionDomainBase.getClassLoader(),protectionDomainBase.getProtectionDomain(),.."

  • Used the package tool to create the client package and copied all JAR files from the client package including referenced files into my RCP application. Replaced the ejb-container.jar with the changed one

The question is also howto use such a client with the upcoming modularization environment in JDK 8 ?






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

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b51
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-19059] Deprecate use of TimerWelcomeServlet Created: 05/Sep/12  Updated: 09/Oct/12

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

Type: Task 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   

Admin GUI should be able to show the same info as the TimerWelcomeServlet.






[GLASSFISH-19058] Do not expose EJB TimerBean in JNDI Created: 05/Sep/12  Updated: 05/Sep/12

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

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   

To avoid security concerns, do not bind EJB TimerBean in the JNDI (PersistentEJBTimerService currently looks it up).






[GLASSFISH-16780] cluster wide EJB 3.1 Singleton support Created: 01/Jun/11  Updated: 13/Jun/11

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

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


 Description   

Provide cluster wide EJB 3.1 Singleton support.

GlassFish 3.1 release considered this feature. Refer to http://wikis.sun.com/display/GlassFish/GlassFishv3.1EJB

Also see forum thread: http://forums.java.net/node/807417



 Comments   
Comment by shreedhar_ganapathy [ 08/Jun/11 ]

Is this a request for clusterwide EJB Singleton or a generic Singleton Service. If the latter, any application object can be a singleton using a generic service that is cluster aware through GMS - a feature we have been thinking about in Shoal.
Would help to clarify what is being sought here.

Comment by jeff_trent [ 13/Jun/11 ]

The state-management JSR (being proposed now) will provide this feature. There already exists implementations including Coherence, and eventually we would like to have a Shoal provider built as well.





[GLASSFISH-16372] Not able to make toString() a final method in EJB with no-interface view Created: 17/Apr/11  Updated: 01/Apr/13

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo 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

 Description   

EJB 3.1 spec says the following in section #4.9.8:
/All public methods of the bean class and any superclasses are exposed as business methods
through the no-interface view.

All methods of the bean class and any superclasses must not be declared final./

Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean. This can't be true, because Object class has quite a few final methods in it. So, I am assuming that all methods of java.lang.Object are automatically excluded from being part of no-interface view of the EJB. But, then I am surprised to see an exception while trying to deploy the following EJB:

@Stateless
@LocalBean
public class FooBean {

public String test(String s)

{return s.toUpperCase();}

@Override public final String toString()

{return "FooBean";}

}

I got following exception:

Caused by: 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.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:460)
... 27 more
Caused by: java.lang.VerifyError: class org.glassfish.fighterfish.test.app11.ejb._EJB31_GeneratedFooBeanIntf__Bean_ overrides final method toString.()Ljava/lang/String;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
... 32 more

I think GlassFish is incorrectly making toString() a part of no-interface view of this bean.



 Comments   
Comment by marina vatkina [ 18/May/11 ]

We do not know if toString() will be called by the client. If it will, it should be a proxy call

Comment by Cheng Fang [ 19/Oct/11 ]

This issue was fixed as part of 17235 (Dependency Injection doesn't work for overloaded methods accepting generic-type parameter)

Comment by Mark Struberg [ 27/Mar/13 ]

Folks, I humbly recommend to reopen this issue.

final methods cannot get proxied, thus this method will always just hit the proxy instance instead of the proxied EJB instances. I think users will just not be aware what happens.

> Nowhere do I find that methods of "java.lang.Object" are excluded from being part of no-interface view of the bean.

That's true and should get fixed. I recommend to explicitly define the expected behaviour for Object.class methods and exclude them from the standard 'business methods' definition. Maybe this is already even in the spec implicitly? Not sure...

  • toString() -> should get proxied
  • equals, hashCode -> should not get proxied
  • clone -> should not get proxied
    etc
Comment by marina vatkina [ 29/Mar/13 ]

reopening...





[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-19947] Some EJB devtests do not follow Interceptors spec for LC method signatures Created: 19/Mar/13  Updated: 19/Mar/13

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

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   

The Interceptors 1.2 (EE 7) has relaxed the LC method signature rules as follows:

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

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

Note: A lifecycle callback interceptor method must not throw application exceptions, but it may be declared to throw checked exceptions including the java.lang.Exception if the same interceptor method interposes on business or timeout methods in addition to lifecycle events. If a lifecycle callback interceptor method returns a value, it is ignored by the container.

Lifecycle callback interceptor methods defined on a target class have the following signature:

void <METHOD>()






[GLASSFISH-19948] Verify LC interceptor method signatures Created: 19/Mar/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b79
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-19585] No explicit tests for thread safety of singleton session context Created: 25/Jan/13  Updated: 25/Jan/13

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

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   

Need to add tests that verify thread safety of all SessionContext methods when invoked from a singleton with all supported concurrency types.






[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-19654] Unable to specify a DataSource in an embedded EJB container Created: 08/Feb/13  Updated: 11/Feb/13

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

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

Tags: datasource, ejb-container, test, testing

 Description   

There is no way to programmatically specify the datasource for an EJB container. If a module is written to make use of a JTA datasource (by declaring the following in the module's persistence.xml):

<jta-data-source>jdbc/myDS</jta-data-source>

Then it seems impossible to load this module into an embedded EJB container, because the container cannot be configured to set up a datasource, and so the module cannot find one and deployment fails.

Being able to specify datasource details in an embedded EJB container is critical for testing, where we want to use a different datasource but be sure we are testing the same artifact/jar/war file that will eventually be released.

Other embedded EJB containers use properties to achieve this:

However, the only relevant property for glassfish is
org.glassfish.ejb.embedded.glassfish.configuration.file
which could in theory be used to specify a domain.xml file with a pre-configured test datasource. Unfortunately, this property is ignored unless the following property is set
org.glassfish.ejb.embedded.glassfish.installation.root
and to set this second property requires an existing glassfish installtion - thus ruining the project portability I was trying to achieve by using embedded glassfish in the first place.

See here for the forum post I made which describes other awkward and limited workarounds:
http://stackoverflow.com/questions/14748280/how-to-define-a-test-datasource-for-an-embedded-ejb-container



 Comments   
Comment by marina vatkina [ 08/Feb/13 ]

Embeddable EJB container is designed to work either with pre-installed GlassFish, where any resource can be added using CLI or UI, or by specifying the config file with the pre-defined resources.

Changing to RFE

Comment by skwirking [ 11/Feb/13 ]

I agree that the feature to configure a datasource via EJB Container properties should be a feature request.

However, specifying the config file (domain.xml) only works if the installation root is also specified. If the installation root is not specified, the config file option is ignored.

Thus, it appears to be impossible to set up a datasource inside an EJB Container without having an existing installation of GlassFish - and for this reason I respectfully request that the issue still be marked as a 'bug'.





[GLASSFISH-20070] EjbSessionDescriptor.isPassivationCapable should be false by default Created: 27/Mar/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b81
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-20731] Application deployed on standalone instance does not initialize database Created: 29/Jul/13  Updated: 03/Aug/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2_b08, 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-20446] transaction/ee/dblogs/mdb does not test auto-recovery for local jms Created: 30/Apr/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 4.0_b86_RC2
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   

setup-local always uses delegated=true






[GLASSFISH-20434] TM constructor should either fail or recover from ORBPackage.InvalidName: TransactionCurrent not found Created: 29/Apr/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: 4.0_b86_RC2
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   

Seen the following error reported but not thrown (which causes NPE on the following call because current is not set) during tx clustered devtest on hudson:

[2013-04-25T07:26:40.591-0700] [glassfish 4.0] [SEVERE] [jts.unexpected_error_in_create_transaction_manager] [javax.enterprise.system.core.transaction.com.sun.jts.jta] [tid: _ThreadID=105 _ThreadName=Recovery Helper Thread] [timeMillis: 1366900000591] [levelValue: 1000] [[
JTS5043: Unexpected error occurred while creating transaction manager instance
org.omg.CORBA.ORBPackage.InvalidName: TransactionCurrent not found
at com.sun.corba.ee.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1262)
at com.sun.jts.jta.TransactionManagerImpl.<init>(TransactionManagerImpl.java:189)
at com.sun.jts.jta.TransactionManagerImpl.getTransactionManagerImpl(TransactionManagerImpl.java:177)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.setTransactionManager(JavaEETransactionManagerJTSDelegate.java:457)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.recover(JavaEETransactionManagerJTSDelegate.java:418)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.recover(JavaEETransactionManagerSimplified.java:297)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverXAResources(ResourceRecoveryManagerImpl.java:256)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverXAResources(ResourceRecoveryManagerImpl.java:337)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.postConstruct(ResourceRecoveryManagerImpl.java:108)






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

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b89_RC5
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-20676] com.sun.jts.jtsxa.XID needs to be serializable Created: 02/Jul/13  Updated: 02/Jul/13

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

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


 Description   

com.sun.jts.jtsxa.XID implements javax.transaction.xa.Xid which doesn't implement any other interfaces, nor extend anything that can be traced back to java.io.Serializable.

So at first there doesn't appear to be an absolute requirement for the Xid implementation to be serializable.

However, the GlassFish XID implementation should be serializable as its a field in the OTSResourceImpl class, which does need to be serializable through a chain of interfaces/extensions:

com.sun.jts.jtsxa.OTSResourceImpl implements OTSResource
com.sun.jts.jtsxa.OTSResource implements (amongst other things) org.omg.CORBA.portable.IDLEntity
org.omg.CORBA.portable.IDLEntity extends Serializable

Hence if OTSResourceImpl is serialized that will fail because XID is not serializable.

This appears to have been highlighted in past findbugs reports, for example against GF 2.x: http://www.cs.umd.edu/~pugh/glassfish/glassfish.html

Class com.sun.jts.jtsxa.OTSResourceImpl defines non-transient non-serializable instance field tranState
Bug type SE_BAD_FIELD (click for details)
In class com.sun.jts.jtsxa.OTSResourceImpl
Field com.sun.jts.jtsxa.OTSResourceImpl.tranState
In OTSResourceImpl.java

Class com.sun.jts.jtsxa.OTSResourceImpl defines non-transient non-serializable instance field xaRes
Bug type SE_BAD_FIELD (click for details)
In class com.sun.jts.jtsxa.OTSResourceImpl
Field com.sun.jts.jtsxa.OTSResourceImpl.xaRes
In OTSResourceImpl.java

Class com.sun.jts.jtsxa.OTSResourceImpl defines non-transient non-serializable instance field xid
Bug type SE_BAD_FIELD (click for details)
In class com.sun.jts.jtsxa.OTSResourceImpl
Field com.sun.jts.jtsxa.OTSResourceImpl.xid
In OTSResourceImpl.java

This has been seen with a combination of Glassfish + Coherence JCA resource adapter using UserTransaction:

[#|2013-06-27T14:57:50.097+0100|WARNING|glassfish3.1.2|javax.enterprise.system.core.transaction.com.sun.jts.jtsxa|_ThreadID=26;_ThreadName=Thread-2;|JTS5067: Unexpected error occurred in commit

(Wrapped) java.io.NotSerializableException: com.sun.jts.jtsxa.XID

at com.tangosol.util.ExternalizableHelper.toBinary(ExternalizableHelper.java:216)

at com.tangosol.net.partition.DefaultKeyPartitioningStrategy.calculateBasePartition(DefaultKeyPartitioningStrategy.java:90)

at com.tangosol.net.partition.DefaultKeyPartitioningStrategy.calculateKeyPartition(DefaultKeyPartitioningStrategy.java:72)

at com.tangosol.net.partition.DefaultKeyPartitioningStrategy.getKeyPartition(DefaultKeyPartitioningStrategy.java:42)

at com.tangosol.coherence.transaction.internal.storage.StorageKeyPartitioningStrategy.getKeyPartition(StorageKeyPartitioningStrategy.java:33)

at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.PartitionedService$ConverterKeyToBinary.convert(PartitionedService.CDB:88)

at com.tangosol.util.ConverterCollections$ConverterMap.remove(ConverterCollections.java:1690)

at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ViewMap.remove(PartitionedCache.CDB:1)

at com.tangosol.coherence.component.util.SafeNamedCache.remove(SafeNamedCache.CDB:1)

at com.tangosol.coherence.transaction.internal.xa.XAResourceImpl.remove(XAResourceImpl.java:626)

at com.tangosol.coherence.transaction.internal.xa.XAResourceImpl.commit(XAResourceImpl.java:162)

at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:174)

at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1565)

at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2956)

at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:322)

at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)

at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:633)

at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:332)

at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)

at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:861)

at com.sun.enterprise.transaction.UserTransactionImpl.commit(UserTransactionImpl.java:208)

at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1011)

at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:755)

at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:724)

at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:475)

at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:270)

at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94)

at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)

at $Proxy214.generateToken(Unknown Source)



 Comments   
Comment by tecknobabble [ 02/Jul/13 ]

Can provide a simple testcase to generate the above error, however don't see any option where I can add an attachment.

Requires Oracle Coherence for Java 3.7.1, available from: http://www.oracle.com/technetwork/middleware/coherence/downloads/index.html

A simple servlet which imports:

import com.tangosol.coherence.transaction.Connection;
import com.tangosol.coherence.transaction.ConnectionFactory;
import com.tangosol.coherence.transaction.OptimisticNamedCache;

which has a service method which calls:

response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
UserTransaction tx = null;

InitialContext ctx = new InitialContext();
tx = (UserTransaction) ctx.lookup("java:comp/UserTransaction");
tx.begin();

ConnectionFactory cf = (ConnectionFactory) ctx.lookup("java:comp/env/eis/CoherenceTxCF");
Connection con = cf.createConnection("TransactionalCache");
OptimisticNamedCache cache = con.getNamedCache("tx-cache");
out.println("PUT: " + cache.put(1, "test") + "<br />");
out.println("GET: " + cache.get(1) + "<br /");

tx.commit();

will generate the "java.io.NotSerializableException: com.sun.jts.jtsxa.XID" error.

The coherence.jar file needs to be placed in the domain's lib directory.
The coherence-transaction.rar needs to be deployed and a connector resource created with the jndi name eis/CoherenceTxCF.

web.xml needs a resource ref for the coherence connection factory:

<resource-ref>
<res-ref-name>eis/CoherenceTxCF</res-ref-name>
<res-type>com.tangosol.coherence.transaction.ConnectionFactory</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

The glassfish-web.xml requires a resource ref adding:

<resource-ref>
<res-ref-name>eis/CoherenceTxCF</res-ref-name>
<jndi-name>eis/CoherenceTxCF</jndi-name>
</resource-ref>





[GLASSFISH-20803] Transaction is not committed when launching disable sub-command Created: 09/Sep/13  Updated: 09/Sep/13

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

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

Windows


Tags: licbug

 Description   

Symptom:

With EJB's CMT(Container-Managed Transactions) in Java EE 7 RI, the
following exception is thrown if "asadmin disable" command is launched
when business method is till in execution.

javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

However, rollback never be executed.

It seems a bug exists in the code at com.sun.ejb.containers.BaseContainer.java#postInvoke(EjbInvocation, boolean).

REPRODUCE:

The attached test case is for OracleDB.

1) Run the attached createTable_Oracle.sql and create testtable in DB
2) Run start-domain.bat and start the domain(default domain1)
3) Run the attached create-jdbc.bat and create JDBC resources
4) Run the attached deploy.bat and deploy applications
5) Click URL.url to open a browser and show adder.html
6) Input some value in the text box and click "Send query" button

This step does:

  • Accesses to EJB from servlet
  • Update testtable (update the value of balance with id:001 )
  • Sleep 10 seconds

7) When the above step 6) is running, invoke disable.bat to stop the application

Here, javax.ejb.EJBException is thrown and the message
500 Internal Server Error
shows up.

Then, confirm the contents of testtabel in DB.
The value should be the previous value (the value before update)

8) Run the attached stop-domain.bat to stop the domain

Then, confirm the contents of testtabel in DB.
The value is updated.(value after update)

At step 7), if rollback is executed and the value in DB is the previous value,
this is what expected behavior.
However, transaction is committed at step 8) which should have happened at step 7). As a result, the value is updated incorrectly.






[GLASSFISH-19282] Warn if AroundInvoke or AroundTimeout method signatures are not correct Created: 02/Nov/12  Updated: 02/Nov/12

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

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   

Return value is not checked for sure. The rest needs to be checked also.






[GLASSFISH-19281] Warn if SFSB lifecycle callbacks use container-transaction that is not RequiresNew or NotSupported Created: 02/Nov/12  Updated: 02/Nov/12

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

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   

Only RequiresNew and NotSupported are valid values






[GLASSFISH-19143] XAResource.setTransactionTimeout(encompassingJTATransactionTImeoutValue) is not being called on resources enlisted in a Glassfish transaction. Created: 10/Oct/12  Updated: 22/Mar/13

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

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

Linux adc2100774 2.6.18-308.0.0.0.1.el5xen #1 SMP Sat Feb 25 16:26:29 EST 2012 x86_64 x86_64 x86_64 GNU/Linux



 Description   

XAResource.setTransactionTimeout(encompassingJTATransactionTImeoutValue) is not being called on resources enlisted in a Glassfish transaction.

Javadoc for the XAResource.setTransactionTimeout: "Once set, this timeout value is effective until setTransactionTimeout is invoked again with a different value." Which means that if an XAResource has a predefined timeout less than the timeout set on the UserTransaction, the transaction manager has no control (and should not have any according to the text above) over the XAResource behavior.

The javadoc does not state this as a requirement. Note that the javadoc does say "Sets the current transaction timeout value for this |XAResource| instance. " suggesting, as is the case, that each XAResource in question is an instance related to a transaction.

However, in all other application servers, XAResource.setTransactionTimeout(encompassingJTATransactionTImeoutValue) is the default behavior (in WebLogic there is an override option but even that is not suggested best practice) and it makes logical sense as the XAResource is always a part of a JTA transaction and thus the timeout values are directly related.

Glassfish should make Glassfish xa-resource-timeout dynamic in future releases.



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

The current support is static using transaction-service.property.xaresource-txn-timeout to set the timeout for all XA resources.





GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19410] Ejb container configuration to conform with configuration modularity Created: 06/Dec/12  Updated: 06/Dec/12

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

Type: Sub-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


 Description   

Different modules requires to conform with configuration modularity. This is a parent task for all the issue being filed for this project. More details at the internal wiki page: http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Config+Modularity+One+Pager This ticket is to track this change for ejb container.






GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19409] Transaction service configuration to conform with configuration modularity Created: 06/Dec/12  Updated: 21/Sep/15

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

Type: Sub-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


 Description   

Different modules requires to conform with configuration modularity. This is a parent task for all the issue being filed for this project. More details at the internal wiki page: http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Config+Modularity+One+Pager This ticket is to track this change for transaction service.






[GLASSFISH-19398] Add sub-command "list-transactions" to GF V3.x or later Created: 04/Dec/12  Updated: 06/Dec/12

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

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

Attachments: Zip Archive prototype.zip     Microsoft Word SD_Draft.docx    

 Description   

there is some requirements for listing the active transactions on server instance as the transaction id is the operand of some subcomannd.
eg. the subcommand "rollback-transaction" which described in the following page.
http://docs.oracle.com/cd/E26576_01/doc.312/e24938/rollback-transaction.htm#rollback-transaction-1

for the ease of using the command above. we should supply subcommand("list-transactions" for assumed name) to list the active transaction info which contains transaction ID.



 Comments   
Comment by Wu Jie [ 04/Dec/12 ]

we can add the "list-transactions" subcommand as following.

===================================================================
asadmin list-transactions [--help] [--detail[=true|=false]] target
OPTIONS
--help , -?
Displays the help text for the subcommand.

--detail
this option specifies whether output the transaction
in detail. outputs in detail if this option is set to
true(default is false).

OPERANDS
target
This option specifies the target on which you are
listing the transactions. Valid values are:

instance_name
lists the active transactions on a particular
server instance.

EXAMPLES
Example 1 Using list-transactions
% asadmin list-transactions server
List of the transactions:
No. ID Status
1 0000000000000008_00 Active
2 0700000021A0FD38666E73742D6C696E7A672C7365727665 Active
Command list-transactions executed successfully.

Example 2 Using list-transactions
% asadmin list-transactions --detail=true instance1
List of the transactions:
----------------------------------------------------------------------------
[No 1]
ID :0000000000000008_00
Status :Active
ElapsedTime(ms):48204
ComponentName :org.lns.samples.servlet.
ResourceNames :jdbc.ServletJdbcDelete
----------------------------------------------------------------------------
[No 2]
ID :0700000021A0FD38666E73742D6C696E7A672C7365727665
Status :Active
ElapsedTime(ms):18891
ComponentName :org.lns.samples.servlet.ServletJdbcDelete
ResourceNames :jdbc/__TimerPool
----------------------------------------------------------------------------
Command list-transactions executed successfully.
===================================================================

Comment by Wu Jie [ 04/Dec/12 ]

attached draft of structure design.

Comment by Wu Jie [ 04/Dec/12 ]

attached the prototype which did the following.
1.the definition of subcommand "list-transaction" refer to ListTransactions.java which should be in
transaction/jta/src/main/java/org/glassfish/jta/admin/cli

2.the usage of subcommand "list-transaction" refer to list-transactions.1 which should be in
transaction/jta/src/main/resources/org/glassfish/jta/admin/cli

3.the definition of message refer to LocalStrings.properties which should be in
transaction/jta/src/main/resources/org/glassfish/jta/admin/cli

4.supply the REST API for "list-transaction" refer to CommandResourceMetaData.java which should be in
admin/rest/src/main/java/org/glassfish/admin/rest/generator

Comment by marina vatkina [ 04/Dec/12 ]

This will not work without tx monitoring being on. Why do you need to have another solution to what is already available (and described in the link above)?

Comment by Wu Jie [ 04/Dec/12 ]

yeah,I see.
the already available solution "get --monitor" seems to not work without tx monitoring being HIGH.
when tx monitoring is set to be LOW, there is no transaction info by "get --monitor" or in the admin gui.

Is above the original design?

Comment by marina vatkina [ 04/Dec/12 ]

There should be no difference between HIGH and LOW. If the latter doesn't work, file a jts bug. But the list-xxx command as a short-cut for monitoring (with duplication of the processing code), seems misleading.

Comment by Wu Jie [ 05/Dec/12 ]

> There should be no difference between HIGH and LOW. If the latter doesn't work, file a jts bug.

I filed a issue about that.
http://java.net/jira/browse/GLASSFISH-19404





[GLASSFISH-12161] Transaction manager collects active "transactions" Created: 07/Jun/10  Updated: 23/Oct/15

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: v2.1.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: hegalor 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: All


Attachments: Java Source File MyTimerBean.java     Zip Archive testcase.zip    
Issuezilla Id: 12,161

 Description   

J2EETransactionManagerImpl does not free monitored transaction, if nobody calls
commit. This is the cause, that NoTransaction transaction are collected, if
transaction monitoring is enabled.

http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/distributedtx/J2EETransactionManagerImpl.java?r=HEAD
— SNIP —
protected Vector activeTransactions; // <--- Contains monitored active Txs
// ...
public void begin(int timeout)
{
// ...
// START IASRI 4662745
if (monitoringEnabled)

{ Transaction tran = tm.getTransaction(); activeTransactions.addElement(tran); m_transInFlight++; }

// END IASRI 4662745
// ...
}
// ...
protected void monitorTxCompleted(Object tran, boolean committed){
if(tran==null || !activeTransactions.remove(tran))

{ // WARN !!! return; }

// ...
}
// ...
public void commit() throws RollbackException,
// ...
{
// ...
Object obj = null;
if(monitoringEnabled)

{ obj = tm.getTransaction(); }

// ...
if (monitoringEnabled)

{ monitorTxCompleted(obj, true); }

// ...
}
// ...
public void rollback() throws IllegalStateException, SecurityException,
SystemException {
// ...

if (monitoringEnabled)

{ monitorTxCompleted(obj, false); }

// END IASRI 4662745

}
— SNAP —

So as you can see, on rollback/commit the transaction will be removed from
Vector, but without never!



 Comments   
Comment by hegalor [ 08/Jun/10 ]

Created an attachment (id=4417)
Simple maven project for creating an ear for simple reproduce

Comment by hegalor [ 08/Jun/10 ]

I've create a sample to reproduce the problem.

I've a timeout method, that has the annotation
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED).
This method create a new timer.

If you configure Configuration -> Monitoring -> Transaction Service "LOW" or
"HIGH" gf collects the transactions.

Perhaps instead of a vector of Transaction object it should be used a weak
reference list.

Comment by hegalor [ 14/Jun/10 ]

Created an attachment (id=4428)
Simpler MyTimerBean

Comment by hegalor [ 14/Jun/10 ]

I've the problem with the simpler case, too:
A timeout function marked with
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) and doing nothing
else create a log entry.

Comment by hegalor [ 14/Jun/10 ]

I'Ve located the problem:
According to the source code:
http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/distributedtx/J2EETransaction.java?r=1.11.6.4

If an commit is perfomed, the task will be cancled:
— SNIP —
   public void commit() throws RollbackException,
               HeuristicMixedException, HeuristicRollbackException,
               SecurityException, IllegalStateException, SystemException
   {
        // START local transaction timeout
        // If this transaction is set for timeout, cancel it as it is in the
commit state
        if (isTimerTask)
                cancel();
— SNAP —

According to TimerThread:
— SNIP —
/**

  • Removes all cancelled tasks from this timer's task queue. <i>Calling
  • this method has no effect on the behavior of the timer</i>, but
  • eliminates the references to the cancelled tasks from the queue.
  • If there are no external references to these tasks, they become
  • eligible for garbage collection.
    *
  • <p>Most programs will have no need to call this method.
  • It is designed for use by the rare application that cancels a large
  • number of tasks. Calling this method trades time for space: the
  • runtime of the method may be proportional to n + c log n, where n
  • is the number of tasks in the queue and c is the number of cancelled
  • tasks.
    *
  • <p>Note that it is permissible to call this method from within a
  • a task scheduled on this timer.
    *
  • @return the number of tasks removed from the queue.
  • @since 1.5
    */
    public int purge() {
      • SNAP —

I think the problem is the state CANCELED. All my thousend of timertask in the
TimerQueue saved in TimerThread are in state canceled.

Comment by hegalor [ 14/Jun/10 ]

Sorry that was for issue 12177

Comment by marina vatkina [ 04/Oct/10 ]

They should be active transactions if they were not committed/rolledback. Will
look to provide a flag in transaction config that will allow to remove old
transactions from the monitoring table

Comment by Enfernuz [ 23/Oct/15 ]

The "bug" (don't know if it's actually a bug though) still presents at least in 3.1.2.2 b5 and I don't see any related code lines in the new builds.
Is there a workaround or a solution available? The option for removing "old" active transactions would help.





[GLASSFISH-20749] Glassfish expunges timer even if callback method keeps its contract Created: 07/Aug/13  Updated: 13/Sep/13

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

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

Tags: portability, timer

 Description   

Glassfish expunges the timer of a callback method if during the execution of the callback method a called services throws an application exception. The timer will be expunged even if the callback method handles the exception and finishes properly.

On the mailing list Marina Vatikna commented on my post:

GF retries once (you can change the setting to retry more times), but after all retries failed, the timer is expunged.

In my opinion the timer must not be expunged. The EJB 3.1 and 3.2 specification require only that a callback method does not throw an exception. In the scenario described above the callback method fullfils this requirement.

From my point of view this behaviour makes it impossible to write a reliable service because as the programmer of the callback method the only thing I can do is to read and to keep the requirements of the specification.

Furthermore the only possible solution to recover from this scenario is to restart the server or to redeploy the application.

I developed a small sample application to demonstrate this behaviour of Glassfish. You can find it at https://bitbucket.org/obfischer/glassfish-timerproblem

I also ran this example application with JBoss and with Apache Geronimo. Both do not expunge the timer.

Please ensure that Glassfish does not expunge the timer. This will help us to write reliable and portable applications based on Glassfish.



 Comments   
Comment by Marek Handl [ 12/Sep/13 ]

Your sample application works with RuntimeException, which is a system exception, i.e. not an application exception.

System exception thrown from a business method methodToBeCalledByServiceA() marks the transaction for rollback automatically. The fact that you catch the exception in methodOfA() does not affect this, the transaction is still marked for rollback.

Because the transaction is rollbacked, the timer is considered unsuccessful. The container will therefore retry the timeout.

As far as I know, up to here, everything is according to the EJB specification.

The fact that the container expunges the timer might be Glassfish specific. This behavior can be disabled via reschedule-failed-timer property.

Comment by obfischer [ 13/Sep/13 ]

This issue is not on the TX handling of Glassfish for callback methods. The problem is that only Glassfish deletes the timer even if the callback method itself does not throw any exception.

See EJB_SPEC-111 for my request for the EJB specification on this issue.

Comment by Marek Handl [ 13/Sep/13 ]

Well timers are associated with transactions, therefore it is about TX handling. The reason why the timer is expunged is that the TX is rolled back. The fact that the TX is rolled back because of an exception is a separate thing.

The EJB specification says:
"If container-managed transaction demarcation is used and the REQUIRED or REQUIRES_NEW transaction attribute is specified or defaulted (Required or RequiresNew if the deployment descriptor is used), the container must begin a new transaction prior to invoking the timeout callback method. If the transaction fails or is rolled back, the container must retry the timeout at least once."

Glassfish by default does what the specification says, transaction is started, your code is executed, transaction is rolled back and therefore Glassfish retries the timeout once again after 5 seconds.

The fact that the timer gets expunged is another story. I don't think there is anything about expunging in the specification. That's why I said it might be Glassfish specific. If the other servers do not expunge timers by default, good for them. Unfortunately, Glassfish by default does. But this behavior can be disabled via the property I mentioned.

Comment by obfischer [ 13/Sep/13 ]

Correct, but I think Glassfish should not expunges the timer at all and independent of the TX.





[GLASSFISH-17385] asadmin stop-domain does not end cleanly for MDB's Created: 06/Oct/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_b12
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-8297] Circular or self injection of stateful EJB causes stack overflow Created: 12/May/09  Updated: 15/Feb/13

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

Type: Bug Priority: Minor
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


Attachments: Text File web3.war    
Issuezilla Id: 8,297

 Description   

Stack overflow occurs when injecting a stateful ejb ref with @EJB to its own
bean class, or another stateful bean class.

This does not seem to occur to stateless.

Error from server.log:
----------------------

[#|2009-05-12T14:40:40.524-0400|WARNING|glassfish|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=16;_ThreadName=Thread-1;|create
object exception
com.sun.enterprise.container.common.spi.util.InjectionException: Exception
attempting to inject Remote ejb-ref name=test.BarBean/bar,Remote 3.x business
interface=test.BarIFresolved to intra-app EJB with
ejb-name=BarBean,ejb-link=BarBean,mappedName=test.BarIF,refType=Session into
class test.BarBean
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:391)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:210)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:132)
at
com.sun.ejb.containers.StatefulSessionContainer.createBeanInstance(StatefulSessionContainer.java:558)
at
com.sun.ejb.containers.StatefulSessionContainer.createRemoteBusinessObjectImpl(StatefulSessionContainer.java:428)
at
com.sun.ejb.containers.EJBHomeImpl.createRemoteBusinessObjectImpl(EJBHomeImpl.java:117)
at
com.sun.ejb.containers.EJBHomeInvocationHandler.invoke(EJBHomeInvocationHandler.java:194)
at $Proxy111.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:234)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:153)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:84)
at $Proxy113.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:419)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:70)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:427)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:106)
at
com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:534)
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:461)
at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:139)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:418)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:291)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:210)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:132)
at
com.sun.ejb.containers.StatefulSessionContainer.createBeanInstance(StatefulSessionContainer.java:558)
at
com.sun.ejb.containers.StatefulSessionContainer.createRemoteBusinessObjectImpl(StatefulSessionContainer.java:428)
at
com.sun.ejb.containers.EJBHomeImpl.createRemoteBusinessObjectImpl(EJBHomeImpl.java:117)
at
com.sun.ejb.containers.EJBHomeInvocationHandler.invoke(EJBHomeInvocationHandler.java:194)
at $Proxy111.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:234)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:153)
at
com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:84)
at $Proxy113.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:419)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:70)

bean classes:
--------------
//@Stateless
@Stateful
@Remote(BarIF.class)
public class BarBean {
@EJB
private FooIF foo;

// @EJB
// private BarIF bar;

public String hello(String name)

{ return "Hello, " + name + " from " + this; }

}

------


//@Stateless
@Stateful
@Remote(FooIF.class)
public class FooBean {
@EJB
private FooIF foo;

@EJB
private BarIF bar;

public String hello(String name) { return "Hello, " + name + " from " + this; }

}

After stack overflow, need to kill the appserver process. stop-domain didn't
stop the process and log files kept growing and rotating.



 Comments   
Comment by Cheng Fang [ 12/May/09 ]

Created an attachment (id=2794)
test WAR file (/web3/Servlet3)

Comment by ksak [ 16/Sep/09 ]

This is actually spec-defined behavior since injection of a stateful session bean is required to have the
side effect of creating a new bean identity, which then results in injection. The same behavior existed in
V2, so ultimately this is an application coding error. It's possible we could add some kind of check to the
container but it might not be easy for the container to identify this case at runtime. Changing to P4.

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-7959] ejb lookup faild when resource adapter with remote interface deployed Created: 22/Apr/09  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v2.1.1
Fix Version/s: 4.0

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

Operating System: Linux
Platform: Linux


Attachments: GZip Archive ejb-lookup-problem-src-bin.tar.gz    
Issuezilla Id: 7,959
Status Whiteboard:

v3_exclude


 Description   

I'm using Sun Java System Application Server 9.1_02 (build b04-fcs)
I also reproduced this problem using GlassFish v3 (build 44)

Scenerio:
I have two Enterprise Applications (EAR) TEST-MODULE (EAR_1) and SMS-ACTIVE (EAR_2)
one Web Application (WAR_1) and one Connector Module (RAR_1)

EAR_1 : TEST-MODULE have one ejb (EJB_1):

@Stateless(mappedName = "ejb/sms/active/module/EJBCActivityTest")
@Remote(

{ActivityProcessableRemote.class}

)
public class EJBCActivityTest implements ActivityProcessableRemote {

public void doInit()

{ Logger.getLogger(this.getClass().getName()).info("doInit"); }

}

EAR_2 : SMS-ACTIVE have one ejb (EJB_2):

@Stateless(mappedName = "ejb/sms/active/SMSMainBean")
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public class SMSMainBean implements SMSBeanRemote
public void onTextMessage(String message) {
InitialContext ctx;
try

{ ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/module/EJBCActivityTest"); ActivityProcessableRemote activity = (ActivityProcessableRemote) lookup; activity.doInit(); } catch (NamingException e) { e.printStackTrace(); }

}

}

WAR_1 : Servlet (SERVLET_1) with <load-on-startup>1</load-on-startup> in
web.xml (this servlet is packaged in SMS-ACTIVE.ear)

ublic final class LifeCycleServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet {

private transient java.util.logging.Logger logger;


@Override
public void init() throws ServletException {
// start first part of code
getLogger().info("--------- part 1");
InitialContext ctx;
try { ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/module/EJBCActivityTest"); ActivityProcessableRemote activity = (ActivityProcessableRemote) lookup; activity.doInit(); }

catch (NamingException e)

{ e.printStackTrace(); }
// end first part of code
// start second part of code
getLogger().info("--------- part 2");
try { ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/SMSMainBean"); SMSBeanRemote activity = (SMSBeanRemote) lookup; activity.onTextMessage("message"); } catch (NamingException e) { e.printStackTrace(); }

// end second part of code

super.init();
}

public java.util.logging.Logger getLogger()

{ return logger == null ? logger = Logger .getLogger(LifeCycleServlet.class.getName()) : logger; }

}

So, in first part of (see servlet code listening) this code servlet call EJB_1
from SERVLET_1 and in second part it call EJB_2 which call EJB_1.

First part of this code always successes.
But in some cases the second part of this code crashed with exception:

javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
(...)
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
(...)

I described the cases when this code crashed here:
Case 1.
Step 1. deploy RAR_1 with ActivityProcessableRemote.class (remote interface of
EJB_1) on glassfish
Step 2. deploy EAR_1
Step 3. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: Exception.

Case 2.
Step 1. deploy EAR_1
Step 2. deploy EAR_2
Step 3. deploy RAR_1 with ActivityProcessableRemote.class (remote interface of
EJB_1) on glassfish
Step 4. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: OK.

Case 3.
Step 1. deploy EAR_1
Step 2. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
(RAR_1 is not on the glassfish)
OUTCOME:
First part of code: OK
Second part of code: OK.

Case 4.
Step 1. deploy RAR_1 without definition of ActivityProcessableRemote interface
Step 2. deploy EAR_1
Step 3. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: OK.

Conclusion:
Problem occurred only when definition of ejb interface are deployed in RAR_1
before EAR_2 is deployed.

Full exception:
[#|2009-04-22T05:54:52.542+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|
javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at pl.smi.sms.active.manager.SMSMainBean.onTextMessage(SMSMainBean.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.rFull exception:
[#|2009-04-22T05:54:52.542+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|
javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
at
javaxeflect.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.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:203)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:77)
at $Proxy23.onTextMessage(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:154)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:687)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:227)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1846)
at
com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:183)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:219)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:192)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at
com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
at
pl.smi.sms.active.manager._SMSBeanRemote_Remote_DynamicStub.onTextMessage(pl/smi/sms/active/manager/_SMSBeanRemote_Remote_DynamicStub.java)
at
pl.smi.sms.active.manager._SMSBeanRemote_Wrapper.onTextMessage(pl/smi/sms/active/manager/_SMSBeanRemote_Wrapper.java)
at pl.smi.sms.active.LifeCycleServlet.init(LifeCycleServlet.java:48)
at javax.servlet.GenericServlet.init(GenericServlet.java:254)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1178)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1007)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4808)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5196)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
at
com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:182)
at
com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:278)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeModuleDeployEventListener(AdminEventMulticaster.java:974)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleModuleDeployEvent(AdminEventMulticaster.java:961)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:464)
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.admin.jmx.remote.server.callers.InvokeCaller.call(InvokeCaller.java:69)
at
com.sun.enterprise.admin.jmx.remote.server.MBeanServerRequestHandler.handle(MBeanServerRequestHandler.java:155)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.processRequest(RemoteJmxConnectorServlet.java:122)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.doPost(RemoteJmxConnectorServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(Sta|#]

[#|2009-04javax.naming.NamingException: ejb ref resolution error for remote
business interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root
exception is java.lang.IllegalArgumentException: object is not an instance of
declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)-22T05:54:52.543+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|ndardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116)
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:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:372)
... 106 more

#]


 Comments   
Comment by rmalinowski [ 22/Apr/09 ]

Created an attachment (id=2641)
source and bin with maven poms

Comment by ksak [ 11/Oct/09 ]

Marked v3_exclude

Comment by marina vatkina [ 08/Sep/10 ]

-> Cheng

Comment by Tom Mueller [ 15/Feb/13 ]

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





[GLASSFISH-15530] Derby was left in broken state after automatic recovery failure on 2-machine cluster and jdbc and jms app Created: 11/Jan/11  Updated: 28/Aug/12

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

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

solaris 10 and linux 5


Tags: 3_1-verified

 Description   

Automatic recovery with jdbc and jms failed with 2-machine cluster.
glassfish-3.1-b36.zip

Automatic Self Recovery with a GF instance crash test
failed on a cluster of 2 machines.

The same test scenario passed on a cluster of 1 machine with the fix of
http://java.net/jira/browse/GLASSFISH-14809

Please see test description in TX_03L at
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/docs/sqe/txn/GF31TXRecoveryTestSpec.html

The simplified test scenario without jms in TX_03R passed both 1- and 2-machine cluster.

I will provide test details next.



 Comments   
Comment by sherryshen [ 11/Jan/11 ]

Test details:
1) To setup test env and cluster, see
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31TXInstruction

2) To setup databases,
do "ant startDerby" and "ant startTxDerby in
appserver-sqe

3) To run test on 1- or 2-machine cluster with the same steps, i.e.
do "ant ee setup build deploy run_test3_mql
appserver-sqe/pe/transaction/recovery/cliapp2

4) Before killing clustered_instance_2:
hudson@jws-v210-4% asadmin list-instances -l
NAME HOST PORT PID CLUSTER STATE
clustered_instance_1 jws-v210-3.us.oracle.com 34848 14777 sqe-cluster running
clustered_instance_2 jws-v210-4.us.oracle.com 44848 3897 sqe-cluster running
clustered_instance_3 jws-v210-3.us.oracle.com 54848 14776 sqe-cluster running
Command list-instances executed successfully.

5) After killing clustered_instance_2 and restarting it:
hudson@jws-v210-4% asadmin list-instances -l
NAME HOST PORT PID CLUSTER STATE
clustered_instance_1 jws-v210-3.us.oracle.com 34848 14777 sqe-cluster running
clustered_instance_2 jws-v210-4.us.oracle.com 44848 4243 sqe-cluster running
clustered_instance_3 jws-v210-3.us.oracle.com 54848 14776 sqe-cluster running
Command list-instances executed successfully.
hudson@jws-v210-4%

6) The server.log files are saved at
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build36/tx/15330/

7) clustered_instance_2 has jms error:

[#|2011-01-11T12:09:05.987-0800|SEVERE|glassfish3.1|
javax.enterprise.system.std.com.sun.enterprise.server.logging|
_ThreadID=92;_ThreadName=Thread-1;|
com.sun.messaging.jms.JMSException: [C4003]: Error occurred on connection creation
[jws-v210-3.us.oracle.com:48686]. - cause: java.net.ConnectException: Connection refused
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.throwConnectionException(ExceptionHandler.java:280)
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.handleConnectException(ExceptionHandler.java:226)

[#|2011-01-11T12:09:08.442-0800|INFO|glassfish3.1|
javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound|
_ThreadID=92;_ThreadName=Thread-1;|Recovery of Inbound Transactions started.|#]

8) clustered_instance_1 has jts error about derby

[#|2011-01-11T12:09:16.204-0800|INFO|glassfish3.1|
avax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound|
_ThreadID=198;_ThreadName=Thread-1;|Recovery of Inbound Transactions started.|#]

[#|2011-01-11T12:10:16.544-0800|WARNING|glassfish3.1|javax.enterprise.system.core.transaction.com.sun.jts.jta|
_ThreadID=189;_ThreadName=Thread-1;|JTS5064: Unexpected exception occurred while delisting the resource
org.apache.derby.client.am.XaException: XAER_RMFAIL : No current connection.
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
at org.apache.derby.client.net.NetXAResource.connectionClosedFailure(Unknown Source)
at org.apache.derby.client.net.NetXAResource.end(Unknown Source)
at com.sun.gjc.spi.XAResourceImpl.end(XAResourceImpl.java:102)
at com.sun.jts.jta.TransactionState.beforeCompletion(TransactionState.java:160)

9) Test results are posed at
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31TXRecovery
See RunID 05 and 05R for client output and html report.

Comment by marina vatkina [ 11/Jan/11 ]

2 problems to look at:

1) a jms setup error:

[#|2011-01-11T12:07:07.786-0800|SEVERE|glassfish3.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=23;_ThreadName=Thread-1;|MQJMSRA_MC4001: constructor:Aborting:JMSException on createConnection=[C4003]: Error occurred on connection creation [jws-v210-3.us.oracle.com:48686]. - cause: java.net.ConnectException: Connection refused|#]

[#|2011-01-11T12:07:07.800-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=182;_ThreadName=Thread-1;|com.sun.messaging.jms.JMSException: [C4003]: Error occurred on connection creation [jws-v210-3.us.oracle.com:48686]. - cause: java.net.ConnectException: Connection refused
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.throwConnectionException(ExceptionHandler.java:280)
at com.sun.messaging.jmq.jmsclient.ExceptionHandler.handleConnectException(ExceptionHandler.java:226)
at com.sun.messaging.jmq.jmsclient.PortMapperClient.readBrokerPorts(PortMapperClient.java:247)
at com.sun.messaging.jmq.jmsclient.PortMapperClient.init(PortMapperClient.java:156)
at com.sun.messaging.jmq.jmsclient.PortMapperClient.<init>(PortMapperClient.java:98)
at com.sun.messaging.jmq.jmsclient.protocol.tcp.TCPConnectionHandler.<init>(TCPConnectionHandler.java:171)
at com.sun.messaging.jmq.jmsclient.protocol.tcp.TCPStreamHandler.openConnection(TCPStreamHandler.java:141)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:785)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnectionNew(ConnectionInitiator.java:260)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:214)
at com.sun.messaging.jmq.jmsclient.ConnectionInitiator.createConnection(ConnectionInitiator.java:164)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.init(ProtocolHandler.java:843)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.<init>(ProtocolHandler.java:1562)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.openConnection(ConnectionImpl.java:2383)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.init(ConnectionImpl.java:1064)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.<init>(ConnectionImpl.java:442)
at com.sun.messaging.jmq.jmsclient.UnifiedConnectionImpl.<init>(UnifiedConnectionImpl.java:66)
at com.sun.messaging.jmq.jmsclient.XAConnectionImpl.<init>(XAConnectionImpl.java:64)
at com.sun.messaging.XAConnectionFactory.createXAConnection(XAConnectionFactory.java:97)
at com.sun.messaging.jms.ra.ManagedConnection.<init>(ManagedConnection.java:196)
at com.sun.messaging.jms.ra.ManagedConnectionFactory.createManagedConnection(ManagedConnectionFactory.java:226)
at com.sun.enterprise.resource.recovery.ConnectorsRecoveryResourceHandler.loadXAResourcesAndItsConnections(ConnectorsRecoveryResourceHandler.java:292)
at com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.getAllRecoverableResources(ResourceRecoveryManagerImpl.java:210)
<...>
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at com.sun.messaging.jmq.jmsclient.PortMapperClient.makeSocketWithTimeout(PortMapperClient.java:274)
at com.sun.messaging.jmq.jmsclient.PortMapperClient.readBrokerPorts(PortMapperClient.java:226)
... 31 more

2) why derby is left in a bad state

Comment by marina vatkina [ 13/Jan/11 ]

The fix for GLASSFISH-15494 resolved the wrong port problem (part 1). Keeping the bug open to figure out why Derby was left in a broken state (part 2), but downgrading it for now.

Comment by sherryshen [ 26/Jan/11 ]

Thank Knut for helping us to investigating the issue 2).

-------- Original Message --------
Subject: Re: Recover from (identify cause of) XAER_RMFAIL : No current connection?
Date: Wed, 26 Jan 2011 14:46:35 +0100
From: Knut Anders Hatlen <knut.hatlen>
To: Sherry Hill <sherry.hill>
CC: marina.vatkina, javadb-eng

Sherry Hill <sherry.hill> writes:

> On 1/18/2011 5:35 PM, Marina Vatkina wrote:.
>>> Is it always
>>> reproducible with the test, or does it only happen intermittently?
>>
>> Sherry had a setup that failed in JMS and caused this Derby error as
>> a side effect.
> I can reproduce the problem on will with v3.1 build 36 promoted.
> http://java.net/jira/browse/GLASSFISH-15530
> When this suite failed, the other tests also failed if they are executed
> after this suite since derby is not working any more.
> For the further tests, I re-install glassfish and derby.
> I did not know if there is a simple way to clean up this error.

Hi Sherry,

I was able to reproduce this (partially) using your Hudson jobs. Thanks!

What I did reproduce, was the "no current connection" errors. The cause
appears to be a lock timeout when the session bean executes "select *
from students". The lock timeout takes down the connection to the
database when running in XA. Not sure why it does so, but I found this
comment in the server code that terminates the connection, so at least
it looks intentional:

// For a session ending error > CodePoint.SRVCOD_ERROR you cannot
// send a SQLERRRM. A CMDCHKRM is required. In XA if there is a
// lock timeout it ends the whole session. I am not sure this
// is the correct behaviour but if it occurs we have to send
// a CMDCHKRM instead of SQLERRM

If there's a lock hanging around from an unfinished transaction, that
would explain why getting new connections didn't help. The transactions
running in the new connections would eventually run into a lock
conflict, time out and become closed.

The lock issue also seems to prevent some of the test's cleanup:

http://sqe-hudson.us.oracle.com:8080/hudson/job/sherry-tr-c2dbg/10/console

execute-sql-common:
[echo] ***** db.url=jdbc:derby://apg-sqe2.us.oracle.com:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing file: /export/hudson/workspace/sherry-tr-c2dbg/appserver-sqe/pe/transaction/recovery/cliapp2/sql/delete_cliapp_derby.sql
[sql] Failed to execute: delete from student
[sql] java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
[sql] 0 rows affected
[sql] 1 of 2 SQL statements executed successfully

Now, the issue I didn't manage to reproduce, was the problem with the
Derby server getting into a bad state, not even helped by a restart of
the server. The transaction that held the lock causing the problems was
rolled back when the server was shut down, and I didn't see any problems
on restart.


Knut Anders

On 1/26/2011 6:16 AM, Knut Anders Hatlen wrote:
> Knut Anders Hatlen <knut.hatlen> writes:
>
>> If there's a lock hanging around from an unfinished transaction, that
>> would explain why getting new connections didn't help. The transactions
>> running in the new connections would eventually run into a lock
>> conflict, time out and become closed.
>
> One more observation: I set the XA transaction timeout to 45 seconds and
> reran the test. Then I didn't see any errors from Derby, only the JMS
> port problem. The timeout ensures that any active XA transactions
> belonging to the GF instance that was killed are rolled back in a timely
> manner, so they don't hang on to resources indefinitely.
>
> I think it would be reasonable to expect production servers to run with
> an XA tx timeout to clean up in the case where the appserver crashes
> mid-transaction and the database server survives. Perhaps that would be
> acceptable for this test too?
>

Comment by sherryshen [ 26/Jan/11 ]

A note about Knut's debug run on sqe hudson jobs.

From hudson configure and in $SPS_HOME

    1. KAH DEBUG START ##
      echo derby.infolog.append=true >> derby.properties
      echo derby.stream.error.logSeverityLevel=0 >> derby.properties
      echo derby.jdbc.xaTransactionTimeout=45 >> derby.properties
    2. KAH DEBUG END ##

On test machine, apg-sqe2,
see $SPS_HOME/derby.properties with 3 entries above.

From hudson console, the clean up went through fine,
execute-sql-common:
[echo] ***** db.url=jdbc:derby://apg-sqe2.us.oracle.com:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing file: /export/hudson/workspace/sherry-tr-c2dbg/appserver-sqe/pe/transaction/recovery/cliapp2/sql/delete_cliapp_derby.sql
[sql] 0 rows affected
[sql] 0 rows affected
[sql] 2 of 2 SQL statements executed successfully

Without derby timeout setting, the clean up failed due to a derby lock,
execute-sql-common:
[echo] ***** db.url=jdbc:derby://apg-sqe2.us.oracle.com:1527/testdb;retrieveMessagesFromServerOnGetMessage=true;create=true;user=dbuser;password=dbpassword; ; dbuser : dbpassword *****
[sql] Executing file: /export/hudson/workspace/sherry-tr-c2dbg/appserver-sqe/pe/transaction/recovery/cliapp2/sql/delete_cliapp_derby.sql
[sql] Failed to execute: delete from student
[sql] java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
[sql] 0 rows affected
[sql] 1 of 2 SQL statements executed successfully





[GLASSFISH-15385] Remove "commit-one-phase-during-recovery" flag if not needed Created: 29/Dec/10  Updated: 21/Sep/15

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

Type: Bug Priority: Minor
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   

Fix for 14836 introduced a <transaction-service> config property "commit-one-phase-during-recovery", that if set to true will fall back into the previous behavior, i.e. pass in 1PC flag set to true during recovery. If this property is not needed, remove it.



 Comments   
Comment by marina vatkina [ 22/Mar/13 ]

Nobody complained so far





[GLASSFISH-15377] [STRESS] java.lang.ArrayIndexOutOfBoundsException in EJB container when executing richAccess 24x7 Created: 28/Dec/10  Updated: 06/Jan/11

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

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

Attachments: Text File server.log    
Issue Links:
Dependency
blocks GLASSFISH-15425 [STRESS][umbrella] 24x7 RichAccess ru... Open

 Description   

Build : 21-dec-2010 nightly build.

See one occurrence of this exception in the cluster when running richaccess over a 24x7 period.

[#|2010-12-28T13:02:31.076+0530|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=16;_ThreadName=Thread-1;|A system exception occurred during an invocation on EJB SFSB method null
javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:1051)
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:969)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:207)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:284)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:170)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at $Proxy182.remove(Unknown Source)
at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:241)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at samples.rmiiiopclient.ejb._SFSBRemoteObjRef_DynamicStub.remove(samples/rmiiiopclient/ejb/_SFSBRemoteObjRef_DynamicStub.java)
at com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(SendOrder.java:141)
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(SendOrder.java:229)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
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:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)



 Comments   
Comment by Mahesh Kannan [ 03/Jan/11 ]

Sony, Are there any other exceptions following this exception (particularly any message that says "Caused by")?

Comment by Mahesh Kannan [ 03/Jan/11 ]

At line number 1051 in StatefulSessioncontainer, I dont see any Array access at all. The source at that line only throws EJBException(ex);

line 1051: throw new EJBException(ex);

I have asked Sony to find out if there were any other "Caused by" exception messages.

This is an EJB Container bug and not replication bug.

Since we see this only once in a 7 day run, the priority of the issue can be reduced.

Also, the message "A system exception occurred during an invocation on EJB SFSB method null " seem to indicate that the method object is null. Not sure if it is anyway related to the ArrayIndex exception.

Assigning to Marina for further evaluation.

Comment by marina vatkina [ 04/Jan/11 ]

Sony, Is monitoring on during run? Can you set ejb-container logger to FINE level and try again?

Comment by marina vatkina [ 05/Jan/11 ]

Please reopen when you have FINE logs available

Comment by sonymanuel [ 05/Jan/11 ]

Don't expect FINE logs for a stress run. We are running at 100 calls per seconds and we can't turn on FINE logging.





[GLASSFISH-6842] Timer.getTimeRemaining() returns 10ms less with each call Created: 25/Nov/08  Updated: 08/Dec/10

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

Type: Bug Priority: Minor
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


Issuezilla Id: 6,842

 Description   

I need to look why is it happening as the timeout method is called at regular
intervals.



 Comments   
Comment by ksak [ 17/Apr/09 ]

Changing to P4. The EJB timer service makes no guarantees about the accuracy of the remaining time
values, especially at this level of granularity. It would be interesting to understand why the underlying
Java SE API( and OS / hardware clock) behave this way.





[GLASSFISH-6748] use of RequiresNew without datasource access leads to NPE Created: 09/Nov/08  Updated: 27/Mar/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v2.1, V3
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: marina vatkina
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File move-delisting.patch     Zip Archive transactionNPE.zip    
Issuezilla Id: 6,748
Status Whiteboard:

V2.1.1_exclude


 Description   

We are seeing a NPE when a business method returns (stacktrace at end of
description).

We made a small test application to reproduce the issue on GF V2.1 b53.

Client calls an EJB, which starts a transaction (using RequiresNew) and accesses
a datasource. This bean then calls a second EJB, which starts another
transaction (using RequiresNew). When the methods return a NPE happens in the
container:

java.lang.NullPointerException
at
com.sun.enterprise.resource.ConnectorXAResource.getResourceHandle(ConnectorXAResource.java:228)
at
com.sun.enterprise.resource.ConnectorXAResource.start(ConnectorXAResource.java:124)
at
com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.enlistResource(J2EETransactionManagerOpt.java:159)
at
com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.enlistComponentResources(J2EETransactionManagerImpl.java:563)
at
com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.postInvoke(J2EETransactionManagerImpl.java:675)
at
com.sun.enterprise.util.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:221)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1329)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:134)
at $Proxy41.call(Unknown Source)
at com.fujitsu.test.ejb3.FirstBean.call(FirstBean.java:49)



 Comments   
Comment by Dies Koper [ 09/Nov/08 ]

Created an attachment (id=2094)
reproducible test case. Readme.txt inside.

Comment by marina vatkina [ 10/Nov/08 ]

Looking into it...

Comment by marina vatkina [ 10/Nov/08 ]

The bug is in the connector code that doesn't expect that no reasource had been
accessed in a transaction - if I change the test case to get a connection and
close it the the 2nd bean, it works as expected:

START : InitialContext new
END : InitialContext new
START : lookup
END : lookup
sleep time(ms):0
START : invoke
END : invoke :

Note about the test case: the ejb srces in the zip file are not separated into
local/remote subpackages, so they don't match neither the DDs nor the jar.

Comment by marina vatkina [ 10/Nov/08 ]

changed the summary to reflect the actual situation

Comment by Jagadish [ 17/Nov/08 ]

NPE is an after effect.

I could see the following behavior :
---------------------------------------------------------------------
FirstBean.call() [tx-1] [new-tx]

{ getConnection() SecondBean.call() - > [new-tx] [tx-1 suspeded] [tx2-started] }

at the end of secondBean.call(), invocationManager tries to re-enlist
the resources of "first-bean-invocation".

The "transaction" used by TxMgrOpt is (tx-1) and TxMgrOpt calls start on
ConnectorXAResource.

ConnectorXAResource will use the current transaction's non-xa resource.
Somehow, Switch.getSwitch().getTxMgr().getTransaction() returns tx-2
[ second bean's transaction which does not have any non-xa resource] and
as a result NPE is thrown.
---------------------------------------------------------------------

We can not proceed with the resourceHandle in
the ConnectorXAResource wrapper as it will violate sharing semantics.

When there is no resource in the current transaciton, we can throw XA
Exception during start, but that is incorrect and does not provide required
behavior (solution) for the application.

Fix should be either from transaction-manager or invocation-manager (container)

Transferring this to Marina for further investigation.

Comment by Jagadish [ 17/Nov/08 ]

adding cc

Comment by marina vatkina [ 18/Nov/08 ]

Let's start with the EJB container, and may be remove preInvoke/postInvoke from
the TxMgr alltogether.

The EJB Container in it's postInvoke does currently this:
BaseContainer.postInvoke
---> InvocationManagerImpl.postInvoke
---> SecurityManager.postInvoke or RealmAdapter.postSetRunAsIdentity
---> tm.postInvoke
---> delistComponentResources(curr, false)
---> enlistComponentResources(prev)
---> PoolManager.postInvoke
---> postInvokeTx
---> transactionManager.resume // if needed
---> releaseContext

Depending on the PoolManager.postInvoke, InvocationManagerImpl (or TxMgr if we
decide so) can just do delistResources in postInvoke, but then BaseContainer
needs to call enlistResources after resume.

There is some logic in BaseContainer.postInvokeTx() that shouldn't be moved to
TxMgr (IMHO), but there is also some logic in checking that there is a
transaction associated with the invocation in the
J2EETransactionManagerImpl.postInvoke() that either needs to be moved to the
BaseContainer, or be executed by the new TxMgr API.

The same changes needs to apply to the preInvoke processing.

Comment by Dies Koper [ 04/Jan/09 ]

Created an attachment (id=2181)
proposed patch

Comment by Dies Koper [ 04/Jan/09 ]

The patch I just attached solves the issue for us, the NPE does not occur
anymore.

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 Dies Koper [ 10/Feb/09 ]

Hi Ken,

Would you evaluate the patch that I had attached?

Thanks,
Dies

Comment by Dies Koper [ 12/Feb/09 ]

We did the following testing with the proposed patch:

1. To confirm the code in the patch is executed as expected:

  • followed all possible paths in the postInvoke method using a debugger to
    check the values and branches.

2. To confirm the issue itself is fixed:

  • ran the test case I had attached to the issue.

3. To check the transaction attributes work as they should:

  • used a Bean1 -> Bean2 test application with BMT and CMT (all 6 transaction
    attributes) accessing a JDBC resource directly (no JPA).

4. To confirm the patch did not break anything else:

  • ran Java EE 5 CTS categories ejb, ejb30 and jta; all passed.
Comment by marina vatkina [ 12/Feb/09 ]

It should be a p3 for v3 so that we won't forget about it. But we need to
address the connector interaction as well to make sure all parts of the code are
doing the right thing.

Comment by marina vatkina [ 10/Jun/09 ]

After discussing this with Jagadish and Sankar, we agreed that the behavior
needs to be changed in the transaction-connector interaction for resource start
and end. The problem is with the non-XA resources that are handled by the same
api as the XA resources which does not allow the non-XA resource to be
associated with a transaction that is not current.

The solution would be to call new ResourceHandler startXXX and endXXX methods
and pass in the Transaction object to be used for enlist/delist.

Reassigning to Jagadish for the followup.

Dies, if you are still interested in solving this problem, feel free to provide
the patch

Comment by Dies Koper [ 10/Jun/09 ]

Sorry, I'm a bit swamped at the moment with other work and I'm not so familiar
with this code as I was when I brought up the issue and prepared the proposed patch.
I'd love to see your solution, though!

Comment by Dies Koper [ 04/Aug/09 ]

The patch I had attached in January '09 had a problem, it led to failures in
the xa category of CTS (Java EE 5).
However, with a slight modification of it all CTS tests pass again, and the
test case of this issue also works:
The attached patch modifies two classes, BaseContainer and
J2EETransactionManagerImpl. Ignore the modification to the latter class, only
apply the modification of BaseContainer.

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Jagadish [ 02/Sep/10 ]

I made an attempt to change TransactionManager-ConnectorContainer interaction
w.r.t LocalTxResource, but it does not solve the issue completely as the
contract to enlist a resource or to delist a resource takes "transaction" to
which the resource need to be enlisted or delisted.

JavaEETransactionManager.java :
public boolean delistResource(Transaction tran, TransactionalResource h,
int flag)
public boolean enlistResource(Transaction tran, TransactionalResource h)

Transferring to Marina for further investigation.

Comment by Jagadish [ 02/Sep/10 ]

Probably, we should investigate it from the BaseContainer perspective as that
will solve the issue such that all users of TransactionManager.getTransaction()
will be provided with appropriate transaction.

Comment by chaoslayer [ 17/Jun/11 ]

Oh, a bug for more than 2.5 years unfixed...

We observe this as well, when stressing our application a bit. It does not happen all the time, which makes it hard to reproduce here.

So it is still present in GlassFish 3.1 and probably in 3.1.1.

It seems clearly related to "nested" transactions via @RequiresNew or similar (at least on our side).

What we have is something like this:

  1. TX 1 begin
  2. service call (datasource A)
  3. service call (datasource B)
  4. service call (datasource A)
  5. service call (datasource B)
  6. service call @RequiresNew (⇒ TX 1 suspend)
    • TX 1.1 begin
    • access (datasource A)
    • TX 1.1 commit
  7. TX 1 resume
  8. service call (datasource A)
  9. service call (datasource B)
  10. TX 1 commit

Where datasource A is a XADataSource and datasource B is not.

So this error is thrown after the "TX 1.1 commit" (full stacktrace of GF 3.1):

[#|2011-06-17T13:16:01.504+0200|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|_ThreadID=680;_ThreadName=Thread-1;|RAR5031:System Exception
java.lang.NullPointerException
	at com.sun.enterprise.resource.ConnectorXAResource.getResourceHandle(ConnectorXAResource.java:246)
	at com.sun.enterprise.resource.ConnectorXAResource.start(ConnectorXAResource.java:136)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistResource(JavaEETransactionManagerSimplified.java:377)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.enlistComponentResources(JavaEETransactionManagerSimplified.java:1336)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.postInvoke(JavaEETransactionManagerSimplified.java:642)
	at com.sun.enterprise.transaction.TransactionInvocationHandler.beforePostInvoke(TransactionInvocationHandler.java:95)
	at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:201)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2015)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at $Proxy330.getJobState(Unknown Source)
	at sun.reflect.GeneratedMethodAccessor666.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.activiti.engine.impl.javax.el.OSGiServiceELResolver.invoke(OSGiServiceELResolver.java:170)
	at org.activiti.engine.impl.javax.el.CompositeELResolver.invoke(CompositeELResolver.java:408)
	at org.activiti.engine.impl.juel.AstMethod.invoke(AstMethod.java:91)
	at org.activiti.engine.impl.juel.AstMethod.eval(AstMethod.java:75)
	at org.activiti.engine.impl.juel.AstEval.eval(AstEval.java:50)
	at org.activiti.engine.impl.juel.AstNode.getValue(AstNode.java:26)
	at org.activiti.engine.impl.juel.TreeValueExpression.getValue(TreeValueExpression.java:114)
	at org.activiti.engine.impl.el.JuelExpression.getValue(JuelExpression.java:46)
	at org.activiti.engine.impl.bpmn.behavior.ServiceTaskExpressionActivityBehavior.execute(ServiceTaskExpressionActivityBehavior.java:39)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute.execute(AtomicOperationActivityExecute.java:40)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(AtomicOperationTransitionNotifyListenerStart.java:48)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:52)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:45)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionCreateScope.execute(AtomicOperationTransitionCreateScope.java:44)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake.execute(AtomicOperationTransitionNotifyListenerTake.java:61)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionDestroyScope.execute(AtomicOperationTransitionDestroyScope.java:111)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerEnd.eventNotificationsCompleted(AtomicOperationTransitionNotifyListenerEnd.java:36)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:52)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:45)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.take(ExecutionEntity.java:326)
	at org.activiti.engine.impl.bpmn.behavior.BpmnActivityBehavior.performOutgoingBehavior(BpmnActivityBehavior.java:92)
	at org.activiti.engine.impl.bpmn.behavior.BpmnActivityBehavior.performDefaultOutgoingBehavior(BpmnActivityBehavior.java:49)
	at org.activiti.engine.impl.bpmn.behavior.FlowNodeActivityBehavior.leave(FlowNodeActivityBehavior.java:44)
	at org.activiti.engine.impl.bpmn.behavior.AbstractBpmnActivityBehavior.leave(AbstractBpmnActivityBehavior.java:37)
	at org.activiti.engine.impl.bpmn.behavior.ScriptTaskActivityBehavior.execute(ScriptTaskActivityBehavior.java:49)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute.execute(AtomicOperationActivityExecute.java:40)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(AtomicOperationTransitionNotifyListenerStart.java:48)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:52)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:45)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionCreateScope.execute(AtomicOperationTransitionCreateScope.java:44)
	at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
	at org.activiti.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:481)
	at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionNotifyListenerTake.execute(AtomicOperationTransitionNotifyListenerTake.java:61)
	at org.activiti.engine.impl.i