[GLASSFISH-21552] Streaming large Downloads without Content-length when using AJP produces OutOfMemory Created: 20/Jul/16  Updated: 20/Jul/16

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

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


 Description   

When streaming large (> 100MB) downloads without Content-Length via mod_ajp to Apache, OutOfMemoryErrors occur.

Stacktrace:

java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3181)
at org.glassfish.grizzly.memory.BuffersBuffer.ensureBuffersCapacity(BuffersBuffer.java:303)
at org.glassfish.grizzly.memory.BuffersBuffer.append(BuffersBuffer.java:230)
at org.glassfish.grizzly.memory.BuffersBuffer.split(BuffersBuffer.java:463)
at org.glassfish.grizzly.http.ajp.AjpMessageUtils.appendContentAndTrim(AjpMessageUtils.java:486)
at org.glassfish.grizzly.http.ajp.AjpHandlerFilter.encodeHttpPacket(AjpHandlerFilter.java:275)
at org.glassfish.grizzly.http.ajp.AjpHandlerFilter.handleWrite(AjpHandlerFilter.java:244)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBinaryBuffers(OutputBuffer.java:1011)
at org.glassfish.grizzly.http.io.OutputBuffer.flushAllBuffers(OutputBuffer.java:982)
at org.glassfish.grizzly.http.io.OutputBuffer.close(OutputBuffer.java:715)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:263)
at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:186)
at org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.destroy(ZipArchiveOutputStream.java:1426)
at org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.close(ZipArchiveOutputStream.java:808)

The problem is also described here: https://github.com/payara/Payara/issues/350

The fix provided in this issue https://java.net/jira/browse/GLASSFISH-21202 doesn't help here. The root cause for the problem is, that in the class AjpHttpRequest the chunking isn't enabled, therefore the response is buffered completely.



 Comments   
Comment by unwichtich [ 20/Jul/16 ]

Here is the relevant grizzly bug: https://java.net/jira/browse/GRIZZLY-1787

Comment by unwichtich [ 20/Jul/16 ]

Here is a patched JAR which includes the required fix: https://dl.dropboxusercontent.com/u/6862316/so/glassfish-grizzly-extra-all.jar

The included change is very similar to this: https://github.com/GrizzlyNIO/grizzly-mirror/commit/6c08805499f7c6b64c3c8806a71f0b58b52c960b





[GLASSFISH-21551] Connection is closed by keep-alive timeout even if the connection is not idle Created: 17/Jul/16  Updated: 17/Jul/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Cai_Ming Assignee: oleksiys
Resolution: Unresolved Votes: 0
Labels: keep-alive, timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,
My web application is working on the Glassfish V2.
When lots of requests were sent one by one from client,
I found that a request of TCP connection was suddenly closed,the request was failed to be processed.

After analysis,I found the connection was closed by the keep-alive timeout.
The following is the coding of the ConnectionClose.
------------------------
com.sun.enterprise.web.connector.grizzly.SelectorThread#expireIdleKeys()

try{
long expire = (Long)attachment;
if (current - expire >= kaTimeout) {
if (enableNioLogging)

{ logger.log(Level.INFO, "Keep-Alive expired for SocketChannel " + key.channel()); }


cancelKey(key);
}
------------------------

requestA is sent and created a new connection.
After responsed, the connection is idle (waiting for the next request to come).
At the moment of going to implement the "cancelKey(key)",the next request(requestB) is coming.
So,The connection is used by requestB,but the connection is going to be closed.

The phenomenon is a bug?
I think that when the connection is not idle it shound not be closed even if "current - expire >= kaTimeout" is true.
----------------
</pre>






[GLASSFISH-21550] How to configure the location of temp directory C:/Users/pisipam/AppData/Local/Temp/ Glassfish Created: 14/Jul/16  Updated: 14/Jul/16

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

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

jdk 1.8.0_72"
Glassfish 4.1.1
Embedded glassfish 3.2-b06



 Description   

HI ,

I am trying to run tests using Embedded Glassfish

In the pom I have
Parent Project POM

<plugin>
<groupId>org.glassfish</groupId>
<artifactId>maven-embedded-glassfish-plugin</artifactId>
<version>3.1</version>
<configuration>
<goalPrefix>embedded-glassfish</goalPrefix>

<glassfishProperties>

<property>glassfish.embedded.tmpdir=$

{basedir}</property>

</glassfishProperties>
<autoDelete>true</autoDelete>

<systemProperties>
<property>org.glassfish.ejb.embedded.glassfish.embedded.tmpdir=${basedir}

</property>
</systemProperties>
</configuration>
<executions>
<execution>
<id>start-glassfish</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<!-- <execution>
<id>glassfish-deploy</id>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
<execution>
<id>glassfish-undeploy</id>
<phase>post-integration-test</phase>
<goals>
<goal>undeploy</goal>
</goals>
</execution> -->
<execution>
<id>stop-glassfish</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>

POM of EJB Project under parent Project
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.2-b06</version>
<scope>test</scope>
</dependency>

<plugin>
<groupId>org.glassfish</groupId>
<artifactId>maven-embedded-glassfish-plugin</artifactId>
</plugin>

In my test I have

File target = prepareModuleDirectory();
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(EJBContainer.MODULES, target);
properties.put("org.glassfish.ejb.embedded.glassfish.configuration.file", "./src/test/resources/glassfish/domains/domain1/config/domain.xml");

ejbContainer = EJBContainer.createEJBContainer(properties);

private File prepareModuleDirectory() throws IOException

{ File result = new File(TARGET_DIR); FileUtils.copyDirectory(new File("target/classes"), result); return result; }

When i start the embedded container from my test calling

I can load the jdbc connection pool , all the EJB contexts are working

The issue is it creates two temp folders in

C:\Users\pisipam\AppData\Local\Temp\gfembed6257424114280274898tmp
C:\Users\pisipam\AppData\Local\Temp\gfembed8497832114868367105tmp

/lib/install/applications

and some files related to
__cp_jdbc_ra
__dm_jdbc_ra
__ds_jdbc_ra
__xa_jdbc_ra
jaxr-ra
jmsra

I dont want these files to be created under
C:\Users\pisipam\AppData\Local\Temp

I want them to be configured to be creted under my project/target directory so that they can be deleted.

Because <autodelete>true</autodelete> doesnt have any effect on the files created under

C:\Users\pisipam\AppData\Local\Temp






[GLASSFISH-19470] RAR5031:System Exception -> NPE Created: 18/Dec/12  Updated: 13/Jul/16

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

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

GlassFish 3.1.2 build 23
Oracle 10.2.0.5 ia64 2-node RAC


Tags: JDBC, NullPointerException, RAR5031, connection, pool

 Description   

We are getting occasional "RAR5031" System Exceptions followed by a NullPointerException. This looks somewhat similar to GLASSFISH-13390.

It appears to have something to do with the JDBC connections or connection pools but the trace is all but clear. The DB is a 2-node RAC of 10.2.0.5.

2012-12-18T03:55:26.350+0200|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|
_ThreadID=24;_ThreadName=Thread-2;|RAR5031:System Exception
java.lang.NullPointerException

2012-12-18T03:55:26.350+0200|SEVERE|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource|
_ThreadID=24;_ThreadName=Thread-2;|RAR5031:System Exception
com.sun.appserv.connectors.internal.api.PoolingException: java.lang.NullPointerException
        at com.sun.enterprise.resource.ConnectorXAResource.getResourceHandle(ConnectorXAResource.java:255)
        at com.sun.enterprise.resource.ConnectorXAResource.end(ConnectorXAResource.java:159)
        at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.delistResource(JavaEETransactionManagerSimplified.java:528)
        at com.sun.enterprise.resource.rm.SystemResourceManagerImpl.delistResource(SystemResourceManagerImpl.java:145)
        at com.sun.enterprise.resource.pool.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:381)
        at com.sun.enterprise.resource.listener.LocalTxConnectionEventListener.connectionClosed(LocalTxConnectionEventListener.java:77)
        at com.sun.gjc.spi.ManagedConnection.connectionClosed(ManagedConnection.java:784)
        at com.sun.gjc.spi.base.ConnectionHolder.close(ConnectionHolder.java:217)
        at com.sun.gjc.spi.jdbc40.ConnectionHolder40.close(ConnectionHolder40.java:587)
        at org.hibernate.connection.DatasourceConnectionProvider.closeConnection(DatasourceConnectionProvider.java:97)
        at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474)
        at org.hibernate.jdbc.ConnectionManager.aggressiveRelease(ConnectionManager.java:429)
        at org.hibernate.jdbc.ConnectionManager.afterStatement(ConnectionManager.java:304)
        at org.hibernate.jdbc.AbstractBatcher.closePreparedStatement(AbstractBatcher.java:572)
        at org.hibernate.jdbc.AbstractBatcher.closeStatement(AbstractBatcher.java:291)
        at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:307)
        at org.hibernate.jdbc.AbstractBatcher.closeQueryStatement(AbstractBatcher.java:234)
        at org.hibernate.loader.Loader.doQuery(Loader.java:854)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
        at org.hibernate.loader.Loader.doList(Loader.java:2533)
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
        at org.hibernate.loader.Loader.list(Loader.java:2271)
        at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:119)
        at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1716)
        at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:347)
        at my.own.dao.package.MyOwnDAO.selaa(MyOwnDAO.java:126)
        at my.own.package.MyClass.selaa(MyClass.java:42)
        at sun.reflect.GeneratedMethodAccessor606.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        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:5388)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
        at $Proxy246.selaa(Unknown Source)
        at my.own.package.__EJB31_Generated__MyOwnClass__Intf____Bean__.selaa(Unknown Source)
        at my.another.package.AnotherClass.onMessage(AnotherClass.java:145)
        at sun.reflect.GeneratedMethodAccessor604.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
        at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
        at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
        at $Proxy336.onMessage(Unknown Source)
        at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
        at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.NullPointerException

The method MyOwnDAO.selaa() (=browse) is as follows. Exception is thrown on line 126 which is criteria.list().

    public static List<AGame> selaa(String serialnumber, boolean onlyActive) throws AvepsiDAOException {
        Session session = HibernateUtil.getNMSession();
        Transaction tx = null;
        try {
            tx = session.beginTransaction();
            Criteria criteria = session.createCriteria(AGame.class);
            criteria.add(Restrictions.eq("serialnumber", serialnumber));
            if (onlyActive) {
                criteria.add(Restrictions.eq("active", 1));
            }
            List list = criteria.list();
            tx.commit();
            return list;
        } catch (HibernateException e) {
            rollbackIfActive(tx);
            throw new AvepsiDAOException(e, serialnumber);            
        }
    }

Connection validation is 'on'.



 Comments   
Comment by emailnbw [ 29/May/14 ]

Occasionally seeing the same thing. Glassfish 3.1.2 b23 w/Oracle ojdbc6 driver.

Comment by sekmiller [ 18/Mar/16 ]

We are still seeing this in Glassfish 4.1

Comment by adrienb [ 13/Jul/16 ]

We are still seeing this in Glassfish 3.1.2.12. Could you resolve this bug ?





[GLASSFISH-21549] Stand alone client intermittently fails when accessing multiple clusters Created: 11/Jul/16  Updated: 11/Jul/16

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

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


 Description   

From a standalone client. When accessing 2 different clusters using JNDI, the client will sometimes access the wrong cluster.

Properties props = new Properties();
props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
props.put("com.sun.appserv.iiop.endpoints", "server1:10037,server2:10037");
InitialContext ctx = new InitialContext(props);

NamingEnumeration<NameClassPair> n = ctx.list("");
....
Accesses correct cluster all the time
....

Properties props = new Properties();
props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
props.put("com.sun.appserv.iiop.endpoints", "serverA:11037,serverB:11037");
InitialContext ctx = new InitialContext(props);

NamingEnumeration<NameClassPair> n = ctx.list("");

....
Sometimes fails by hitting previous cluster
....

SerialContext contains the following properties in "myEnv"

com.sun.appserv.ee.iiop.endpointslist=corbaloc:iiop:1.2@server1:10037,iiop:1.2@server2:10037
com.sun.appserv.iiop.endpoints=serverA:11037,serverB:11037






[GLASSFISH-21548] During startup of the server WouldBlockException is thrown, with GlassFish 4.1(hk2 2.3.0) Created: 08/Jul/16  Updated: 11/Jul/16

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

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

Windows 2012 x86_64



 Description   

GlassFish 4.1.0(hk2 2.3.0) throws WouldBlockException during startup of the server though hk2 2.2.0-b05 has a fix WouldBlockException.
https://java.net/jira/browse/GLASSFISH-20617
https://java.net/jira/browse/GLASSFISH-20604

MultiException stack 1 of 5
org.glassfish.hk2.runlevel.internal.WouldBlockException: This descriptor would block: SystemDescriptor(
implementation=com.sun.enterprise.admin.util.InstanceStateServiceImpl
contracts=

{com.sun.enterprise.admin.util.InstanceStateServiceImpl,com.sun.enterprise.admin.util.InstanceStateService}

scope=org.glassfish.hk2.runlevel.RunLevel
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=runLevelValue=

{10}

,runLevelMode=

{0}

,Bundle-SymbolicName=

{org.glassfish.main.admin.util}

,Bundle-Version=

{4.1.0}

rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.util [8]], State = [READY],234832186)
proxiable=null
proxyForSameScope=null
analysisName=null
id=346
locatorId=0
identityHashCode=240464280
reified=true)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:184)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
MultiException stack 2 of 5
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.v3.admin.CommandRunnerImpl errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
MultiException stack 3 of 5
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.v3.admin.CommandRunnerImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:389)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:647)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:214)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:237)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
MultiException stack 4 of 5
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.v3.admin.PrivateAdminAdapter errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:360)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1372)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:726)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:714)
at com.sun.enterprise.v3.services.impl.GrizzlyService.registerContainerAdapters(GrizzlyService.java:637)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:515)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneLevel.run(CurrentTaskFuture.java:753)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
MultiException stack 5 of 5
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.v3.admin.PrivateAdminAdapter
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:389)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:114)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:102)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:153)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1372)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:726)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:714)
at com.sun.enterprise.v3.services.impl.GrizzlyService.registerContainerAdapters(GrizzlyService.java:637)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:515)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpOneLevel.run(CurrentTaskFuture.java:753)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)



 Comments   
Comment by jwells [ 08/Jul/16 ]

How do you reproduce this issue? Just booting GlassFish 4.1 works fine

Comment by fyoshitomi [ 11/Jul/16 ]

I just boot GlassFish 4.1 with "asadmin start-domain" or "asadmin start-cluster". WouldBlockException have been thrown by GlassFish two times before.





[GLASSFISH-21547] stop-local-instances fails after resynchronization of server instance Created: 02/Jul/16  Updated: 02/Jul/16

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

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

Windows



 Description   

How to reproduce:

0. start-domain
1. create-cluster c1
2. create-local-instance --cluster c1 i1
3. start-local-instance i1
4. update domain.xml
5. start-localinstance i1
6. stop-local-instance i1

Stop 6 fails.

CLI1306 Warning - server instance is not running.
Command stop-local-instance executed successfully.

Problem is that after domain.xml has been updated in step 4, start-local-instance command will synchronize repository cache of server instance even though server instance is already started. Synchronization done in step 5 removes pid files from cache. stop-local-instance in step 6 look for pid file, which is gone, and incorrectly thinks server instance is already stopped and will do nothing.






[GLASSFISH-11208] JSP compiler Erro whit OSGI imported class Created: 29/Nov/09  Updated: 01/Jul/16

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: sebglon Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,208
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

have 2 bundle:
Bundla A --> a WAB bundle with a JSP pages
and
Bundle B --> that export class with static fields

The JSP pages (in Bundle A) use the exported class (in Bundle B)
When I want to see my page, i have compilation
error "org.apache.jasper.JasperException: PWC6033: Error in Javac compilation
for JSP"

Current GlassFish JSP compiler can't
see classes imported from another WAB. This is because it expects all
the dependencies to be specified in a classpath which it can pass onto
the javac. I have always felt, JSP compiler should use a classloader
backed JavaFileManager.

Forum Thread
http://forums.java.net/jive/thread.jspa?messageID=373634



 Comments   
Comment by sebglon [ 30/Nov/09 ]
      • Issue 11208 has been confirmed by votes. ***
Comment by kumara [ 30/Nov/09 ]

This is an extensive change and too risky for the v3 release targeted for next week. It will be addressed in
the next release.

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

Unfortunately, because of time constraints, we have to exclude this from 3.1 rel.

Comment by ruans [ 27/Jan/12 ]

Is there any fix for this in 3.* I've tried 3.1.2 build 26-01-2012 and the problem persists. I am forced to run my sites in karaf with pax and jetty at the moment. Much rather be using glassfish.

org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP

PWC6199: Generated servlet error:
string:///index_jsp.java:9: package com.net1.core.commons.web does not exist

PWC6199: Generated servlet error:
string:///index_jsp.java:10: package com.net1.core.commons.web.tag does not exist

PWC6199: Generated servlet error:
string:///index_jsp.java:11: package com.net1.core.commons.web.util does not exist

at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:129)
at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:299)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:392)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)

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 Sanjeeb Sahoo [ 30/Sep/13 ]

This issue is difficult to fix until JSP compiler allows us to use class loaders to be used for searching classes. So deferring it for now. Recommended work around is to use offline JSP compiler to precompile JSPs and package them in the WAB.

Comment by ejroberts [ 18/Oct/13 ]

One workaround is to push the use of the OSGi provided classes out of the JSP pages and into a local class available from within the WAB.

I have found that this manages to defer the class loading until such a point where it is then the compiled Servlet class that loads the OSGi provided classes.

Comment by PashaTurok [ 27/Dec/14 ]

The same I have in GlassFish 4.1. Five years have passed since this bug was fired. Can you say if you are going to fix it?

Comment by PashaTurok [ 05/Jan/15 ]

Please, anyone, answer my question. It's impossible to use jsp with this bug as it makes duplicate code and all soft architecture becomes a nightmare.

Comment by PashaTurok [ 01/Jul/16 ]

Here I described the suggested solution - use precompiling jsp files with GF 4.1 http://stackoverflow.com/questions/38139152/glassfish-4-and-offline-jsp-compiler I hope it will be useful for anyone.





[GLASSFISH-21083] CDI and Tag File with Parameter Creates Memory Leak Created: 09/Jun/14  Updated: 27/Jun/16

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

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


 Description   

If you have CDI enabled and a tag file with an object parameter you get a memory leak where the object that is passed in accumulates in memory each time you view the page. Dump memory with jvisualvm or jmap and look for the object you passed in.

Similar to, but not the same as: GLASSFISH-18650. I can confirm that GLASSFISH-18650 is indeed fixed based on the attached test case, but it differs from this bug in that it doesn't use parameters.



 Comments   
Comment by slominskir [ 09/Jun/14 ]

I have a simple test case, but I don't see an option to attach it. I've instead attached it to the forum thread discussing the leak: https://www.java.net/forum/topic/glassfish/glassfish/glassfish-4-memory-leak. Alternatively you can create a simple test case by extending the test case attached to GLASSFISH-18650 to include a parameter of "java.util.List" which contains a bunch of some object that you create with a well known name and can search for when you do a heap dump.

Comment by douglassm [ 17/Jul/14 ]

I have the same problem. If i reload the .war application, in console administration, the memory is collected.

Comment by smillidge-c2b2 [ 03/Aug/14 ]

I've tested with the latest 4.1 builds and the problem still exists.

Comment by smillidge-c2b2 [ 03/Aug/14 ]

Adding the following raw commit to our copy of the glassfish src tree fixes the memory leak but will need reviewing by the GlassFish team

From ce3fb85d642323fa73ba9f3430556fbbb7882e09 Mon Sep 17 00:00:00 2001
From: Steve Millidge <smillidge-AT-c2b2.co.uk>
Date: Sun, 3 Aug 2014 16:16:07 +0100
Subject: [PATCH] Added destroy managed object to fix leak of CDI beans


.../src/main/java/com/sun/enterprise/web/jsp/ResourceInjectorImpl.java | 1 +
1 file changed, 1 insertion

diff --git a/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/jsp/ResourceInjectorImpl.java b/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/jsp/ResourceInjectorImpl.java
index 0ddd30f..c5953db 100644
— a/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/jsp/ResourceInjectorImpl.java
+++ b/appserver/web/web-glue/src/main/java/com/sun/enterprise/web/jsp/ResourceInjectorImpl.java
@@ -116,6 +116,7 @@ public class ResourceInjectorImpl implements ResourceInjector {
if (desc != null) {
try

{ injectionMgr.invokeInstancePreDestroy(handler, desc); + injectionMgr.destroyManagedObject(handler); }

catch (Exception e) {
String msg = _rb.getString(EXCEPTION_DURING_JSP_TAG_HANDLER_PREDESTROY);
msg = MessageFormat.format(msg, handler);

1.8.5.2

Comment by smillidge-c2b2 [ 03/Aug/14 ]

Essentially the TagPoolHandler creates a new TagHandler via the ResourceInjector which creates a new tag handler instance as a managed object;

public <T extends JspTag> T createTagHandlerInstance(Class<T> clazz)
throws Exception

{ return webModule.getWebContainer().createTagHandlerInstance( webModule, clazz); }

However when the TagHandler calls release and then preDestroy on the ResourceInjector it never destroys the ManagedBean (TagHandler) therefore added an explicit call to destroy the managed object after preDestroy methods are called.

public void preDestroy(JspTag handler) {
if (desc != null) {
try

{ injectionMgr.invokeInstancePreDestroy(handler, desc); //line below fixes GLASSFISH-21083 injectionMgr.destroyManagedObject(handler); }

catch (Exception e)

{ String msg = _rb.getString(EXCEPTION_DURING_JSP_TAG_HANDLER_PREDESTROY); msg = MessageFormat.format(msg, handler); _logger.log(Level.WARNING, msg, e); }

}
}

Comment by kchung [ 04/Aug/14 ]

Thanks for the patch. I've committed the patch to the trunk.

Comment by smillidge-c2b2 [ 05/Aug/14 ]

Hi

Reviewing my patch I'm not sure injectionMgr.invokeInstancePreDestroy should be called as well as injectionMgr.destroyManagedObject(handler); as I think destroyManagedObject; calls preDestroy internally. I haven't tested it though.

Steve

Comment by mauritz.lovgren@hotmail.com [ 05/Aug/14 ]

Is there any chance whatsoever that this fix could make it into 4.0.1 final, or is it already too late?

Comment by kchung [ 06/Aug/14 ]

smillidge-cb: I think you are right. If you look at the source in appserver/common/container-common/src/main/java/com/sun/enterprise/container/common/impl/util/InjectionManagerImpl.java, you'll see that in the method destroyManagedObject calls managedBeanMgr.destroyManagedBean() if it is a managed beans, otherwise it calls invokeInstancePreDestroy(). So we need to remove the call to invokePreDestroy, else if it is not a managed bean, invokeInstancePredestroy will be called twice.

Please do more tests and let me know.

mauritz.lovgren, I'm trying to get the fix in 4.0.1, but time is running out.

Comment by smillidge-c2b2 [ 07/Oct/14 ]

This is in the 4.1 source tree so should be closed as resolved.

Comment by slominskir [ 27/Jun/16 ]

FYI - Forum URL has changed. Discussion on this topic is now here:

https://community.oracle.com/thread/3848032





[GLASSFISH-21546] password alias is not updated until restart the process. Created: 27/Jun/16  Updated: 27/Jun/16

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

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


 Description   

Password alias is not updated until restart the process.
This problem is reproducible in GF4.1, but is not reproducible in GF3.1.2.2.

C:\gf41\glassfish4\glassfish\bin>asadmin create-password-alias alias2
Enter the alias password>invalid password
Enter the alias password again>invalid password

C:\gf41\glassfish4\glassfish\bin>asadmin create-jdbc-connection-pool --datasourceclassname oracle.jdbc.pool.OracleConnectionPoolDataSource --restype javax.sql.ConnectionPoolDataSource --property user=SYSTEM:password=${ALIAS\=alias2}:URL="jdbc\:oracle\:thin\:@//192.168.236.30\:1521/orcl" oraclePool2

C:\gf41\glassfish4\glassfish\bin>asadmin ping-connection-pool oraclePool2
remote failure: Ping Connection Pool failed for oraclePool2.
Connection could not be allocated because: ORA-01017: invalid username/password; logon denied
 Please check the server.log for more details.
Command ping-connection-pool failed.

C:\gf41\glassfish4\glassfish\bin>asadmin update-password-alias alias2
Enter the alias password>valid password
Enter the alias password again>valid password

C:\gf41\glassfish4\glassfish\bin>asadmin ping-connection-pool oraclePool2
remote failure: Ping Connection Pool failed for oraclePool2.
Connection could not be allocated because: ORA-01017: invalid username/password; logon denied
 Please check the server.log for more details.
Command ping-connection-pool failed.

C:\gf41\glassfish4\glassfish\bin>asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.

C:\gf41\glassfish4\glassfish\bin>asadmin start-domain
Waiting for domain1 to start ...............................
Successfully started the domain : domain1
domain  Location: C:\gf41\glassfish4\glassfish\domains\domain1
Log File: C:\gf41\glassfish4\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Command start-domain executed successfully.

C:\gf41\glassfish4\glassfish\bin>asadmin ping-connection-pool oraclePool2
Command ping-connection-pool executed successfully.

In GlassFish 3.1.2.2, restarting DAS is not needed after asadmin update-password-alias.



 Comments   
Comment by yama0428 [ 27/Jun/16 ]

org.glassfish.config.support.TranslatedConfigView.java is different between GF3.1.2.2 and GF4.1.

I think this problem is caused by the following code.

org.glassfish.config.support.TranslatedConfigView.java
    public static Object getTranslatedValue(Object value) {
        if (value!=null && value instanceof String) {
            String stringValue = value.toString();
            if (stringValue.indexOf('$')==-1) {
                return value;
            }
            if (domainPasswordAliasStore() != null) {
                if (getAlias(stringValue) != null) {
                    try{
                        return getRealPasswordFromAlias(stringValue);
                    } catch (Exception e) {
                        Logger.getAnonymousLogger().severe(
                                Strings.get("TranslatedConfigView.aliaserror", stringValue, e.getLocalizedMessage()));
                        return stringValue;
                    }
                }
            }
org.glassfish.config.support.TranslatedConfigView.java
    private static synchronized DomainScopedPasswordAliasStore domainPasswordAliasStore() {
        if (domainPasswordAliasStore == null) {
            domainPasswordAliasStore =
                AccessController.doPrivileged(
                        new PrivilegedAction<DomainScopedPasswordAliasStore>() {
                            public DomainScopedPasswordAliasStore run() {
                                    return habitat.getService(DomainScopedPasswordAliasStore.class);
                            }
                });
        }
        return domainPasswordAliasStore;
    }

domainPasswordAliasStore is static field, and singleton pattern is applied.
Therefore, password alias is cached after executing domainPasswordAliasStore method.
So updated password alias is not enabled if password alias is updated by asadmin create/update/delete-password-alias commands.





[GLASSFISH-21440] Webservices don't work properly in 4.1.1 Created: 12/Oct/15  Updated: 18/Jun/16

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: setup Assignee: Unassigned
Resolution: Unresolved Votes: 15
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 15.04



 Description   

After switching from 4.1 to 4.1.1 webservices fail with error 500
server-log

[2015-10-11T07:32:14.904+1000] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1444512734904] [levelValue: 900] [[
  StandardWrapperValve[javax.ws.rs.core.Application]: Servlet.service() for servlet javax.ws.rs.core.Application threw exception
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:257)
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:208)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.validateAndTransformIfNeeded(JAXBMarshaller.java:587)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.marshal(JAXBMarshaller.java:481)
	at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.writeTo(MOXyJsonProvider.java:949)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
	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:292)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
	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 org.glassfish.tyrus.servlet.TyrusServletFilter.doFilter(TyrusServletFilter.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.setupit.experiment.controller.util.URLFilter.doFilter(URLFilter.java:122)
	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:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	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:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	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:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	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:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)

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

@Entity
@Table(name = "TITLE")
@XmlRootElement
@NamedQueries({
    @NamedQuery(name = "Title.findAll", query = "SELECT t FROM Title t"),
    @NamedQuery(name = "Title.findById", query = "SELECT t FROM Title t WHERE t.id = :id"),
    @NamedQuery(name = "Title.findByTitle", query = "SELECT t FROM Title t WHERE t.title = :title"),
    @NamedQuery(name = "Title.findByFullTitle", query = "SELECT t FROM Title t WHERE t.fullTitle = :fullTitle")})
public class Title implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Basic(optional = false)
    @Column(name = "id")
    private Integer id;
    @Basic(optional = false)
    @NotNull
    @Size(min = 1, max = 45)
    @Column(name = "title")
    private String title;
    @Size(max = 1024)
    @Column(name = "full_title")
    private String fullTitle;
    @OneToMany(mappedBy = "title")
    private List<User> userList;

    public Title() {
    }

    public Title(Integer id) {
        this.id = id;
    }

    public Title(Integer id, String title) {
        this.id = id;
        this.title = title;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getFullTitle() {
        return fullTitle;
    }

    public void setFullTitle(String fullTitle) {
        this.fullTitle = fullTitle;
    }

    @XmlTransient
    public List<User> getUserList() {
        return userList;
    }

    public void setUserList(List<User> userList) {
        this.userList = userList;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof Title)) {
            return false;
        }
        Title other = (Title) object;
        if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return title + " (id=" + id + " )";
    }
    
}

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

@Stateless
@Path("title")
public class TitleService extends AbstractFacade<Title> {
    @PersistenceContext(unitName = "org.setupit_experiment_war_1.0PU")
    private EntityManager em;

    public TitleService() {
        super(Title.class);
    }

    @GET
    @Path("{id}")
    @Produces({MediaType.APPLICATION_JSON})
    public Title find(@PathParam("id") Integer id) {
        return super.find(id);
    }

    @GET
    @Override
    @Produces({MediaType.APPLICATION_JSON})
    public List<Title> findAll() {
        List<Title> lt = super.findAll();
        return lt;
    }

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }
    
}

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

    <servlet>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>


 Comments   
Comment by reza_rahman [ 12/Oct/15 ]

I can confirm this happens with Cargo Tracker as well. It's a fairly serious usability problem.

Comment by Vinay Vishal [ 14/Oct/15 ]

Bean validation was introduced in Eclipselink 2.6.0 and that is where the NoClassDefFoundError is thrown.

This could be a case of missing entries in MANIFEST.MF in org.eclipse.persistence.moxy osgi bundle. Following link suggests so.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=463169
https://java.net/jira/browse/JERSEY-2888

Comment by Lukas Jungmann [ 14/Oct/15 ]

this seems to be fixed with eclipselink-2.6.1-RC2

Comment by Vinay Vishal [ 14/Oct/15 ]

Thanks Lukas, it worked when I tried locally with eclipselink-2.6.1-RC2.

Comment by setup [ 14/Oct/15 ]

I just tried to replace eclipselink-2.6.1-RC1 with eclipselink-2.6.1-RC2. it didn't resolve the problem. Any other suggestions?

Comment by Vinay Vishal [ 15/Oct/15 ]

In my case, I rebuilt Glassfish locally after bumping up eclipselink version. Its working fine for me. May be you can try stopping the domain, cleaning up your osgi-cache inside domains/<domain> directory, restart the domain and see if it works?

Comment by nicof6786 [ 15/Oct/15 ]

Hi,
I tried to get around this issue using Jackson as a media provider.
I ran into a similar issue even though it was not blocking.
On the first call and only on the first call to a Jax-Rs resource I get the following error :

java.lang.NoClassDefFoundError: com/fasterxml/jackson/module/jaxb/JaxbAnnotationIntrospector
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospector(JsonMapperConfigurator.java:109)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospectors(JsonMapperConfigurator.java:84)
        at com.fasterxml.jackson.jaxrs.cfg.MapperConfiguratorBase._setAnnotations(MapperConfiguratorBase.java:120)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator.getDefaultMapper(JsonMapperConfigurator.java:45)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.locateMapper(ProviderBase.java:864)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:588)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
        at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
        at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
        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:292)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
        at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
        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:206)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
        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:283)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
        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:591)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
        at java.lang.Thread.run(Thread.java:745)

The subsequent calls work fine.
Should I declare another issue ?

Comment by xwibao [ 19/Oct/15 ]

That nasty JERSEY-2888 definitely crept into GlassFish 4.1.1 :-\

As a quick & dirty fix, one can find glassfish/modules/org.eclipse.persistence.moxy.jar and fix META-INF/MANIFEST.MF inside it. Simply append the following to Import-Package:

,org.xml.sax.helpers,javax.xml.parsers;resolution:=optional,javax.naming;resolution:=optional

and restart. That worked for me.

Comment by setup [ 26/Oct/15 ]

Thank you!

Editing glassfish/modules/org.eclipse.persistence.moxy.jar helps

Comment by sebastian2 [ 30/Nov/15 ]

Hi there,
this bug is also blocking us from updating to the new Glassfish version.

Comment by pdurbin [ 04/Dec/15 ]

This issue is blocking us from upgrading from Glassfish 4.1 to Glassfish 4.1.1 because bean validation isn't working in the latter. Please see the following comment for details and a stacktrace: https://github.com/IQSS/dataverse/issues/2628#issuecomment-158197478

At https://javabot.evanchooly.com/logs/%23glassfish/2015-12-04 Ed Burns mentioned that this issue (GLASSFISH-21440) is the one I should be tracking so if "bean validation" could be added to the title, I would really appreciate it. We're looking forward to a release that has the bug fix (Glassfish 4.1.2 or whatever). We'll pass on Glassfish 4.1.1. (We already do enough patching of Glassfish 4.1 per the GitHub issue above and our goal is to avoid making our users patch Glassfish.)

Thanks for Glassfish. It's great. We're looking forward to upgrading. (I kind of want to play with Ozark.

Comment by Pavel Bucek [ 04/Dec/15 ]

If you just wan't to "play", you can checkout and build glassfish trunk, I believe the issue is resolved there.

Comment by basler [ 22/Dec/15 ]

This bug is blocking my upgrade, but the moxy patch listed above worked.

Comment by nabizamani [ 23/Jan/16 ]

Hello Oracle!!!! I can confirm this bug also exists also on Mac OS.

It's such a pity that you don't care about this serious issue! I'm writing tutorials based on Glassfish and I just decided to drop Glassfish for all my future tutorials because the quality of GF is disgusting compared to the times it was managed by Sun! I will use Tomcat instead, congrats!! I'm so disappointed. It's such a shame that this obvious issue is not even assigned yet!

Comment by atiqkhaled [ 09/Apr/16 ]

Hi
Did you try it for XML. I mean replace xml on @Produces(

{MediaType.APPLICATION_JSON}

) . Hope it works then.

Comment by nabizamani [ 14/Apr/16 ]

Helloooo Oracle, anyone working on this???

Comment by andradeb.david [ 23/May/16 ]

Hi in this post is a solution .
http://ayudasdesarrollo.blogspot.com.co/2016/05/glassfish-441-falla-con-jax-rs-y-json.html

Comment by sombriks [ 18/Jun/16 ]

hello,

i can confirm that the bug still there.

i know that java.net stuff is being deactivated, however this bug is going to be one year old soon, even though the solution is documented here.

The solution is there like a couple of weeks after the bug was reported.





[GLASSFISH-21269] Cancelled POST via AJP triggers busy wait by http-listener-1 thread Created: 11/Dec/14  Updated: 16/Jun/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1
Fix Version/s: None

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

Ubuntu 12.04.4, Chrome browser with SPDY, apache 2.2.22-1ubuntu1.4, mod_jk 1:1.2.32-1, JAX-RS-based servlet with async-supported set to true



 Description   

A http worker thread goes into a busy conversation with Apache's mod_jk. Both the mod_jk thread and http-listener-1 pool thread are sitting at high CPU (together at around 100% for my single CPU test setup) and the listener appears never to return to the thread pool.

The conversation is as follows (captured using strace on the high CPU glassfish thread):
glassfish -> mod_jk: 0x41 0x42 0x00 0x03 0x06 0x1f 0xfa (Send me up to 8186 bytes of the body)
mod_jk -> glassfish: 0x12 0x34 0x00 0x00 (end of body)
This sequence of messages is repeated very very rapidly, suggesting that the glassfish side is not handling the end of body message from mod_jk.

The request is to an asynchronous JAX-RS method via the @Suspended annotation on an AsyncResponse parameter. The body of the message is JSON and is being deserialised in the container into another method parameter.

I think the following is occurring:

  • The browser sends a post request with a (in this case) 39260 byte body, but cancels it. This closes the spdy stream and causes mod_spdy to report an end of file to mod_jk internally within apache
  • Meanwhile glassfish begins to process the request. It has not read the whole request at this time. It invokes jackson to read the request which in turn reads from the InputStream that AjpHandlerFilter provides (see AjpHandlerFilter.handleRead in the stack trace).
  • The filter chain then appears to mishandle the AJP end of file message and instead continues to request more data. I didn't see AjpHandlerFilter in the read stack trace I captured so maybe it isn't intercepting correctly.

Restarting either apache or glassfish resolves the problem. This bug may be related to https://java.net/jira/browse/GLASSFISH-21202 which seems to have a similar trigger but results in memory growth rather than the high cpu and thread exhaustion I am seeing.

I have included stack traces for the write and read phases of the conversation as captured by jstack. I have also included strace output for the beginning of the problem, and to show how it recovers once Apache is restarted:
Thread 12324: (state = IN_NATIVE)

  • sun.nio.ch.FileDispatcherImpl.write0(java.io.FileDescriptor, long, int) @bci=0 (Compiled frame; information may be imprecise)
  • sun.nio.ch.SocketDispatcher.write(java.io.FileDescriptor, long, int) @bci=4, line=47 (Compiled frame)
  • sun.nio.ch.IOUtil.writeFromNativeBuffer(java.io.FileDescriptor, java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher) @bci=114, line=93 (Compiled frame)
  • sun.nio.ch.IOUtil.write(java.io.FileDescriptor, java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher) @bci=12, line=51 (Compiled frame)
  • sun.nio.ch.SocketChannelImpl.write(java.nio.ByteBuffer) @bci=206, line=487 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(java.nio.channels.SocketChannel, java.nio.ByteBuffer) @bci=2, line=149 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeSimpleBuffer(org.glassfish.grizzly.nio.transport.TCPNIOConnection, org.glassfish.grizzly.Buffer) @bci=130, line=133 (Compil
    ed frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransport.write(org.glassfish.grizzly.nio.transport.TCPNIOConnection, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.
    grizzly.WriteResult) @bci=53, line=680 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTemporarySelectorWriter.writeNow0(org.glassfish.grizzly.nio.NIOConnection, java.net.SocketAddress, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.WriteResult) @bci=14, line=65 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorWriter.write0(org.glassfish.grizzly.nio.NIOConnection, java.net.SocketAddress, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.WriteResult, long, java.util.concurrent.TimeUnit) @bci=50, line=202 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorWriter.write(org.glassfish.grizzly.Connection, java.net.SocketAddress, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.asyncqueue.PushBackHandler, long, java.util.concurrent.TimeUnit) @bci=71, line=153 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorWriter.write(org.glassfish.grizzly.Connection, java.net.SocketAddress, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.asyncqueue.MessageCloner) @bci=19, line=78 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorWriter.write(org.glassfish.grizzly.Connection, java.lang.Object, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.asyncqueue.MessageCloner) @bci=11, line=58 (Compiled frame)
  • org.glassfish.grizzly.AbstractWriter.write(org.glassfish.grizzly.Connection, java.lang.Object, org.glassfish.grizzly.asyncqueue.WritableMessage, org.glassfish.grizzly.CompletionHandler) @bci=10, line=105 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=104, line=129 (Compiled frame)
  • org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=20, line=191 (Compiled frame)
  • org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=2, line=111 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(org.glassfish.grizzly.filterchain.FilterExecutor, org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=38, line=284 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(org.glassfish.grizzly.filterchain.FilterChainContext, org.glassfish.grizzly.filterchain.FilterExecutor, int, int, org.glassfish.grizzly.filterchain.DefaultFilterChain$FiltersState) @bci=48, line=201 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=50, line=133 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.process(org.glassfish.grizzly.Context) @bci=103, line=112 (Compiled frame)
  • org.glassfish.grizzly.ProcessorExecutor.execute(org.glassfish.grizzly.Context) @bci=53, line=77 (Compiled frame)
  • org.glassfish.grizzly.filterchain.FilterChainContext.write(java.lang.Object, java.lang.Object, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.asyncqueue.PushBackHandler, org.glassfish.grizzly.asyncqueue.MessageCloner, boolean) @bci=135, line=848 (Compiled frame)
  • org.glassfish.grizzly.filterchain.FilterChainContext.write(java.lang.Object) @bci=13, line=702 (Compiled frame)
  • org.glassfish.grizzly.http.ajp.AjpHandlerFilter.sendMoreDataRequestIfNeeded(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=114, line=504 (Compiled frame)
  • org.glassfish.grizzly.http.ajp.AjpHandlerFilter.handleRead(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=18, line=197 (Compiled frame)
  • org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=2, line=119 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(org.glassfish.grizzly.filterchain.FilterExecutor, org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=38, line=284 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(org.glassfish.grizzly.filterchain.FilterChainContext, org.glassfish.grizzly.filterchain.FilterExecutor, int, int, org.glassfish.grizzly.filterchain.DefaultFilterChain$FiltersState) @bci=48, line=201 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.read(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=83, line=351 (Compiled frame)
  • org.glassfish.grizzly.filterchain.FilterChainContext.read() @bci=65, line=695 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.blockingRead() @bci=4, line=1119 (Compiled frame)
  • org.glassfish.grizzly.http.server.io.ServerInputBuffer.blockingRead() @bci=18, line=95 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.fill(int) @bci=23, line=1143 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.read(byte[], int, int) @bci=74, line=353 (Interpreted frame)
  • org.apache.catalina.connector.InputBuffer.read(byte[], int, int) @bci=33, line=267 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteInputStream.read(byte[], int, int) @bci=97, line=270 (Interpreted frame)
  • org.glassfish.jersey.message.internal.EntityInputStream.read(byte[], int, int) @bci=7, line=101 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.loadMore() @bci=48, line=178 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.parseEscapedName(int[], int, int, int, int) @bci=268, line=1749 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.slowParseName() @bci=64, line=1654 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser._parseName(int) @bci=78, line=1499 (Compiled frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextToken() @bci=255, line=700 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringMap(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, java.util.Map) @bci=133, line=416 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=143, line=312 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=3, line=26 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=59, line=525 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, java.lang.Object) @bci=5, line=106 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, com.fasterxml.jackson.core.JsonToken) @bci=53, line=242 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=26, line=118 (Compiled frame)
  • com.fasterxml.jackson.databind.ObjectReader._bind(com.fasterxml.jackson.core.JsonParser, java.lang.Object) @bci=128, line=1233 (Interpreted frame)
  • com.fasterxml.jackson.databind.ObjectReader.readValue(com.fasterxml.jackson.core.JsonParser) @bci=6, line=677 (Interpreted frame)
  • com.fasterxml.jackson.jaxrs.base.ProviderBase.readFrom(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], javax.ws.rs.core.MediaType, javax.ws.rs.core.MultivaluedMap, java.io.InputStream) @bci=204, line=777 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.invokeReadFrom(javax.ws.rs.ext.ReaderInterceptorContext, javax.ws.rs.ext.MessageBodyReader, org.glassfish.jersey.message.internal.EntityInputStream) @bci=61, line=251 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(javax.ws.rs.ext.ReaderInterceptorContext) @bci=292, line=229 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed() @bci=46, line=149 (Interpreted frame)
  • org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundReadFrom(javax.ws.rs.ext.ReaderInterceptorContext) @bci=1, line=73 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed() @bci=46, line=149 (Interpreted frame)
  • org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], javax.ws.rs.core.MediaType, javax.ws.rs.core.MultivaluedMap, org.glassfish.jersey.internal.PropertiesDelegate, java.io.InputStream, java.lang.Iterable, boolean) @bci=48, line=1124 (Interpreted frame)
  • org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], org.glassfish.jersey.internal.PropertiesDelegate) @bci=116, line=851 (Interpreted frame)
  • org.glassfish.jersey.server.ContainerRequest.readEntity(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[]) @bci=8, line=270 (Interpreted frame)
  • org.glassfish.jersey.server.internal.inject.EntityParamValueFactoryProvider$EntityValueFactory.provide() @bci=60, line=96 (Interpreted frame)
  • org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(java.util.List) @bci=46, line=81 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues() @bci=4, line=121 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(java.lang.Object, javax.ws.rs.core.Request) @bci=3, line=136 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(java.lang.Object, org.glassfish.jersey.server.ContainerRequest) @bci=5, line=104 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(org.glassfish.jersey.server.internal.process.RequestProcessingContext, java.lang.Object) @bci=28, line=387 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(org.glassfish.jersey.server.internal.process.RequestProcessingContext) @bci=97, line=331 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(java.lang.Object) @bci=5, line=103 (Interpreted frame)
  • org.glassfish.jersey.server.ServerRuntime$1.run() @bci=57, line=271 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors$1.call() @bci=4, line=271 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors$1.call() @bci=1, line=267 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(java.util.concurrent.Callable, boolean) @bci=36, line=315 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(org.glassfish.jersey.internal.util.Producer, boolean) @bci=2, line=297 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(java.lang.Runnable) @bci=9, line=267 (Interpreted frame)
  • org.glassfish.jersey.process.internal.RequestScope.runInScope(org.glassfish.jersey.process.internal.RequestScope$Instance, java.lang.Runnable) @bci=23, line=297 (Interpreted frame)
  • org.glassfish.jersey.server.ServerRuntime.process(org.glassfish.jersey.server.ContainerRequest) @bci=164, line=254 (Interpreted frame)
  • org.glassfish.jersey.server.ApplicationHandler.handle(org.glassfish.jersey.server.ContainerRequest) @bci=5, line=1028 (Interpreted frame)
  • org.glassfish.jersey.servlet.WebComponent.service(java.net.URI, java.net.URI, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=119, line=372 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(java.net.URI, java.net.URI, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=9, line=381 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=362, line=344 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=39, line=221 (Interpreted frame)
  • org.apache.catalina.core.StandardWrapper.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.Servlet) @bci=122, line=1682 (Interpreted frame)
  • org.apache.catalina.core.StandardWrapperValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=694, line=318 (Interpreted frame)
  • org.apache.catalina.core.StandardContextValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=74, line=160 (Interpreted frame)
  • org.apache.catalina.core.StandardPipeline.doInvoke(org.apache.catalina.Request, org.apache.catalina.Response, boolean) @bci=168, line=734 (Interpreted frame)
  • org.apache.catalina.core.StandardPipeline.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=4, line=673 (Interpreted frame)
  • com.sun.enterprise.web.WebPipeline.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=99, line=99 (Interpreted frame)
  • org.apache.catalina.core.StandardHostValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=44, line=174 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteAdapter.doService(org.glassfish.grizzly.http.server.Request, org.apache.catalina.connector.Request, org.glassfish.grizzly.http.server.Response, org.apache.catalina.connector.Response, boolean) @bci=425, line=415 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteAdapter.service(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=183, line=282 (Interpreted frame)
  • com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call() @bci=12, line=459 (Interpreted frame)
  • com.sun.enterprise.v3.services.impl.ContainerMapper.service(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=15, line=167 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpHandler.runService(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=48, line=201 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpHandler.doHandle(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=131, line=175 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=348, line=235 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=2, line=119 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(org.glassfish.grizzly.filterchain.FilterExecutor, org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=38, line=284 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(org.glassfish.grizzly.filterchain.FilterChainContext, org.glassfish.grizzly.filterchain.FilterExecutor, int, int, org.glassfish.grizzly.filterchain.DefaultFilterChain$FiltersState) @bci=48, line=201 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=50, line=133 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.process(org.glassfish.grizzly.Context) @bci=103, line=112 (Interpreted frame)
  • org.glassfish.grizzly.ProcessorExecutor.execute(org.glassfish.grizzly.Context) @bci=53, line=77 (Interpreted frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=69, line=561 (Interpreted frame)
  • org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener, java.util.logging.Logger) @bci=9, line=112 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=6, line=117 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=3, line=56 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run() @bci=12, line=137 (Interpreted frame)
  • org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork() @bci=47, line=565 (Interpreted frame)
  • org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run() @bci=9, line=545 (Interpreted frame)
  • java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)

The read phase of the cycle looks like this:
Thread 12324: (state = IN_NATIVE)

  • sun.nio.ch.FileDispatcherImpl.read0(java.io.FileDescriptor, long, int) @bci=0 (Compiled frame; information may be imprecise)
  • sun.nio.ch.SocketDispatcher.read(java.io.FileDescriptor, long, int) @bci=4, line=39 (Compiled frame)
  • sun.nio.ch.IOUtil.readIntoNativeBuffer(java.io.FileDescriptor, java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher) @bci=114, line=223 (Compiled frame)
  • sun.nio.ch.IOUtil.read(java.io.FileDescriptor, java.nio.ByteBuffer, long, sun.nio.ch.NativeDispatcher) @bci=29, line=192 (Compiled frame)
  • sun.nio.ch.SocketChannelImpl.read(java.nio.ByteBuffer) @bci=234, line=379 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOUtils.readSimpleByteBuffer(org.glassfish.grizzly.nio.transport.TCPNIOConnection, java.nio.ByteBuffer) @bci=10, line=344 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOUtils.allocateAndReadBuffer(org.glassfish.grizzly.nio.transport.TCPNIOConnection) @bci=55, line=237 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransport.read(org.glassfish.grizzly.Connection, org.glassfish.grizzly.Buffer) @bci=22, line=618 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTemporarySelectorReader.readNow0(org.glassfish.grizzly.nio.NIOConnection, org.glassfish.grizzly.Buffer, org.glassfish.grizzly.ReadResult) @bci=25, line=65 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read0(org.glassfish.grizzly.nio.NIOConnection, org.glassfish.grizzly.ReadResult, org.glassfish.grizzly.Buffer, long, java.util.concurrent.TimeUnit) @bci=39, line=171 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read0(org.glassfish.grizzly.nio.NIOConnection, org.glassfish.grizzly.Interceptor, org.glassfish.grizzly.ReadResult, org.glassfish.grizzly.Buffer, long, java.util.concurrent.TimeUnit) @bci=20, line=141 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(org.glassfish.grizzly.Connection, org.glassfish.grizzly.Buffer, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.Interceptor, long, java.util.concurrent.TimeUnit) @bci=52, line=113 (Compiled frame)
  • org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(org.glassfish.grizzly.Connection, org.glassfish.grizzly.Buffer, org.glassfish.grizzly.CompletionHandler, org.glassfish.grizzly.Interceptor) @bci=18, line=75 (Compiled frame)
  • org.glassfish.grizzly.AbstractReader.read(org.glassfish.grizzly.Connection, org.glassfish.grizzly.Buffer) @bci=12, line=72 (Compiled frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=57, line=77 (Compiled frame)
  • org.glassfish.grizzly.filterchain.TransportFilter.handleRead(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=20, line=173 (Compiled frame)
  • org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=2, line=119 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(org.glassfish.grizzly.filterchain.FilterExecutor, org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=38, line=284 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(org.glassfish.grizzly.filterchain.FilterChainContext, org.glassfish.grizzly.filterchain.FilterExecutor, int, int, org.glassfish.grizzly.filterchain.DefaultFilterChain$FiltersState) @bci=48, line=201 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.read(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=83, line=351 (Compiled frame)
  • org.glassfish.grizzly.filterchain.FilterChainContext.read() @bci=65, line=695 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.blockingRead() @bci=4, line=1119 (Compiled frame)
  • org.glassfish.grizzly.http.server.io.ServerInputBuffer.blockingRead() @bci=18, line=95 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.fill(int) @bci=23, line=1143 (Compiled frame)
  • org.glassfish.grizzly.http.io.InputBuffer.read(byte[], int, int) @bci=74, line=353 (Interpreted frame)
  • org.apache.catalina.connector.InputBuffer.read(byte[], int, int) @bci=33, line=267 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteInputStream.read(byte[], int, int) @bci=97, line=270 (Interpreted frame)
  • org.glassfish.jersey.message.internal.EntityInputStream.read(byte[], int, int) @bci=7, line=101 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.loadMore() @bci=48, line=178 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.parseEscapedName(int[], int, int, int, int) @bci=268, line=1749 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.slowParseName() @bci=64, line=1654 (Interpreted frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser._parseName(int) @bci=78, line=1499 (Compiled frame)
  • com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextToken() @bci=255, line=700 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringMap(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, java.util.Map) @bci=133, line=416 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=143, line=312 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=3, line=26 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=59, line=525 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, java.lan
    g.Object) @bci=5, line=106 (Interpreted frame)
  • com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext, com.fasterxml.jackson.core.JsonToken) @bci=53, line=242 (Compiled frame)
  • com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) @bci=26, line=118 (Compiled frame)
  • com.fasterxml.jackson.databind.ObjectReader._bind(com.fasterxml.jackson.core.JsonParser, java.lang.Object) @bci=128, line=1233 (Interpreted frame)
  • com.fasterxml.jackson.databind.ObjectReader.readValue(com.fasterxml.jackson.core.JsonParser) @bci=6, line=677 (Interpreted frame)
  • com.fasterxml.jackson.jaxrs.base.ProviderBase.readFrom(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], javax.ws.rs.core.MediaType, javax.ws.rs.core.MultivaluedMap, java.io.InputStream) @bci=204, line=777 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.invokeReadFrom(javax.ws.rs.ext.ReaderInterceptorContext, javax.ws.rs.ext.MessageBodyReader, org.glassfish.jersey.message.internal.EntityInputStream) @bci=61, line=251 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(javax.ws.rs.ext.ReaderInterceptorContext) @bci=292, line=229 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed() @bci=46, line=149 (Interpreted frame)
  • org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundReadFrom(javax.ws.rs.ext.ReaderInterceptorContext) @bci=1, line=73 (Interpreted frame)
  • org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed() @bci=46, line=149 (Interpreted frame)
  • org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], javax.ws.rs.core.MediaType, javax.ws.rs.core.MultivaluedMap, org.glassfish.jersey.internal.PropertiesDelegate, java.io.InputStream, java.lang.Iterable, boolean) @bci=48, line=1124 (Interpreted frame)
  • org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[], org.glassfish.jersey.internal.PropertiesDelegate) @bci=116, line=851 (Interpreted frame)
  • org.glassfish.jersey.server.ContainerRequest.readEntity(java.lang.Class, java.lang.reflect.Type, java.lang.annotation.Annotation[]) @bci=8, line=270 (Interpreted frame)
  • org.glassfish.jersey.server.internal.inject.EntityParamValueFactoryProvider$EntityValueFactory.provide() @bci=60, line=96 (Interpreted frame)
  • org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(java.util.List) @bci=46, line=81 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues() @bci=4, line=121 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(java.lang.Object, javax.ws.rs.core.Request) @bci=3, line=136 (Interpreted frame)
  • org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(java.lang.Object, org.glassfish.jersey.server.ContainerRequest) @bci=5, line=104 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(org.glassfish.jersey.server.internal.process.RequestProcessingContext, java.lang.Object) @bci=28, line=387 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(org.glassfish.jersey.server.internal.process.RequestProcessingContext) @bci=97, line=331 (Interpreted frame)
  • org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(java.lang.Object) @bci=5, line=103 (Interpreted frame)
  • org.glassfish.jersey.server.ServerRuntime$1.run() @bci=57, line=271 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors$1.call() @bci=4, line=271 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors$1.call() @bci=1, line=267 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(java.util.concurrent.Callable, boolean) @bci=36, line=315 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(org.glassfish.jersey.internal.util.Producer, boolean) @bci=2, line=297 (Interpreted frame)
  • org.glassfish.jersey.internal.Errors.process(java.lang.Runnable) @bci=9, line=267 (Interpreted frame)
  • org.glassfish.jersey.process.internal.RequestScope.runInScope(org.glassfish.jersey.process.internal.RequestScope$Instance, java.lang.Runnable) @bci=23, line=297 (Interpreted frame)
  • org.glassfish.jersey.server.ServerRuntime.process(org.glassfish.jersey.server.ContainerRequest) @bci=164, line=254 (Interpreted frame)
  • org.glassfish.jersey.server.ApplicationHandler.handle(org.glassfish.jersey.server.ContainerRequest) @bci=5, line=1028 (Interpreted frame)
  • org.glassfish.jersey.servlet.WebComponent.service(java.net.URI, java.net.URI, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=119, line=372 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(java.net.URI, java.net.URI, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=9, line=381 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=362, line=344 (Interpreted frame)
  • org.glassfish.jersey.servlet.ServletContainer.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=39, line=221 (Interpreted frame)
  • org.apache.catalina.core.StandardWrapper.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.Servlet) @bci=122, line=1682 (Interpreted frame)
  • org.apache.catalina.core.StandardWrapperValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=694, line=318 (Interpreted frame)
  • org.apache.catalina.core.StandardContextValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=74, line=160 (Interpreted frame)
  • org.apache.catalina.core.StandardPipeline.doInvoke(org.apache.catalina.Request, org.apache.catalina.Response, boolean) @bci=168, line=734 (Interpreted frame)
  • org.apache.catalina.core.StandardPipeline.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=4, line=673 (Interpreted frame)
  • com.sun.enterprise.web.WebPipeline.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=99, line=99 (Interpreted frame)
  • org.apache.catalina.core.StandardHostValve.invoke(org.apache.catalina.Request, org.apache.catalina.Response) @bci=44, line=174 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteAdapter.doService(org.glassfish.grizzly.http.server.Request, org.apache.catalina.connector.Request, org.glassfish.grizzly.http.server.Response, org.apache.catalina.connector.Response, boolean) @bci=425, line=415 (Interpreted frame)
  • org.apache.catalina.connector.CoyoteAdapter.service(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=183, line=282 (Interpreted frame)
  • com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call() @bci=12, line=459 (Interpreted frame)
  • com.sun.enterprise.v3.services.impl.ContainerMapper.service(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=15, line=167 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpHandler.runService(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=48, line=201 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpHandler.doHandle(org.glassfish.grizzly.http.server.Request, org.glassfish.grizzly.http.server.Response) @bci=131, line=175 (Interpreted frame)
  • org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=348, line=235 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=2, line=119 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(org.glassfish.grizzly.filterchain.FilterExecutor, org.glassfish.grizzly.filterchain.Filter, org.glassfish.grizzly.filterchain.FilterChainContext) @bci=38, line=284 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(org.glassfish.grizzly.filterchain.FilterChainContext, org.glassfish.grizzly.filterchain.FilterExecutor, int, int, org.glassfish.grizzly.filterchain.DefaultFilterChain$FiltersState) @bci=48, line=201 (Compiled frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(org.glassfish.grizzly.filterchain.FilterChainContext) @bci=50, line=133 (Interpreted frame)
  • org.glassfish.grizzly.filterchain.DefaultFilterChain.process(org.glassfish.grizzly.Context) @bci=103, line=112 (Interpreted frame)
  • org.glassfish.grizzly.ProcessorExecutor.execute(org.glassfish.grizzly.Context) @bci=53, line=77 (Interpreted frame)
  • org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=69, line=561 (Interpreted frame)
  • org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener, java.util.logging.Logger) @bci=9, line=112 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=6, line=117 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(org.glassfish.grizzly.Connection, org.glassfish.grizzly.IOEvent, org.glassfish.grizzly.IOEventLifeCycleListener) @bci=3, line=56 (Interpreted frame)
  • org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run() @bci=12, line=137 (Interpreted frame)
  • org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork() @bci=47, line=565 (Interpreted frame)
  • org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run() @bci=9, line=545 (Interpreted frame)
  • java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)

strace output on the glassfish http-listener-1 thread:
futex(0x7fc2b8219454, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fc2b8219450,

{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7fc2b8219428, FUTEX_WAKE_PRIVATE, 1) = 1
read(480, "\0224\4a\2\4\0\10HTTP/1.1\0\0\34/base/resourc"..., 242337) = 8027
read(484, "\0224\4[\2\4\0\10HTTP/1.1\0\0\34/base/resourc"..., 242337) = 9311
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
.... many more repeats until I restart apache ...
futex(0x7fc2b8219454, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fc2b8219450, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}

) = 1
futex(0x7fc2b8219428, FUTEX_WAKE_PRIVATE, 1) = 1
read(480, "\0224\4a\2\4\0\10HTTP/1.1\0\0\34/base/resourc"..., 242337) = 8027
read(484, "\0224\4[\2\4\0\10HTTP/1.1\0\0\34/base/resourc"..., 242337) = 9311
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4
write(484, "AB\0\3\6\37\372", 7) = 7
read(484, "\0224\0\0", 242337) = 4



 Comments   
Comment by fuzzyBSc2 [ 11/Dec/14 ]

Oops, sorry. The recovery portion of the strace when apache is restarted should be this:
read(484, 0x7fc261e29ff0, 242337) = -1 EAGAIN (Resource temporarily unavailable)
epoll_ctl(488, EPOLL_CTL_ADD, 484, {EPOLLIN, {u32=484, u64=9290625383554613732}}) = 0
epoll_ctl(488, EPOLL_CTL_MOD, 484, {EPOLLIN, {u32=484, u64=9290625383554613732}}) = 0
epoll_wait(488, {{EPOLLIN|EPOLLERR|EPOLLHUP,

{u32=484, u64=9290625383554613732}

}}, 4096, 30000) = 1
read(484, 0x7fc261e29ff0, 242337) = -1 ECONNRESET (Connection reset by peer)
write(441, "\1", 1) = 1
epoll_ctl(488, EPOLL_CTL_DEL, 484, {0, {u32=484, u64=484}}) = -1 ENOENT (No such file or directory)
close(484) = 0
epoll_wait(488, {}, 4096, 0) = 0
write(2, "[#|2014-12-09T15:42:00.719+1000|"..., 8192) = -1 EPIPE (Broken pipe)
— SIGPIPE (Broken pipe) @ 0 (0) —
write(2, "(DefaultFilterChain.java:133)\n\ta"..., 955) = -1 EPIPE (Broken pipe)
— SIGPIPE (Broken pipe) @ 0 (0) —

Comment by fuzzyBSc2 [ 11/Dec/14 ]

Note: I have tried applying the patches from GLASSFISH-21202 to see if they resolve this problem, but currently they appear to have been prepared for glassfish 4.0 only, not 4.1.

Comment by oleksiys [ 12/Dec/14 ]

pls. try this patch
https://dl.dropboxusercontent.com/u/7319744/glassfish-4.1/glassfishv41-patch.zip

Comment by fuzzyBSc2 [ 15/Dec/14 ]

Thanks,

I have applied this patch and retested. I have not been able to reproduce the problem with this patch in place

Comment by fuzzyBSc2 [ 16/Dec/14 ]

If you don't mind, just a procedural question: Is there any way I could trace this binary patch to a change in the source tree? Part of the open source policy of the company I work for is that I need to show how I would build the software from source if required.

Comment by oleksiys [ 16/Dec/14 ]

)

you can track it on github
https://github.com/GrizzlyNIO/grizzly-mirror/tree/glassfish41

Comment by fuzzyBSc2 [ 16/Jun/16 ]

Is this the correct commit?
https://github.com/GrizzlyNIO/grizzly-mirror/commit/79c2e9e3bfc07f0252c3f28eda326bacf3cb658b

Comment by fuzzyBSc2 [ 16/Jun/16 ]

Incidentally, was this bug fixed in 4.1.1 by any chance? Based on https://blogs.oracle.com/theaquarium/entry/glassfish_4_1_1_has it looks like grizzly 3.2.23 is included in glassfish 4.1.1.





[GLASSFISH-21314] Cannot create JDBC Connection Pool Created: 23/Feb/15  Updated: 06/Jun/16  Resolved: 08/Jan/16

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: doobrie Assignee: Arindam Bandyopadhyay
Resolution: Fixed Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JERSEY-2861 Glassfish REST API - OPTIONS request ... Closed
Duplicate
is duplicated by GLASSFISH-21353 Cannot Create JDBC Resource or Connec... Closed
is duplicated by GLASSFISH-21524 Cannot create a JDBC Resource or a Co... Closed
Tags: javaee_ri_fix

 Description   

When attempting to create a new JDBC connection pool, GlassFish errors with the exception:

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

To reproduce, using the latest builds (from 23 Feb 2015):

1. Select Create New JDBCConnection Pool
2. Enter any valid information on Step 1 of 2 (New JDBC Connection Pool page)
3. Click the Next button and the error is thrown.

The full stack tace from the log files is as follows:

[2015-02-23T22:06:15.124+0000] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=178 _ThreadName=admin-listener(8)] [timeMillis: 1424729175124] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:846)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:504)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:79)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:642)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:120)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:201)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:126)
at javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
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)
]]

[2015-02-23T22:09:25.421+0000] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=53 _ThreadName=admin-listener(3)] [timeMillis: 1424729365421] [levelValue: 800] [[
Exception Occurred :null]]



 Comments   
Comment by nabizamani [ 24/Feb/15 ]

What DB and version are you using? What JDBC driver are you using?

Did you also try via asadmin? Here you can see how it works via asadmin and with postgres: https://www.nabisoft.com/tutorials/glassfish/using-glassfish-3-and-java-ee-6-for-longitude-latitude-calculations-to-implement-server-side-location-based-services#Step3
Probably this helps you...

A few days ago I had a similar issue when I tried to connect to the latest Postgres 9.4.1 via its latest JDBC driver. Unfortunately, it did not work at all and I thought there is a bug somewhere in Glassfish. Then I found out that the latest JDBC driver (9.4-1200-jdbc41) for Postgres has a bug, see: https://github.com/pgjdbc/pgjdbc/pull/257

However, I also get many "java.lang.IllegalStateException: getOutputStream() has already been called for this response" exceptions in my log file

Comment by tovine [ 11/Mar/15 ]

I also got this error today (running Postgresql 9.3 and the latest JDBC driver, however the error was the same before I even included the jdbc jar in the glassfish lib folder).

Tried with the latest nightly (4.1-b13 from 2015-03-09).

UPDATE: it works with the nightly build dated 2015-02-18, so it must have happened sometime during that week...

Comment by Romain Grécourt [ 11/Mar/15 ]

Can you try against the following builds?

Thanks,
Romain

Comment by Arindam Bandyopadhyay [ 15/May/15 ]

Duplicate to GLASSFISH-21353.
This is a Jersey 2.16 integration issue.The functionality is broken on 2015-02-18 due to Jersey 2.16 integration. From buildDefaultValueMap function of appserver/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java we are calling HTTP options method to populate the default value. However OPTIONS request with Accept header is giving blank response. JERSEY-2861 is created for the same.

Comment by Arindam Bandyopadhyay [ 15/May/15 ]

Please note that not only JDBC Connection Pool is broken , due to this issue we can't create any of the following resources
Concurrent Resources
--------------------
Context Services
Managed Thread Factories
Managed Executor Services
Managed Scheduled Executor Services
Connectors
-----------
Admin Object Resources
Connector Resources
Connector Connection Pools
Work Security Maps
JDBC


JDBC Resources
JDBC Connection Pools
JMS Resources
--------------
Connection Factories
Destination Resources
JNDI


Custom Resources
External Resources
JavaMail Sessions

Comment by tovine [ 22/May/15 ]

Romain Grécourt: I'm sorry for not responding earlier (been busy with school projects and final exams, plus we avoided the issue at work by using a version of Payara instead).

Isn't this issue fixed now? From the Payara release notes (http://payara.co/release_notes):
(Under Fixed issues) "269 – Nightly build 2015-04-28 does not allow creating jdbc connection pool resources through web interface"

If this is correct, then I assume the fix will be submitted back to upstream GlassFish (if it hasn't been already)...

Comment by viczai [ 19/Oct/15 ]

Checked with Oct 07 20:33 nightly build. Bug still there.

Comment by ccagf [ 29/Oct/15 ]

I have the Same Issue - Unable to Create JDBC Connection Pool through adminGUI...
Errors out: java.lang.IllegalStateException: getOutputStream() has already been called for this response

Version: GlassFish Server Open Source Edition 4.1.1 (build 1)

Stack:
[2015-10-29T10:39:21.669-0500] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=52 _ThreadName=admin-listener(2)] [timeMillis: 14461
33161669] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:851)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:504)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:79)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:642)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:120)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:202)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:127)
at javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
]]

Comment by randypeters [ 12/Nov/15 ]

This appears to make 4.1.1 completely unusable if the Admin GUI is needed and yet no activity in 6 months?

Comment by zebhed [ 07/Dec/15 ]

The only way to workaround this issue is to edit domain.xml by hand.
Or use Payara instead of Glassfish.

More info here: http://stackoverflow.com/a/33066856

Still, it is sad to see that GF 4.1.1 was released with such an obvious heavy bug.

Comment by frankmanzhu [ 07/Dec/15 ]

It is sad to see that GF 4.1.1 was released with such an obvious heavy bug. I did the GF 4.1.1 upgrade today and found the issue.

Comment by nabizamani [ 07/Dec/15 ]

I'm very unsatisfied as well. But at least the status is "IN PROGRESS". Let's give Oracle another 10 months, maybe they will solve it. But why do I feel that Oracle is not really interested in improving at least basic GF quality goals? Hm, maybe because they don't want to push Glassfish and they just don't have such goals...

Comment by raman777 [ 07/Jan/16 ]

As mentioned in GLASSFISH-21353:

In issue JERSEY 2861 it was proposed to be the solution to revert a previous change in annotation of the option method in the class "org.glassfish.admin.rest.resources.TemplateListOfResource"

The causing change was the following annotation change:

@OPTIONS
@Produces(

{MediaType.APPLICATION_JSON+";qs=0.5", MediaType.TEXT_HTML+";qs=0.5", MediaType.APPLICATION_XML+";qs=0.5"}

)
public Response options()

{ return Response.ok().entity(buildActionReportResult()).build(); }

According to JERSEY-2861 this needs to be reverted to

@OPTIONS
@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_HTML, MediaType.APPLICATION_XML})
public Response options() { return Response.ok().entity(buildActionReportResult()).build(); }

But when I take a look in the "rest-service.jar" bundeled with Glassfish 4.1.1 this change was not reverted:
--> Eclipse shows the following, when you open the file org/glassfish/admin/rest/resources/TemplateListOfResource.java:

@javax.ws.rs.OPTIONS
@javax.ws.rs.Produces(value=

{"application/json;qs=0.5","text/html;qs=0.5","application/xml;qs=0.5"}

)
public javax.ws.rs.core.Response options();

Is the change NOT integrated / NOT bundled within the current glassfish 4.1.1 release?

Comment by Arindam Bandyopadhyay [ 08/Jan/16 ]

The issue is fixed in trunk/main.
Sending nucleus/admin/rest/rest-service/src/main/java/org/glassfish/admin/rest/resources/TemplateListOfResource.java
Transmitting file data .
Committed revision 64238.

Comment by raman777 [ 08/Jan/16 ]

Resolved in Glassfish 5.0?
Is there any intermediate release planned - 4.1.2 for example - for the current Glassfish 4.1 server with this fix?

Comment by Arindam Bandyopadhyay [ 11/Jan/16 ]

The nightly build contains the fix. You can download the nightly build from http://download.oracle.com/glassfish/5.0/nightly/

Comment by jan_goyvaerts [ 19/May/16 ]

Can this fix really not be backported to GF 4 ? Seriously ?

IMHO an application server without data sources is not an application server.

Leaving GF 4 indefinitely broken is absurd. Twice so since it is supposed to be the reference implementation.

Comment by T-Gergely [ 19/May/16 ]

Re "Leaving GF 4 indefinitely broken is absurd." ...

Agreed. I regularly check for a fixed GF 4.x.
If you like conspiracy theories, you may wonder if Oracle wants you to drop GF in favor of Web*ogic. That wouldn't work of course. It's Open Source. There's Payara and more...

Comment by nabizamani [ 19/May/16 ]

I agree to both of you. Do you know how many open high prio issues I have opened many many months ago and I'm still waiting for a fix or at least for a response? This is ridiculous! Oracle is ridiculous! They are killing the community process, they kill Glassfish, NetBeans,... Words can't express how pissed I am about Oracle! For example, do you remember the old days when there was a weekly comments list ("tab sweep") on https://blogs.oracle.com/theaquarium/ that summed up great blogs from the community (I think it was all from alexis)? If you go to that page (aquarium) now you will see the last entry is from March 2nd, 2016 - that's 2.5 months ago! And, most of the other comments are marketing articles either for Oracle or the "one" person that likes to show off!

For Oracle it's a clash of interests and that's why Oracle does not care about the quality of Glassfish and about fixing bugs! From THE BEST quality OpenSource Java EE implementation Glassfish has changed to THE WORST quality OpenSource Java EE implementation - and it's THE reference implementation!! Oracle even tends to close discussions if they get to wild from the Oracle point of view, i.e. https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server .

Enough is enough! Wanna start a campaign to free Java (EE) and Glassfish from Oracle?

Comment by jan_goyvaerts [ 19/May/16 ]

I used to advocate for GF because it looks nice and was maintained by the JEE authors. But this kind of ... flaw ... ? It's like telling HTTPS is broken. What good is this application server for serious enterprise applications ?

Btw, Isn't GF already free from Oracle ? I wonder who is maintaining GF 5. Since Oracle isn't maintaining GF anymore.

Comment by neialcantarajr [ 19/May/16 ]

Really it is absurd not release a fix in version 4.
Oracle this very disappointing.

Comment by reza_rahman [ 19/May/16 ]

I advise using the GlassFish user alias to have the discussions around Oracle commitments to Java EE and GlassFish. It would be more visible there.

You would also be welcome amongst the growing ranks of the Java EE Guardians.

Comment by jan_goyvaerts [ 19/May/16 ]

Is there an actual place to voice such opinions ? The forums for Glassfish are basically dead.

Comment by reza_rahman [ 19/May/16 ]

You'll find some kindred spirits on the Java EE Guardians Google Group: https://groups.google.com/forum/#!forum/javaee-guardians. If you look around there, I think you'll be able to figure out what we are trying to do. Our Twitter account is probably also helpful: https://twitter.com/javaee_guardian. Looking at this news entry will also prove helpful: https://adtmag.com/blogs/watersworks/2016/05/java-ee-guardians-charter-draft.aspx.

None of us are alone in this. If we can work together, we have a fighting chance of making this right.

Comment by nabizamani [ 20/May/16 ]

Have a look at these issues and for how long they are open:

I'm sure you could add yours as well. How can the reference implementation of Java EE pass the TCK/Spec when all these issues and many more exist? As a conclusion Glassfish cannot be called a "Certified" Java EE 7 implementation! Payer only exists because Glasfish has become a piece of crap under Oracle (I'm happy to have Payara)! I think for a long time that Oracle is killing Glassfish on purpose, just like they don't put efforts into Java EE, and I'm not even happy with their commitment to Java EE. Remember what happened to MySql? Remember Hudson? What about NetBeans? And JavaFX? Now Java, Java EE, and Glassfish? If Oracle would invest into these then they would help their competitors - that's why there is a clash of interests! Oracle has done its best to avoid transparency in the development of Glassfish: Why isn't Glassfish on GutHub yet? Maybe because pull requests are not appreciated? Actually, Oracle have never been considered as an "OpenSource Company" in contrast to Google, Twitter, Facebook, and many more.

All that said Oracle is NOT the right place for Java, Java EE, Glassfish, etc. All this has to set "free" from Oracle. It should be part of some other organization, a Non-Profit organization maybe. Maybe Eclipse Foundation, Apache Software Foundation, or something new which brings together many interested companies and people. What I don't like about the "Java EE Guardians", I think founded by Reza, is that they sound a little too formal and too "Oracle friendly" (Code of conduct, "with Oracle", taking over JSRs,...). And all that in spite of past the experience with Oracle.

I believe that the only way to set Java, Java EE, and Glassfish free from Oracle is by putting pressure on Oracle. A lot of pressure! That could be:

  • get out of JCP
  • stop working on JSRs
  • creating forks like Payara (maybe the Node.js way, also think of how successful Jenkins is after how Oracle behaved with Hudson)
  • create fragmentation of Java, Java EE (sorry for that)
  • creating a JCP outside of Oracle and getting commitment from other companies - big and small
  • Make those leading personalities like James Gosling, Adam Bien, and other Java Champions join all THIS and exit what ever is related with Oracle - no contributions for Oracle!
  • increase the pressure on Oracle even more!!!!!
  • Even try to get Oracle clients to pressure Oracle

Again, keep in mind what happened to Node.js. First the fork, then they merged back because the fork was successful and created pressure!

I strictly believe in order to safe Java, Java EE, and Glassfish we need to get rid of Oracle. Oracle is the problem and not the solution. And there is only one solution for this: free them all from Oracle! I'm sure Google would like this taking into account the current trials in front of court (http://fortune.com/2016/05/19/larry-page-google-android-oracle/). If Oracle wins the $9 billions then they get more back than the paid for the takeover of Sun - and Oracle will do everything to get the $9 billions! Maybe after that they will allow Java, Java EE, Glassfish to be set free.

Word can't express how pissed I am about Oracle. However, continuing with Oracle and shaking hands with Oracle is not the right way after all the experience we have with Oracle. However, that's what Reza's "Java EE Guardians" seem to look for ("including Oracle").

Comment by reza_rahman [ 20/May/16 ]

We are definitely a group of collaborative professionals trying to raise awareness and solve problems with due civility, patience and balance.

Comment by jan_goyvaerts [ 23/May/16 ]

I am a bit sceptical about pressuring Oracle really. They currently have €9b reasons to cling to Java. I'm afraid it's all futile unless you fork OpenJDK into something called differently and hope the community will follow swiftly like they did for Hudson and OpenOffice. Otherwise it's all for nothing.

Just found out Oracle is not the only company actively practicing absurdity at work - Red Hat is trying too.

Have a try to download JBoss AS 7.1.2. Even after registering you'll have no access to the software. For some obscure reason Red Hat is not publishing the binaries beyond 7.1.1. But at least the source code is available for building it.

Comment by krahe [ 06/Jun/16 ]

FWIW, adding JDBC Connection Pools works fine in GF 4.1 as installed with NetBeans 8.0.2. It's only the instances of GlassFish where I've applied the updates to bring it up to version 4.1.1 that involve this issue for me. In my case luckily all I'm needing to do at this time is create a new pool that's a clone of an existing one except for targeting a different database instance, which was actually easier to do by manually editing domain.xml than it would have been through the Admin GUI. But not providing a fix for this for 4.x users remains inexcusable nonetheless.





[GLASSFISH-21545] Websocket Container init error Created: 01/Jun/16  Updated: 01/Jun/16

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

Type: Bug Priority: Major
Reporter: Huangyun Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8 Glassfish 4.1.1 Spring 4.2.6



 Description   

Maven:
<properties>
<spring.version>4.2.6.RELEASE</spring.version>
</properties>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-websocket</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-messaging</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>$

{spring.version}

</version>
<scope>compile</scope>
</dependency>

<websocket:message-broker>
<websocket:stomp-endpoint path="/monitor">
<websocket:sockjs websocket-enabled="true"/>
</websocket:stomp-endpoint>
<websocket:simple-broker prefix="/topic, /queue"/>
</websocket:message-broker>

then, start glassfish 4.1.1, the console radom show:

Servlet.service() for servlet dispatcher threw exception
java.lang.IllegalArgumentException: No 'javax.websocket.server.ServerContainer' ServletContext attribute. Are you running in a Servlet container that supports JSR-356?






[GLASSFISH-21544] imqcmd failed when the command repeats many times at 2-minute intervals Created: 31/May/16  Updated: 31/May/16

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

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


 Description   

When the imqcmd command repeats many times at 2-minute intervals,
the command failed and output the following message to console.

Error while connecting to the broker on host 'localhost' and port '37676'.
com.sun.messaging.jms.JMSSecurityException: [C4076]: Client does not have permission to create producer on destination:
__JMQAdmin user=admin, broker=localhost:37676(47987) Please check your security configurations.
Querying the destination failed.

The following message appeared on the broker log when this happened.

[B2083]: Unable to create destination _JMQAdmin [Queue], auto-creation is forbidden

Using Open MQ version is 4.5.



 Comments   
Comment by tsyama [ 31/May/16 ]

"__JMQAdmin" is the Physical Destination that the broker create automatically when the imqcmd are executed.
Connecting with the broker, the imqcmd requests the broker to (1) and (2) processing.
(1) Create "__JMQAdmin"
(2) Add producer on "__JMQAdmin"
It seems that the avobe failure occurs when "__JMQAdmin" is deleted between (1) and (2).

Receiving the request of (1), the broker confirms if the connection is AdminConnection,
adds DestType.DEST_ADMIN, DestType.DEST_LOCAL and DestType.DEST_AUTO to
the original type of destination only in the case of AdminConnection.

  • com.sun.messaging.jmq.jmsserver.data.handlers.DestinationHandler#handle(IMQConnection con, Packet msg)
    if (con.isAdminConnection()) {
       type |= DestType.DEST_ADMIN | DestType.DEST_LOCAL 
             | DestType.DEST_AUTO;
    }
    

On the other hand, receiving the request of (2),
the broker doesn't confirm if the connection is AdminConnection, the destination type is not change.

  • com.sun.messaging.jmq.jmsserver.data.handlers.ProducerHandler#handle(IMQConnection con, Packet msg)

If "_JMQAdmin" is deleted between (1) and (2), the broker is going to create "_JMQAdmin" at (2).
But the imqcmd command ends in failure because the broker throws BrokerException when "com.sun.messaging.jmq.jmsserver.core.Destination" is instantiated.

if (!DestType.isAdmin(type) && !canAutoCreate(DestType.isQueue(type),type) && !BrokerMonitor.isInternal(destination)) {
    throw new BrokerException(
            Globals.getBrokerResources().getKString(
            BrokerResources.W_DST_NO_AUTOCREATE,
             getName()),
            BrokerResources.W_DST_NO_AUTOCREATE,
            (Throwable) null,
            Status.FORBIDDEN);

When this happend, the property "imq.autocreate.queue" is false.

This failure might be fixed by confirming if the connection is AdminConnection and adding DestType.DEST_ADMIN, DestType.DEST_LOCAL and DestType.DEST_AUTO to the destination type when the broker receives the request of (2).

But this fix cause another problem with the multiple executions of the imqcmd.
The following error message appeared when a lot of imqcmd commands are executed at the same time.

3 09, 2016 10:23:14 AM com.sun.messaging.jmq.jmsclient.ExceptionHandler logCaughtException
WARNING: [I500]: Caught JVM Exception: com.sun.messaging.jms.JMSException: [ADD_PRODUCER_REPLY(19)] [C4036]: A broker error occurred. :[409] [B4063]: Can not create Destination __JMQAdmin [Queue] - the destination already exists user=admin, broker=localhost:37676(47987)
Error while connecting to the broker on host 'localhost' and port '37676'.
com.sun.messaging.jms.JMSException: [ADD_PRODUCER_REPLY(19)] [C4036]: A broker error occurred. :[409] [B4063]: Can not create Destination __JMQAdmin [Queue] - the destination already exists user=admin, broker=localhost:37676(47987)
Please verify that there is a broker running on the specified host and port or
use the '-b' option to specify the correct broker host and port.

Querying the destination failed.

The broker logged the following message at this time.

[B4063]: Can not create Destination __JMQAdmin [Queue] - the destination already exists

It may happens when creating the destination object conflicts at (2).
One imqcmd process creates "__JMQAdmin" and puts it into the list of destinations managed by a broker,
and the other one put "__JMQAdmin" which created at the same time into the list,
the broker throws the BrokerException through the following part.

    synchronized (destinationList) {
          Destination newd = (Destination)destinationList.get(duid);
          if (newd != null) { // updating existing
              throw new BrokerException("Destination already exists");
          }

I think it only have to change BrokerException to ConflictException to fix it.
ConflictException will be caught by invoker method immediately,
"__JMQAdmin" are taken out from the list at the time, and then, the broker carrys on the processing.
As a result, multiple executions of the imqcmd would not be failure.

Please refer to the following diff about a suggested fix.


Destination.diff
--- com/sun/messaging/jmq/jmsserver/core/Destination.java	Tue Jan 18 11:15:55 2011
+++ com/sun/messaging/jmq/jmsserver/core/Destination.java	Fri May 20 18:52:30 2016
@@ -5523,7 +5523,10 @@
               synchronized (destinationList) {
                     Destination newd = (Destination)destinationList.get(duid);
                     if (newd != null) { // updating existing
-                        throw new BrokerException("Destination already exists");
+                        throw new ConflictException(
+                               Globals.getBrokerResources().getKString(
+                                    BrokerResources.X_DESTINATION_EXISTS,
+                                    duid));
                     }
 
                     if (!autocreated)
@@ -5535,6 +5538,8 @@
                     destinationList.put(duid, d);
 
                }
+            } catch (ConflictException ex) {
+                throw ex;
             } catch (BrokerException ex) {
                     // may happen with timing of two brokers in an
                     // HA cluster
ProducerHandler.diff
--- com/sun/messaging/jmq/jmsserver/data/handlers/ProducerHandler.java	Fri Sep 10 07:20:39 2010
+++ com/sun/messaging/jmq/jmsserver/data/handlers/ProducerHandler.java	Fri May 20 18:53:03 2016
@@ -113,6 +113,11 @@
                 assert dest != null : " bad protocol ";
                 assert type != null : " bad protocol ";
     
+                if (con.isAdminConnection()) {
+                   type |= DestType.DEST_ADMIN | DestType.DEST_LOCAL 
+                         | DestType.DEST_AUTO;
+                }
+                
                 if (!con.isAdminConnection() && MemoryGlobals.MEM_DISALLOW_PRODUCERS) {
                     status = Status.ERROR;
                     reason = "Low memory";




[GLASSFISH-21539] JAX-WS HandlerChain issue Created: 23/Apr/16  Updated: 28/May/16

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

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

CentOS 6.5 + NetBeans 8.1



 Description   

I got the below exception when deploying web service endpoint with handlers

  • Exception log
    Severe: Component referenced from annotation symbol cannot be found
    symbol: javax.jws.HandlerChain
    location: class master.wsservices.CargoGeneralServices
    Severe: Annotations processing failed for file:/home/cargo-tracker/target/cargo-tracker/
  • JAX-WS
    @WebService
    @HandlerChain(file = "handler-chain.xml")
    public class WSGeneralService {
    /**
  • Web service operation
    */
    @WebMethod(operationName = "hello")
    public CargoDTO hello(@WebParam(name = "name") String name) { return "Hello, " + name; }

    }

  • Handler chain file
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <javaee:handler-chains
    xmlns:javaee="http://java.sun.com/xml/ns/javaee"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <javaee:handler-chain>
    <javaee:handler>
    <javaee:handler-class>JWSSOAPInterceptor</javaee:handler-class>
    </javaee:handler>
    </javaee:handler-chain>
    </javaee:handler-chains>
  • Handler class

public class JWSSOAPInterceptor implements SOAPHandler<SOAPMessageContext>{

@Override
public Set<QName> getHeaders()

{ return null; }

@Override
public boolean handleMessage(SOAPMessageContext context) {
Boolean outboundProperty = (Boolean)
context.get (MessageContext.MESSAGE_OUTBOUND_PROPERTY);

if (outboundProperty.booleanValue())

{ System.out.println("\nOutbound message:"); }

else

{ System.out.println("\nInbound message:"); }

System.out.println("======== Response: "+context.getMessage().toString());

return true;
}

@Override
public boolean handleFault(SOAPMessageContext context)

{ return true; }

@Override
public void close(MessageContext context) {

}

}



 Comments   
Comment by lprimak [ 28/May/16 ]

This is now fixed in Payara





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

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

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


 Description   

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

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

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

Using GF 4.1, the method worked correctly.



 Comments   
Comment by napu [ 12/Feb/16 ]

I can confirm the same issue.

Comment by iordannalbantov [ 25/Feb/16 ]

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

Comment by douglasjunior [ 20/Apr/16 ]

I also have a method that persists much data.

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

I can ignore it?

Comment by fgonzales [ 25/May/16 ]

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

Comment by lprimak [ 28/May/16 ]

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





[GLASSFISH-17295] Redeployment leads to a Closed EntityManagerFactory problem Created: 14/Sep/11  Updated: 28/May/16  Resolved: 29/Mar/12

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b30

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

Windows 7 x64, also reported on Linux


Attachments: Text File DeploymentHandler-DIFF.text     Text File stacktrace.txt     File webapp.war    
Tags: 3_1_2-next

 Description   

This may be a duplicate of GLASSFISH-16897.

Recipe: from admin console,

Deploy the attached WAR file (it requires a connection pool called jdbc/EmployeeDb).

Check the page /all-employees.jsf (an empty basic JSF table should be shown).

Click the "redeploy" button on the admin console.

Check the page /all-employees.jsf again.

The attached stack trace is thrown, with the pertinent error being:

"Caused by: java.lang.IllegalStateException: Attempting to execute an operation on a closed EntityManagerFactory."

Note that this doesn't seem to affect either autodeployment, or re-deploying through the asadmin tool, so I suspect this is a problem with the GUI admin tool.



 Comments   
Comment by Mitesh Meswani [ 15/Sep/11 ]

AdminGUI implements redeploy as "deploy -force=true -target das ..." JPADeployer and deployment framework need to sync up on how --target das is interpreted. Till then as a workaround, please use "undeploy" + "deploy" for redeployment

P.S. Thanks for clear steps to reproduce

Comment by Nazrul [ 24/Feb/12 ]

Another user ran into this issue. This is impacting user experience.

Comments from Mitesh: "We should attempt to fix this in next available release.". So, changing the priority to P3.

Comment by Anissa Lam [ 24/Feb/12 ]

Assign to myself. will work with Hong on how target should be specified during redeployment. She mentioned for single target, maybe we should just call deploy with force with that one target. For mulitple target, using 'domain' is fine. will confirm with her.

Comment by Anissa Lam [ 09/Mar/12 ]

Made the change on what to specify as target during deployment;
0 or more than 1 target: "domain"
1 target: "actual target name"

Mitesh confirms that this fixes the symptom for now. He believes that for long term, the code should ensure that JPADeployer should happen first.

Diff is attached.

Comment by Anissa Lam [ 09/Mar/12 ]

The fix has checked into trunk.

Comment by Anissa Lam [ 29/Mar/12 ]

The fix is in both 4.0 trunk and the 3.1.2 sustaining branch. corresponding bug# 13900347.
I am marking this bug fixed since redeployment using console also works now.
If Mitesh wants to fix the underlying problem, please open up a new bug and assign to yourself. thanks.

Comment by rainerfrey [ 19/Jul/12 ]

Can anyone tell me whether this fix is in 3.1.2.2? Thanks!

Comment by sdoca [ 04/Jun/14 ]

I am experiencing this issue in GF-4.0, so this issue is not fixed. See my comments on https://java.net/jira/browse/GLASSFISH-16897. If I try to use the undeploy/deploy workaround mentioned above, I get this issue:

Caused by: java.lang.IllegalArgumentException: Object: Change ID=TEST-6 is not a known entity type.
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4222)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:496)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)

where we are trying to create a "Batch" entity object that has a String attribut called "changeId" and we're passing the value "TEST-6" to the set method.

On first deploy, the Batch object is correctly created and the changeId set. It's only on undeploy/deploy that we see this error and the server needs to be restarted.

Comment by alexanderst [ 25/Jun/14 ]

The problem is present in 3.1.2 (build 23).

Comment by reza_rahman [ 25/Jun/14 ]

This is still a problem that is in the latest builds.

Comment by deepdish [ 19/Jul/14 ]

I have the same problem at GF4...

Comment by win_wave [ 28/Nov/14 ]

Still the same problem exists, if redeployment fails due to some CDI problems, requires restart of GF

Comment by dmatej [ 02/Jun/15 ]

Still not resolved, even on Payara 4.1.152.

Comment by lprimak [ 28/May/16 ]

This will be fixed in Payara
It is tracked by issue https://github.com/payara/Payara/issues/315





[GLASSFISH-21166] session.invalidate causes two NPE Created: 18/Aug/14  Updated: 25/May/16

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.1, future release
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dmatej Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

EAR with many WAR modules, form auth and custom realm and SSO enabled.


Tags: logout, session, weld

 Description   

The session is finally correctly invalidated, even on cluster instances, but there are these exceptions in the server.log.
I think it should throw another exception or do nothing, but it must not throw NPE.

WeldTerminalListener in current trunk is 2.2.2, current version is 2.2.4 - maybe it could be fixed, if it is really weld error.

[2014-08-18T13:42:56.479+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1408362176479] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
        at org.apache.jsp.logout_jsp._jspService(logout_jsp.java:58)
...
[2014-08-18T13:42:56.482+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=28 _ThreadName=http-listener-1(2)] [timeMillis: 1408362176482] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.authenticator.SingleSignOnEntry.expireSessions(SingleSignOnEntry.java:158)
        at com.sun.enterprise.security.web.GlassFishSingleSignOn.deregister(GlassFishSingleSignOn.java:560)
        at com.sun.enterprise.security.web.GlassFishSingleSignOn.sessionEvent(GlassFishSingleSignOn.java:337)
        at org.apache.catalina.session.StandardSession.fireSessionEvent(StandardSession.java:2318)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:984)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
        at org.apache.jsp.logout_jsp._jspService(logout_jsp.java:58)

Line 65 in WeldTerminalListener:

    private HttpSessionContext getSessionContext() {
        return beanManager.instance().select(HttpSessionContext.class).get();
    }


 Comments   
Comment by Shing Wai Chan [ 18/Aug/14 ]

Can you provide a test case to illustrate this?

Comment by dmatej [ 19/Aug/14 ]

I will try to create some. I tried to replace weld-osgi-bundle with the 2.2.4 version, the result is same.

Comment by dmatej [ 20/Aug/14 ]

It seems it is not so simple ...
1) In our 35MB big ear with around 20 modules it is logged after each logout.
2) In unit test I created, with or without SSO enabled and tested on ear containing two simple war modules it works without exceptions.
So I looked inside the Glassfish code ... meanwhile I tried to undeploy our application and same error occured. I suspect this issue is caused by the same thing as GLASSFISH-21147 , but I have to find out how to create some simplier example with the test.

[2014-08-20T17:09:18.952+0200] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=227 _ThreadName=admin-listener(6)] [timeMillis: 1408547358952] [levelValue: 800] [[
  Session event listener threw exception
java.lang.NullPointerException
        at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
        at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
        at org.apache.catalina.session.StandardManager.stop(StandardManager.java:955)
        at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6133)
        at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
Comment by dmatej [ 20/Aug/14 ]

I have downloaded weld-core sources from Github and separated that line in three.
It seems the beanManager is not injected - it is null.
Tested with weld-osgi-bundle 2.2.5-SNAPSHOT commit 81c0ee82, 2.2.4 and original 2.2.2.

public class WeldTerminalListener implements HttpSessionListener {
    @Inject
    private BeanManagerImpl beanManager;

Does someone know why and how to fix it?

I have found more messages in logs - this is in server.log file when initializing both the admingui application and our application:

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [org.glassfish.naming] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: NamedNamingObjectManager] [METHODNAME: tryNamedProxies] [[
  found cached proxy [org.glassfish.weld.BeanManagerNamingProxy@7209773] for [java:comp/BeanManager]]]

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: com.sun.faces.config.WebConfiguration] [METHODNAME: processJndiEntries] [[
  javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]]]

[2014-08-20T23:04:43.273+0200] [glassfish 4.1] [FINE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=170 _ThreadName=Thread-32] [timeMillis: 1408568683273] [levelValue: 500] [CLASSNAME: com.sun.faces.config.WebConfiguration] [METHODNAME: processJndiEntries] [[
  javax.naming.NamingException: Lookup failed for 'java:comp/env/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: No object bound to name java:comp/env/BeanManager]]]

Maybe I got some idea - my test application does not contain any beans and does not need injections ... I will take a look in the morning ... now I'm dead ...
(also catching Throwable in BeanManagerNamingProxy is really ugly )

Comment by dmatej [ 21/Aug/14 ]

I got it - when I add empty beans.xml file to the WEB-INF directory, there are no NPE any more. It seems it is some problem with using SSO, EJB3 and old J2SE war applications in one EAR. CDI then works only partially: it works on EJB modules, but not in war modules which did not declare they want it. WeldTerminalListener is maybe initialized in war module and that is the reason why it's beanManager is null.

I will try to create the test case but I am not authorized to attach files. Can you do something with it?

Comment by dmatej [ 21/Aug/14 ]

The perfectly repeatable test case is prepared, how can I upload it?

Comment by reza_rahman [ 21/Aug/14 ]

Could you kindly send it to me for now?

Comment by dmatej [ 02/Sep/14 ]

Test case uploaded to GLASSFISH-21146 (I did a mistake in e-mail subject). I still cannot upload or change JIRA attachements so I cannot fix it ...

Comment by reza_rahman [ 02/Sep/14 ]

Please email it to me. As I may have explained, we can't enable attachments for now (and perhaps even in the long term) due to security policies.

Comment by dmatej [ 13/Sep/14 ]

Please only move the attachment from GLASSFISH-21146 here.

Comment by Wydrian [ 19/Sep/14 ]

I have the same problem with a simple struts2 based application: every time the HttpSession is invalidated (even manually by calling invalidate() or by the container), a NPE is thrown by WeldTerminalListener. It is since GF 4.1 upgrade, in 4.0 and before it was working fine. Everything seems to work normally: only the log is filled with this exeption.

2014-09-20T00:20:45.571+0200|Info: Session event listener threw exception
java.lang.NullPointerException
at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:65)
at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:57)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
at hu.tikkin.action.LogoutAction.execute(LogoutAction.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:450)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265)
at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:254)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:171)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:191)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:91)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:139)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:189)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:193)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246)
at org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:562)
at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
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:724)

Comment by cistox [ 16/Nov/15 ]

Using request.logout() as per Servlet 3.0 I have same error but different line (WeldTerminalListener.java:72):

[2015-11-16T12:21:17.108+0100] [glassfish 4.1] [INFO] [] [javax.enterprise.web.core] [tid: _ThreadID=111 _ThreadName=ContainerBackgroundProcessor[StandardEngine[glassfish-web].StandardHost[server].StandardContext[/svc]]] [timeMillis: 1447672877108] [levelValue: 800] [[
Session event listener threw exception
java.lang.NullPointerException
at org.jboss.weld.servlet.WeldTerminalListener.getSessionContext(WeldTerminalListener.java:72)
at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:64)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
at org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:785)
at org.apache.catalina.session.PersistentManagerBase.backgroundProcess(PersistentManagerBase.java:429)
at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:6375)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1823)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1812)
at java.lang.Thread.run(Thread.java:745)

Comment by payara_steve [ 25/Feb/16 ]

If this is an old application that has no CDI beans but has EJBs try unticking Implicit CDI on deployment. This solved the issue in our test case.

Comment by lprimak [ 25/May/16 ]

This issue will be resolve in Payara with the next release





[GLASSFISH-17281] javax.ejb.AsyncResult in Remote interfaces with DTOs generates ClassCastException on client Created: 08/Sep/11  Updated: 23/May/16

Status: In Progress
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: vins4java Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Vista SP2
JDK 1.6.0_26


Attachments: Zip Archive AsyncTestCase-src.zip     File module-a-ear.ear     File module-b-ear.ear    
Tags: 3_1_2-exclude, asynchronous, ejb31

 Description   

Scenario:

  • 2 ear apps say A and B (module-a-ear and module-b-ear)
  • each ear has contains an ejb-jar (module-a-ejb and module-b-ejb)
  • A's ejb exposes remote interface with an @Asyncronous method
  • the asyncronous method returns a serializable DTO (ADto)
  • both A and B have the same copy of A's ejbClient in their ear's root (module-a-ejbClient.jar)

when a method of B calls a remote asynch method on A, the call is perfomed but when Future<ADto> is done, on module-b-ejb side a ClassCastException is thrown when invoking:
ADto wrappedDto = futureDto.get();

EJB 3.1 specs don't make dinstinction about local or remote interface for @Asynchrouse annotation.They also don't put any limitation in Future<V>, so Data Transfer Objects (serializable) must be supported, right?

In order to have a very simple test case (didn't want to create JEE appclient..) I've annotated module-b-ejb as WebService so that you can call module-b-ejb method via glassfish admin gui webservice tester. You can find a stacktrace in the attached zip file. I also provided the 2 deployable ear files.

IMHO:
Debugging on client side (using eclipse debugger) I had a look at classloader of the ADto instance received from A: it's the A's classloader, not B's! It's strange because I tried also to change method in the "old traditional" synch fashion( public ADto doAsync() ) and on client side the returning ADto correclty comes from A's classloader. Does this help?



 Comments   
Comment by vins4java [ 14/Oct/11 ]

any update on this issue?

Comment by Cheng Fang [ 14/Oct/11 ]

I was able to reproduce it on trunk build. Stack trace is the same as in your attachment(except slightly different line numbers):

        at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:5219)
        at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5117)
        at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4905)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:207)
        at $Proxy234.testIt(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 org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)
        at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
        at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
        at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
        at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:212)
        at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
        at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
        at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
        at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
        at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
        at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
        at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
        at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
        at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
        at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:162)
        at org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:116)
        at org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
        at org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:198)
        at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:129)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.doFilter(ServletHandler.java:985)
        at org.glassfish.grizzly.servlet.ServletHandler$FilterChainImpl.invokeFilterChain(ServletHandler.java:928)
        at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:382)
        at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:335)
        at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:161)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:286)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:223)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:155)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:134)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:827)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:103)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:111)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:131)
        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: java.lang.ClassCastException: module.a.ejb.ADto cannot be cast to module.a.ejb.ADto
        at module.b.ejb.BBean.testIt(BBean.java:36)
        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:5392)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:624)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:576)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:851)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:790)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:361)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5364)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5352)
        at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:195)
        ... 60 more
Comment by Cheng Fang [ 18/Oct/11 ]

If you do not call future.isDone() on the client side, I suspect it will work.

Comment by vins4java [ 18/Oct/11 ]

unfortunately your suspect seems to be wrong: I get the same error even if I comment isDone() call on client ejb.
I've tested this modification on Glassfish 3.1.1-build12 ( on ubuntu with java-6-sun-1.6.0.26 ).
Did you try it with trunk version (3.2)?

Comment by Cheng Fang [ 19/Oct/11 ]

Looks like the payload didn't go thru proper marshalling and unmarshalling when both sides are colocated. It could also be some caching problem.

Comment by vins4java [ 25/Oct/11 ]

So you tried deploying each ear in two different JVMs (on the same physical machine or two different ones) and it worked, or you are supposing so? let me know if there's a way for me to help you to solve this problem. We are going to rely on this feature in short/med term...

Comment by Cheng Fang [ 25/Oct/11 ]

If the two modules are deployed into separate JVM, either same host or different hosts, that should work.
There is total separation of classloaders and so shouldn't be any CCE. What I found now is the DAO instance
on the ejb server side is different from the DAO instance on the client side, which means the serialization and
deserialization did happen. But the wrong classloader (the server side classloader) was used to reconstruct
the DAO on the client side. The client side application classloader should've been used for that.

Another complication is it is not the Java serialization protocol that's been used here. I'm trying to find out
how classloader is picked to copy objects by GlassFish corba and its related modules (see
glassfish.home/modules/glassfish-corba-orb.jar, pfl*.jar).

Again I think this issue only happens with all of the following:
remote async ejb method invocations;
both client and server modules are colocated in the same JVM;
some application class (e.g., business interface classes) are duplicated in both client and server modules

If you package client module and ejb module inside the same EAR file, and extract all shared classes into EAR/lib/xxx.jar,
without duplicating them in client and ejb modules, that should help avoid this CCE. I just tried it and worked.

Comment by Cheng Fang [ 04/Nov/11 ]

In org/glassfish/pfl/dynamic/copyobject/impl/ClassCopierOrdinaryImpl (in modules/pfl-dynamic.jar)
obj.getClass() is called to get the Class, which is then used to create a class copier, which in turn creates the constructor. It is hence associated with the class loader of the source object, not the target.

This part of the code is executed to copy all fields of a source object.

After changing to use thread context class loader in instead of
obj.getClass(), it worked without CCE. There could be other places the kind of changes are also necessary. Also not clear about the full implication or side effects.

Comment by Cheng Fang [ 04/Nov/11 ]

re-assign to orb team for further evaluation.

Comment by Harshad Vilekar [ 15/Dec/11 ]

Cheng and I exchanged email on this - and decided to target this issue post 3.1.2

Comment by juergenschmied [ 23/Nov/12 ]

I get this problem after upgrading from 3.1.2 to 3.1.2.2. A application that was working before is now broken with this error. Would it help do use a Future<ByteArrayOutputStream> an do serialization/deserialization by myself? It looks like this bug does not affect build-in classes.

Thanks!

Comment by wfsaxton [ 23/May/16 ]

This bug is very old. Is it really still being worked on? Is there a workaround available?

This issue still exists in GF 4.1.





[GLASSFISH-21543] Invalid resource when using application scoped resource in EAR Created: 17/May/16  Updated: 17/May/16

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

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


 Description   

1) create EE7 EAR project with ejb and web
2) define jdbc resource and pool using java:module scope in glassfish-resources.xml in ejb module
3) define persistence unit in ejb using the jdbc resource in ejb
4) define stateless session bean
5) inject EnitityManager to the bean:
@PersistenceContext(unitName = "myUnit")
private EntityManager em;
6) deploy the EAR and it will fail with invalid resource

Standalone web module using java:app works fine. Moving the persistence.xml and glassfish-resources.xml to EAR and using java:app also works fine.



 Comments   
Comment by petrhejl [ 17/May/16 ]

I may attach/provide sample project.

Comment by petrhejl [ 17/May/16 ]

I've attached the test project to original NetBeans issue.
https://netbeans.org/bugzilla/attachment.cgi?id=159782





[GLASSFISH-18946] EAR with two CDI Jersey web archives will not deploy Created: 26/Jul/12  Updated: 13/May/16

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Ramon Rockx Assignee: Marek Potociar
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Zip Archive JerseyCDITest2.zip     File TestEAR-0.0.1-SNAPSHOT.ear     Java Archive File TestWAR1-0.0.1-SNAPSHOT-sources.jar     Java Archive File TestWAR2-0.0.1-SNAPSHOT-sources.jar    
Tags: req-weld-fix

 Description   

I already filed this issue in the Jersey JIRA (http://java.net/jira/browse/JERSEY-1232), however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/GlassFish Weld. I also filed an issue at the Weld JIRA (http://issues.jboss.org/browse/WELD-1175), but they think it should be investigated first by the GlassFish team... (from pillar to post).
Hopefully, the GlassFish team can help solving this problem.

So here are the details:
We are experiencing the following issue with Jersey 1.12 in combination with Weld 1.1.4 and Glassfish 3.1.2:
When using an EAR with two WAR's in it, the last WAR doesn't get deployed. Both WAR's are CDI enabled and contains a REST service. When deploying both WAR's without the EAR, they deploy just fine.
I will attach a test case.

Depending on the VM property
com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager we will get another Exception:

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=false:

java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'com/sun/jersey/config/CDIExtension' in
SerialContext[myEnv=java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
 java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, 
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
[Root exception is javax.naming.NameNotFoundException: CDIExtension not found]	
	at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true

java.lang.NullPointerException
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:94)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...


 Comments   
Comment by jjsnyder83 [ 03/Oct/12 ]

There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.

Comment by jjsnyder83 [ 05/Oct/12 ]

I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175.

I have checked in the fix into 3.1.2 and trunk.

Comment by jjsnyder83 [ 05/Oct/12 ]

Reopening due to the bug in Weld

Comment by Ramon Rockx [ 08/Oct/12 ]

Great that this one is fixed!
I'm looking for a way to patch our GlassFish installation (version 3.1.2.2).
jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?

Comment by jjsnyder83 [ 08/Oct/12 ]

I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0).

I will get back to you on the patching.

Please note that even though the app will deploy a fix to Weld (https://issues.jboss.org/browse/WELD-1175) is still required for the app to work correctly. See the Weld issue for details.

Comment by jjsnyder83 [ 08/Oct/12 ]

The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.

Comment by Ramon Rockx [ 09/Oct/12 ]

Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too?
(3.1.2.3 is skipped for release?)

Comment by jjsnyder83 [ 11/Oct/12 ]

Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.

Comment by jjsnyder83 [ 22/Oct/12 ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.

Comment by jjsnyder83 [ 20/Dec/12 ]

I just tested this on trunk with weld 1.1.10.Final and it doesn't work.

Comment by jwells [ 27/Mar/13 ]

I get this error now when I deploy the above ear in GF 4.0:

Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190)
at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224)
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)

I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore...

So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...

Comment by Ramon Rockx [ 02/May/13 ]

I'm wondering if this bug will be fixed with the upcoming 4.0 release?
It really makes it impossible for us to use REST in a large modular EAR application properly.

Comment by dbenegiamo [ 03/May/13 ]

As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.

Comment by Ramon Rockx [ 22/May/13 ]

Like jwells mentioned, the current test case results in ClassNotFoundExceptions.
I downloaded GlassFish 4.0 b88. Tweaked the test case:

  • no Jersey servlet configuration anymore (web.xml is empty)
  • no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x)
  • used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix.

Now each REST service does work in both web modules.

However, GlassFish does log warnings like
"[WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#]".
I'm not sure if this warning can be ignored.

I will attach my new test case.

Comment by Ramon Rockx [ 22/May/13 ]

It seems I cannot add an attachment anymore...

Comment by Jakub Podlesak [ 24/May/13 ]

Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!

Comment by Jakub Podlesak [ 27/May/13 ]

Updated test case from Ramon.

Comment by sebastian2 [ 23/Jul/14 ]

Is there a plan to fix that issue? I am also struggeling with this bug....

Comment by lprimak [ 12/May/16 ]

Payara team is tracking this bug here:
https://github.com/payara/Payara/issues/374

Comment by Jakub Podlesak [ 13/May/16 ]

Re-assigning to Marek, as i am not sure who is in charge with Jersey in GF. I am no longer part of the team.





[GLASSFISH-20720] EAR deployment with multiple embedded WARs broken in 3.1.2.2 and 4.0 Created: 22/Jul/13  Updated: 12/May/16

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1, 4.0_b89_RC5
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: nabizamani Assignee: kchung
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat Linux, Windows, Ubuntu Linux


Attachments: File TestApp.ear     File TestApp.ear    
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, metro2_2-waived

 Description   

We are trying to upgrade to 3.1. Our application is packaged and deployed as an EAR file with multiple EJB and WARs embedded. Some of the WAR files have web services for deployment, and some do not. The 3.1 deployment mechanism is fundamentally broken in this case. It appears that the web service deployment piece ends up scanning all the wars in the EAR for metadata (annotations), and then trying to deploy the collected web services in every WAR in the EAR, not just the one that had the annotated web service classes.

This appears to be the same symptoms as the following bug, but for web services instead.

http://java.net/jira/browse/JAVASERVERFACES-1995

I have attached a very simple test EAR file. Trying to deploy this will demonstrate the error. You will see error messages about duplicate web service deployments and class not found exceptions.



 Comments   
Comment by nabizamani [ 22/Jul/13 ]

I created this clone of https://java.net/jira/browse/GLASSFISH-16249 because the issue reported still exists in GF 3.1.2.2.
A similar issue also exists in GF 4.0.

Below you can see the different outputs (I used an own ear which contains an ejb module and 2 war modules of which one contains restful classes):

  • Glassfish 3.1.2.2 (build 5)
    WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
    WARNING: WEB9052: Unable to load class com.demo.service.rss.NewsFeed, reason: java.lang.ClassNotFoundException: com.demo.service.rss.NewsFeed
  • Glassfish 4.0 (build 89).
    WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
    WARNING: Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
    INFO: Registering the Jersey servlet application, named com.demo.jaxrs.application.ApplicationConfig, at the servlet mapping /*, with the Application class of the same name.
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.jaxrs.provider.MyJacksonJsonProvider, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.provider.MyJacksonJsonProvider
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig

Furthermore In GF 4.0 I get a lot of messages of this kind (which I really hate):
INFO: visiting unvisited references

Comment by Lukas Jungmann [ 01/Aug/13 ]

passing to jax-rs for evaluation since jar-rs seems to be involved here

Comment by Lukas Jungmann [ 01/Aug/13 ]

assign as needed, please. thx.

Comment by replicant77 [ 09/Sep/13 ]

We also get the ClassNotFoundException messages in multi-war deployments. But not only for rest service classes, but also for jsf related classes, like jsf converters and validators:

WARNING: WEB9052: Unable to load class gf4test.rest.TestService, reason: java.lang.ClassNotFoundException: gf4test.rest.TestService
WARNING: WEB9052: Unable to load class gf4test.converters.TestConverter1, reason: java.lang.ClassNotFoundException: gf4test.converters.TestConverter1

If you have a lot of such classes in your application this can get really annoying. We noticed these warning messages on GF 3.1.2 as well as GF4.

Comment by TangYong [ 10/Sep/13 ]

replicant77

Your attachment has problem and while deploying your attachment into 4.0.1-b02, the following error happened,

[2013-09-10T11:18:40.508+0900] [glassfish 4.0] [WARNING] [] [org.apache.jasper.runtime.TldScanner] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520508] [levelValue: 900] [[
PWC6351: In TLD scanning, the supplied resource file:/E:/NanjingJUG/glassfish-4.0.1-b02/glassfish4/glassfish/domains/domain1/applications/TestApp/TestApp-ejbClient.jar does not exist
java.io.FileNotFoundException: E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\domains\domain1\applications\TestApp\TestApp-ejbClient.jar (指定されたファイルが見つかりません。)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:214)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:152)
at java.util.jar.JarFile.<init>(JarFile.java:89)
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:98)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
at org.apache.jasper.runtime.TldScanner.scanJar(TldScanner.java:442)
at org.apache.jasper.runtime.TldScanner.scanJars(TldScanner.java:694)
at org.apache.jasper.runtime.TldScanner.scanTlds(TldScanner.java:350)
at org.apache.jasper.runtime.TldScanner.onStartup(TldScanner.java:239)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
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:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
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$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
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:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
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:318)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
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:187)
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:837)
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:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-09-10T11:18:40.867+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520867] [levelValue: 800] [[
Loading application TestApp#TestApp-war.war at [TestApp-war]]]

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

[2013-09-10T11:18:40.898+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520898] [levelValue: 800] [[
Loading application TestApp#TestApp2-war.war at [TestApp2-war]]]

[2013-09-10T11:18:40.977+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520977] [levelValue: 800] [[
TestApp was successfully deployed in 10,876 milliseconds.]]

So, I have uploaded a new attachment.

OK, current issue should be the following:

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

1. the issue is not related to jax-rs comp
2. instead, firstly forwarding to web_services comp to evaluate, and I also add web_container comp to ask shing wai to evaluate it.

Comment by TangYong [ 10/Sep/13 ]

I made an initial investigation for the issue,

1) removing web_webservices comp because I have confirmed the warning info is related to web_container comp. so, pl. Shing Wai confirms

2) the warning happened in checkAgainstInterestList method from org.glassfish.web.loader.ServletContainerInitializerUtil class

In this attachment, there are two wars and TestApp2-war does not contain any class, TestApp-war contains a class with @WebService, while checkAgainstInterestList is executed, the method also scans TestApp2-war for @WebService, so, ClassNotFoundException happened.

I think this has some wrong logic because "interestList" variable in checkAgainstInterestList always saves previous result(eg. TestApp-war), for TestApp2-war, these annotations do not exist.

However, I think this issue itself should be not important and I think this should be an improvement rather than a bug.

Thanks
Tang

Comment by Shing Wai Chan [ 10/Sep/13 ]

The ClassNotFoundException warning is related to GLASSFISH-16937 .
Assign to Kinman to investigate TLDScanning FileNotFoundException.

Comment by pbelbin [ 09/Jan/14 ]

is there a fix for this issue? or, perhaps I'm having a different issue.

I have a .ear which has multiple .war contained within it that refuses to deploy.

I do see the WEB9052 warnings.

but, after that, I also see this:

[#|2014-01-09T16:29:49.206-0600|WARNING|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=130;_ThreadName=Thread-2;|Deployment failed
java.lang.AbstractMethodError
at org.glassfish.webservices.WsUtil.parseRelativeImports(WsUtil.java:414)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1884)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1858)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:143)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:102)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

#]
Comment by lprimak [ 12/May/16 ]

Payara team is tracking this bug here:
https://github.com/payara/Payara/issues/374





[GLASSFISH-16937] Having REST services in separate WARs in a single EAR prints classloading warnings Created: 01/Jul/11  Updated: 12/May/16

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

Type: Bug Priority: Minor
Reporter: mmuller Assignee: Daniel
Resolution: Unresolved Votes: 11
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008


Attachments: File ear-1.0.ear     GZip Archive jaxrs_multimodule_test.tar.gz    
Tags: classloader, glassfish-3-1, jax-rs

 Description   

Warnings show up when an EAR is deployed, containing more than one WAR archove with REST web services. Looks like GlassFish/Jersey tries to load all the REST service classes for each of the WARs being deployed, and then shows classloader warnings:

WEB9052: Unable to load class <classname>, reason: java.lang.ClassNotFoundException: <classname>

I did a minimal project which produces an EAR with this structure:

ear-1.0.ear

  • META-INF/
`- application.xml
  • war-1-1.0.war
 
  • classes/
  `- test/war1/Service1.class
`- WEB-INF/
`- web.xml
`- war-2-1.0.war
  • classes/
`- test/war2/Service2.class
`- WEB-INF/
`- web.xml

(See the attached maven project).

test.war1.Service1 and test.war2.Service2 are POJOs with class-level @Path annotation and method-level @GET or @POST annotations.
The application.xml DD is generated by maven-ear-plugin and only contains the two webmodules and their contextroots.
Both web.xml only contain a display name and the Jersey ServletContainer loaded on startup.

When deploying to GlassFish 3.1 on Windows Server 2008, the log contains the following entries:

[#|2011-07-01T10:45:59.159+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war2.Service2, reason: java.lang.ClassNotFoundException: test.war2.Service2|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war1.Service1|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.354+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-1-1.0.war at [/war1]|#]

[#|2011-07-01T10:45:59.368+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war1.Service1, reason: java.lang.ClassNotFoundException: test.war1.Service1|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war2.Service2|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.521+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-2-1.0.war at [/war2]|#]

[#|2011-07-01T10:45:59.535+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=183;_ThreadName=Thread-1;|ear-1.0 was successfully deployed in 543 milliseconds.|#]

So this looks like Glassfish tries to load both services for each WAR module. When loading war-1, it cannot load test.war2.Service2, and while loading war-2, it cannot load test.war1.Service1...
Although, the application is correctly deployed and all the services do work !!

I guess this is a tiny bug, and could be fixed within a handful of lines. I could try to fix it, if someone could point me to the right module producing this warning.



 Comments   
Comment by mmuller [ 01/Jul/11 ]

Oops, looks like Jira didn't like my folder-tree syntax.

So, the EAR structure is

ear-1.0.ear
  META-INF/
    application.xml
  war-1-1.0.war
    classes/
      test/war1/Service1.class
    WEB-INF/
      web.xml
  war-2-1.0.war
    classes/
      test/war2/Service2.class
    WEB-INF/
      web.xml
Comment by Shing Wai Chan [ 01/Jul/11 ]

The calling stack is as follows:
StandardContext#callServletContainerInitializer
--> ServletContainerInitializerUtil#getInitializerList
--> ServletContainerInitializerUtil#checkAgainstInterestList

and the warning is coming from calling the checkAgainstInterestList method

The issue is from argument of calling the last method as follows:
1. Types classInfo contains the classes information for the ear
which is from WebModule#getTypes
wmInfo.getDeploymentContext().getTransientAppMetaData(
Types.class.getName(), Types.class);
2. WebappClassLoader cl, for war1, say, then it cannot load classes for war2

Even though the returned value of the method is correct, there is unnecessary call for loading other classes.

Comment by geturnerlmco [ 13/Oct/11 ]

This happens if there are multiple WARs, period. I have an application with 5 WARs, two are SOAP service endpoints and 3 are REST. If I remove 2 of the 3 REST WARS, I still get the WARNINGS. If I remove the 2 SOAP WARs, the WARNINGS are gone. I have searched every forum for an answer to this annoying problem, but this is the first one that is the closest to my problem. If anyone has a workaround other than destroying my EAR structure (which doesn't work well for fielding, ha ha) I would really appreciate knowing it.

Comment by geturnerlmco [ 14/Oct/11 ]

One additional comment that I thought would be helpful. I commented out all of the additional WARs from my application.xml but still built the EAR normally. The WARNINGS occured, just because the modules existed in the EAR directory structure, but the module definitions were commented out! Is the class scanner looking for ANY .class file in the EAR directory, whether it was defined to be part of the application or not???

Comment by Dan.Daneasa [ 23/Oct/11 ]

I have more comments on this.
I have 2 wars deployed in the same ear. One is a Jersey simple west app, the other one is an empty war.
I can see the ClassNotFoundExceptions.

There may be more to this problem. If i have an ear with 2 wars, one is a simple Jersey rest app, the other a simple Mojarra faces app. I see that the ClassNotFoundException is still present, also there are Mojarra-impl ClassNotFoundException warnings.
The same happens if i try to integrate MyFaces instead of Mojarra in the faces webapp.
Mojarra/Myfaces tries to load in the Jersey app as well, and vice-versa, Jersey tries to load in the Mojarra/MyFaces app.

If I have only one of the wars in the ear in any of the above combinations then the warnings are not present.

Comment by hpgisler [ 14/Nov/11 ]

Just for the record: Same problem here.

Two WAR's in an EAR
1. WAR JSF frontend
2. WAR REST frontend

If packaging only one of them into EAR, no problem; if packaging both inside EAR, Problem.

Comment by pettymt [ 10/Apr/12 ]

Confirmed on v3.1.1 (build 12)

30 WARs(each containing a REST service) in an EAR is a lot of warnings.

Comment by phealy [ 27/Mar/13 ]

I am getting a warning for every PimesFaces class every time I deploy (because I also have a Jersey app in my EAR). This does not reflect well on Glassfish.

Comment by nabizamani [ 13/Apr/13 ]

I have the same issue with GlassFish 3.1.2.2 (build 5) when deploying an EAR containing 2 wars and 1 ejb module (one of the wars contains restful web services).

Example:
WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
WARNING: WEB9052: Unable to load class com.demo.service.Order, reason: java.lang.ClassNotFoundException: com.demo.service.Order

RestExceptionCatcher is a @Provider and implements ExceptionMapper<Throwable>.
Order is a very simple REST service.

These warnings are very frustrating and I really want to get rid of them! But that would means I cannot use my EAR

Comment by yonatan [ 01/May/13 ]

If everything works properly, until the issue is resolved you can raise the logging level of that specific logger by adding javax.enterprise.system.container.web.org.glassfish.web.loader.level=SEVERE to the DOMAIN_HOME/config/logging.properties file.

Comment by andrey.v.markelov [ 07/May/13 ]

I have got the same trouble. Are you going to fix that?

Comment by Shing Wai Chan [ 25/Jun/13 ]

The given test case may need to update for GlassFish 4.

Comment by Daniel [ 25/Jun/13 ]

The web.xml for GF4 should use org.glassfish.jersey.servlet.ServletContainer API instead.

Comment by obfischer [ 17/Mar/14 ]

Is there a chance to get this fixed in the near future? Our monitoring reports all log messages with a log level above INFO. It is very annoying to warnings for a non-existent problem.

Comment by Philipp91 [ 21/Dec/14 ]

This issue should be prioritized higher. It may be a minor problem for people who's logs get flooded by these messages, but it is a major problem for people who can't use the REST services, which they deployed. The classes are not available, NoClassDefFound exceptions occur as follow-ups and the REST service is not available.

I use a simple JAR included in WEB-INF/lib.

Comment by lprimak [ 12/May/16 ]

This is now worked on and tracked by Payara team.
Issue https://github.com/payara/Payara/issues/374





[GLASSFISH-6582] Passing multiple VM arguments to JMS Service via Admin Console doesn't work Created: 19/Oct/08  Updated: 12/May/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ijuma Assignee: Anissa Lam
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,582

 Description   

This was reproduced with Glassfish v2.1 b54. I am not sure if it's the right
subcomponent so please reassign if necessary.

Steps to reproduce:

  • Create a standard cluster and login to the admin console.
  • If the cluster is running, stop it.
  • Go to the configuration of the cluster and then to Java Message Service.
  • Add -vmargs "-Xmx1024m -XX:MaxPermSize=128m" to Start Arguments.
  • Start cluster. It will fail to start.

The problem is the usage of quotes (which is how multiple vmargs are passed when
using the command-line). Some more information:

  • Using -vmargs -Xmx1024m works fine.
  • Using -vmargs -Xmx1024m -XX:MaxPermSize:128m does not work.

So, I could not find a workaround that would work for multiple vmargs through
the Admin Console web app.

I added some debugging output to imqbrokerd and for both cases that don't work
the vm arguments get split and the first part becomes a vm argument:

"-Xmx1024m or -Xmx1024m

and the second part becomes an application argument:

-XX:MaxPermSize=128m" or -XX:MaxPermSize=128m

For the quoted cause the command is obviously malformed, but for the case
without quotes it seems like the broker fails to start when it receives an
argument that it doesn't recognise.



 Comments   
Comment by ijuma [ 19/Oct/08 ]

"- Using -vmargs -Xmx1024m -XX:MaxPermSize:128m does not work."

Note that there's a typo here, I meant to say that:

  • Using -vmargs -Xmx1024m -XX:MaxPermSize=128m does not work.
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 kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

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 electricsam [ 22/Jan/14 ]

This happens in glassfish 4.0 as well

Comment by bbergquist [ 12/May/16 ]

I researching this I found

http://yangzb.iteye.com/blog/670387

In there I see that the "-vmarg" option is specified multiple times. This appears to work with Glassfish v2. Looking at arguments when I did -Dimq.jms.tcp.port=0 -vmargs -Xss512k -vmargs -Xms256m -vmargs -Xmx1024m

I see using pargs:

bash-3.2# pargs 29180
29180: /opt/canogaview/app/jdk/jdk1.8.0_40/bin/java -cp /opt/canogaview/glassfi sh/imq/
argv[0]: /opt/canogaview/app/jdk/jdk1.8.0_40/bin/java
argv[1]: -cp
argv[2]: /opt/canogaview/glassfish/imq/bin/../lib/imqbroker.jar:/opt/canogaview/ glassfish/imq/bin/../lib/imqutil.jar:/opt/canogaview/glassfish/imq/bin/../lib/js se.jar:/opt/canogaview/glassfish/imq/bin/../lib/jnet.jar:/opt/canogaview/glassfi sh/imq/bin/../lib/jcert.jar:/usr/lib/audit/Audit.jar:/opt/SUNWjdmk/5.1/lib/jdmkr t.jar:/opt/SUNWmfwk/lib/mfwk_instrum_tk.jar:/opt/SUNWhadb/4/lib/hadbjdbc4.jar:/o pt/SUNWjavadb/derby.jar:/usr/share/java/postgresql.jar:/opt/canogaview/glassfish /imq/bin/../lib/ext:/opt/canogaview/glassfish/imq/bin/../lib/ext
argv[3]: -Xms192m
argv[4]: -Xmx192m
argv[5]: -Xss128k
argv[6]: -XX:MaxGCPauseMillis=5000
argv[7]: -Xmx1024m
argv[8]: -Xms256m
argv[9]: -Xss512k
argv[10]: -Dimq.home=/opt/canogaview/glassfish/imq/bin/..
argv[11]: -Dimq.varhome=/opt/canogaview/glassfish/domains/domain1/imq
argv[12]: -Dimq.etchome=/opt/canogaview/glassfish/imq/bin/../etc
argv[13]: -Dimq.libhome=/opt/canogaview/glassfish/imq/bin/../lib
argv[14]: com.sun.messaging.jmq.jmsserver.Broker
argv[15]: -javahome
argv[16]: /opt/canogaview/app/jdk/jdk1.8.0_40
argv[17]: -Dimq.jms.tcp.port=0
argv[18]: -Dimq.cluster.nowaitForMasterBroker=true
argv[19]: -varhome
argv[20]: /opt/canogaview/glassfish/domains/domain1/imq
argv[21]: -startRmiRegistry
argv[22]: -rmiRegistryPort
argv[23]: 7776
argv[24]: -Dimq.imqcmd.user=admin
argv[25]: -passfile
argv[26]: /var/tmp/asmq4092636148720364648.tmp
argv[27]: -save
argv[28]: -name
argv[29]: imqbroker
argv[30]: -port
argv[31]: 7676
argv[32]: -bgnd
argv[33]: -silent
bash-3.2#

Using jvisualvm I do see that the max heap size is 1024m so it appears the later arguments override the earlier ones (ie. there are two -Xmx arguments being passed to the JVM).





[GLASSFISH-21542] Update jboss.logging Created: 11/May/16  Updated: 11/May/16

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

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


 Description   

Update jboss.logging to new 3.3 final to be consistent with latest hibernate ORM 5 requiremenet






[GLASSFISH-21541] Duplicate Class Error when Undeploying/Redeploying Web App Created: 11/May/16  Updated: 11/May/16

Status: Open
Project: glassfish
Component/s: admin_gui, jdbc
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

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

Java, Netbeans


Tags: ear, ejb, svnkit

 Description   

When I try to undeploy/redeploy my Web Application in the Glassfish Admin GUI I receive an error: java.lang.LinkageError: loader (instance of org/glassfish/web/loader/WebappClassLoader): attempted duplicate class definition for name: "org/glassfish/web/loader/JdbcLeakPrevention" (I will put the full stack trace at the very bottom). It may have something to do with SVNKit.

Exception while running a command
java.lang.LinkageError: loader (instance of org/glassfish/web/loader/WebappClassLoader): attempted duplicate class definition for name: "org/glassfish/web/loader/JdbcLeakPrevention"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.glassfish.web.loader.WebappClassLoader.clearReferencesJdbc(WebappClassLoader.java:2121)
at org.glassfish.web.loader.WebappClassLoader.clearReferences(WebappClassLoader.java:2056)
at org.glassfish.web.loader.WebappClassLoader.stop(WebappClassLoader.java:1960)
at org.glassfish.web.loader.WebappClassLoader.preDestroy(WebappClassLoader.java:1929)
at org.glassfish.internal.data.ApplicationInfo.clean(ApplicationInfo.java:465)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1071)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1099)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:412)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.deployment.admin.DeployCommand.handleRedeploy(DeployCommand.java:724)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:365)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309)
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:292)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:375)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Unknown Source)






[GLASSFISH-17449] Redeploy memory leak Created: 20/Oct/11  Updated: 04/May/16

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

Type: Bug Priority: Critical
Reporter: jelinj14 Assignee: russgold
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

windows 7, 64bit


Attachments: File keepalive-ref.tiff     File runtest.sh    
Tags: 3_1_2-exclude, 4_0_1-approved, 4_0_1-evangelists, memoryleak, orb-review, redeploy

 Description   

Redeployment causes memory leaks, using jmap and jhat can resolve for example: org.glassfish.javaee.full.deployment.EarClassLoader this class has instance each deploy and undeploy even if app is undeployed



 Comments   
Comment by Hong Zhang [ 21/Oct/11 ]

Assign to tim to take a look as he has done a lot of work of tracking down memory leak in 3.1.1.

Comment by Tim Quinn [ 21/Oct/11 ]

I was able to reproduce the problem.

I deployed a simple EAR (containing an EJB) 100 times, and saw 100 EarClassLoader instances remaining live, even after forcing GCs using jconsole.

(I will attach the simple shell script I used.)

Run the script, then browse to http://localhost:7000.

At least part of the problem seems to be caused by EJB monitoring retaining a reference to each StatelessSessionContainer, which in turn has a reference to EarClassLoader.

I am transferring this to the EJB team for investigation into cleaning up the references from monitoring when a container is retired.

Comment by Tim Quinn [ 21/Oct/11 ]

Attached runtest.sh for repeatedly deploying an app and monitoring memory usage.

Comment by jelinj14 [ 21/Oct/11 ]

When the application is bigger, (I have about 70 stateless session beans on EJB side) it causes big memory leak, every deploy is about 90MB leaks. But I'm not sure whether is it only EarClassLoader.
Thanks for resolve.

Comment by Tim Quinn [ 21/Oct/11 ]

There might well be other issues besides the one I found so far. Once that one is resolved we will look into this again for other leaks.

Comment by Cheng Fang [ 25/Oct/11 ]

Hi Tim, I tried your script with my test EAR on trunk build, and had different results. After finishing your script (100 deploy/undeploy), the result page shows only 3 instances of EarClassLoader.

I then tried deployed/undeploy one by one, and also shows any time after GC, the count is at most 3. The small number of left over instances could be related to annotation processing tasks.

Comment by Tim Quinn [ 25/Oct/11 ]

Cheng,

Perhaps something has changed between 3.1.1 and 4.0 (trunk) then. (I do not have a chance right now to try it myself on the trunk.)

Can whatever the change is be back-ported to 3.1.2? (I realize that requires understanding what change(s) are responsible for the better behavior in 4.0).

Comment by Cheng Fang [ 25/Oct/11 ]

Related to http://java.net/jira/browse/GLASSFISH-17468 (WebappClassLoader leak after undeployment)

Comment by Cheng Fang [ 03/Nov/11 ]

Once issue 17468 is resolved, it will help eliminate some causes of leaks.

Another source of leaks, when deploying apps with remote ejb, is from orb layer. An instance of com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive holds a reference to the EarClassLoader after undeploy.

Comment by Cheng Fang [ 03/Nov/11 ]

Attached a screen shot of reference from com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive

Comment by Cheng Fang [ 03/Nov/11 ]

re-assign to orb team to evaluate if we can reset the context class loader when creating the KeepAlive thread, to avoid inheriting the app class loader from the parent thread.

Comment by notabenem [ 02/Dec/13 ]

Just run into this on Glassfish 4: com.sun.corba.ee.impl.javax.rmi.CORBA.KeepAlive prevents the EAR from being garbage collected.
This pretty much eliminates the possibility of a reliable reloading mechanism (Continuous delivery)

Comment by electricsam [ 15/Jan/14 ]

I too can confirm that this is occurring in Glassfish 4.0

Comment by electricsam [ 30/Jan/14 ]

I've investigated a workaround until this is fixed. I found references to the current EarClassLoader (to be undeployed) in the following locations:

1. contextClassLoader in various threads
2. Direct references in ThreadLocals in varous threads
3. A contextClassLoader reference in the selector thread of the following field heirerchy: thread.orb.transportManager.selector
4. A contextClassLoader reference in the static resyncThread field of the com.sun.jts.CosTransactions.RecoveryManager class
5. Lots of indirect references in the ThreadLocals in the admin-listener threads

The below listed code will attempt to clean up items 1-3 when an app is undeployed (or redeployed).

For item 4, I was unable to get a reference to the RecoveryManager that had a contextClassLoader reference, but it is static and not as bad as a thread pool issue.

For item 5, the number of references and the object hierarchy depth made a workaround difficult. My best attempt was to limit the pool size for the admin-thread-pool to 5 with a min of 0 and a timeout of 0 (Although, I never see the pool shrink after it reaches capacity). There is still a leak here, but does not seem to grow past a certain point.

Hopefully this will help the GF dev that looks at this issue or any GF users with the same problem until then.

Bar.java
package test;

import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Singleton
@Startup
public abstract class ClassLoaderCleaner {

    private static final Logger logger = Logger.getLogger(ClassLoaderCleaner.class.getName());

    private ClassLoader loader = null;

    @PreDestroy
    protected void destroy() {
        try {
            loader = getClass().getClassLoader();
            cleanUp();
        } catch (Throwable e) {
            logger.log(Level.SEVERE, null, e);
        }
    }

    private void cleanUp() {
        Thread[] threads = getThreads();
        for (Thread thread : threads) {
            if (thread != null) {
                cleanContextClassLoader(thread);
                cleanOrb(thread);
                cleanThreadLocal(thread);

            }

        }
    }
    
        private Thread[] getThreads() {
        ThreadGroup rootGroup = Thread.currentThread().getThreadGroup();
        ThreadGroup parentGroup;
        while ((parentGroup = rootGroup.getParent()) != null) {
            rootGroup = parentGroup;
        }

        Thread[] threads = new Thread[rootGroup.activeCount()];
        while (rootGroup.enumerate(threads, true) == threads.length) {
            threads = new Thread[threads.length * 2];
        }
        return threads;
    }

    private boolean loaderRemovable(ClassLoader cl) {
        if (cl == null) {
            return false;
        }
        Object isDoneCalled = getObject(cl, "doneCalled");
        if (cl.getClass().getName().equals(loader.getClass().getName())
                && isDoneCalled instanceof Boolean && (Boolean) isDoneCalled) {
            return true;
        }
        return loader == cl;
    }

    private Field getField(Class clazz, String fieldName) {
        Field f = null;
        try {
            f = clazz.getDeclaredField(fieldName);
        } catch (NoSuchFieldException ex) {

        } catch (SecurityException ex) {
            logger.log(Level.WARNING, "Unable to get field " + fieldName + " on " + clazz.getName(), ex);
        }

        if (f == null) {
            Class parent = clazz.getSuperclass();
            if (parent != null) {
                f = getField(parent, fieldName);
            }
        }
        if (f != null) {
            f.setAccessible(true);
        }
        return f;
    }

    private Object getObject(Object instance, String fieldName) {
        Class clazz = instance.getClass();
        Field f = getField(clazz, fieldName);
        if (f != null) {
            try {
                return f.get(instance);
            } catch (IllegalArgumentException | IllegalAccessException ex) {
                logger.log(Level.WARNING, "Unable to get " + fieldName + " on " + clazz.getName(), ex);
            }
        }
        return null;
    }

    private void cleanContextClassLoader(Thread thread) {
        if (loaderRemovable(thread.getContextClassLoader())) {
            thread.setContextClassLoader(null);
            logger.log(Level.INFO, "Cleaned context classloader {0}", thread.getName());
        }
    }

    private void cleanOrb(Thread thread) {
        Object currentWork = getObject(thread, "currentWork");
        if (currentWork != null) {
            Object orb = getObject(currentWork, "orb");
            if (orb != null) {
                Object transportManager = getObject(orb, "transportManager");
                if (transportManager != null) {
                    Thread selector = (Thread) getObject(transportManager, "selector");
                    if (selector != null && loaderRemovable(selector.getContextClassLoader())) {
                        selector.setContextClassLoader(null);
                        logger.log(Level.INFO, "Cleaned orb ref {0}", thread.getName());
                    }
                }
            }
        }
    }

    private void removeThreadLocal(Object entry, Object threadLocals, Thread thread) {
        ThreadLocal threadLocal = (ThreadLocal) getObject(entry, "referent");
        if (threadLocal != null) {
            Class clazz = null;
            try {
                clazz = Class.forName("java.lang.ThreadLocal$ThreadLocalMap");
            } catch (ClassNotFoundException ex) {
                logger.log(Level.WARNING, null, ex);
            }
            if (clazz != null) {
                Method removeMethod = null;
                Method[] methods = clazz.getDeclaredMethods();
                if (methods != null) {
                    for (Method method : methods) {
                        if (method.getName().equals("remove")) {
                            removeMethod = method;
                            removeMethod.setAccessible(true);
                            break;
                        }
                    }
                }
                if (removeMethod != null) {
                    try {
                        removeMethod.invoke(threadLocals, threadLocal);
                        logger.log(Level.INFO, "Cleaned threadlocal {0}", thread.getName());
                    } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
                        logger.log(Level.SEVERE, null, ex);
                    }
                }

            }

        }
    }

    private void cleanThreadLocal(Thread thread) {
        Object threadLocals = getObject(thread, "threadLocals");
        if (threadLocals != null) {
            Object table = getObject(threadLocals, "table");
            if (table != null) {
                int size = Array.getLength(table);
                for (int i = 0; i < size; i++) {
                    Object entry = Array.get(table, i);
                    if (entry != null) {
                        Field valueField = getField(entry.getClass(), "value");
                        if (valueField != null) {
                            try {
                                Object value = valueField.get(entry);
                                if (value != null && value instanceof ClassLoader && loaderRemovable((ClassLoader) value)) {
                                    removeThreadLocal(entry, threadLocals, thread);
                                }
                            } catch (IllegalArgumentException | IllegalAccessException ex) {
                                logger.log(Level.WARNING, "Unable to get threadlocal value", ex);
                            }

                        }
                    }

                }
            }
        }
    }

}
Comment by Ed Bratt [ 20/May/14 ]

Assigned FYI ...

Comment by russgold [ 11/Jun/14 ]

If, as notabenem says, it is the KeepAlive objects preventing the garbage collection, that suggests that deploying the EAR is calling javax.rmi.CORBA.registerTarget, but undeploying is not calling javax.rmi/CORBA.unexportObject for each of the remote objects.

I'm going to look through the source to see where this is being called.

Comment by bebbo [ 04/May/16 ]

It's still present in glassfish 4.1.1.

I am using a ContextListener do null out references if contextDestroyed is invoked. For the ORB I am using

    private void fixORB() {
        try {
            // fix the ORB
            final Object globalPM = getMember(null, Class.forName("com.sun.corba.ee.spi.orb.ORB"), "globalPM");
            final Object weakCache = getMember(globalPM, "classToClassData");
            final Map<?, ?> classToClassData = (Map<?, ?>) getMember(weakCache, "map");

            LOG.info("clearing classToclassData map");
            classToClassData.clear();

        } catch (Exception ex) {
            LOG.error(ex, ex);
        }
    }

I am also patching way more locations to get a reliable undeployment/redeployment. See the full code of my ContextListener here: http://franke.ms/glassfish4_1_1_memory_leak.wiki





[GLASSFISH-21246] Grizzly thread pool waiting on LinkedTransferQueue hangs application Created: 03/Nov/14  Updated: 02/May/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1_b10
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: afcarv Assignee: oleksiys
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1_b13, JDK 1.7u67, Linux CentOS 3.10.48 x64



 Description   

Elaborating on the issue I posted on GLASSFISH-21211.

After some time running, http-listener-1 thread pool stops responding. Checking the logs, I see multiple messages like the one below:

[2014-11-03T18:50:47.114+0000] [glassfish 4.1] [SEVERE] [] [org.glassfish.grizzly.nio.SelectorRunner] [tid: _ThreadID=60 _ThreadName=http-listener-1-kernel(1) SelectorRunner] [timeMillis: 1415040647114] [levelValue: 1000] [[
  doSelect exception
java.util.concurrent.RejectedExecutionException: The thread pool's task queue is full, limit: 4096
        at org.glassfish.grizzly.threadpool.AbstractThreadPool.onTaskQueueOverflow(AbstractThreadPool.java:464)
        at org.glassfish.grizzly.threadpool.QueueLimitedThreadPool.execute(QueueLimitedThreadPool.java:81)
        at org.glassfish.grizzly.threadpool.GrizzlyExecutorService.execute(GrizzlyExecutorService.java:161)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:100)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
        at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
        at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
        at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
        at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
        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:744)
]]

I then took a thread dump which shows all threads in http-listener-1 in a state like the below:

"http-listener-1(31)" daemon prio=10 tid=0x00007ff19422b000 nid=0x6c61 waiting on condition [0x00007ff1f6eed000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006036fd360> (a java.util.concurrent.LinkedTransferQueue)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:735)
        at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:644)
        at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1137)
        at org.glassfish.grizzly.threadpool.FixedThreadPool$BasicWorker.getTask(FixedThreadPool.java:105)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:557)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
        at java.lang.Thread.run(Thread.java:744)

They seem to be waiting on LinkedTransferQueue take() method, which appears to be not responding (waiting for some item to arrive in the queue?). I also took a memory dump that I can look into if someone points me in the right direction.

Thought this could be related to GRIZZLY-1711 but after applying the latest version (2.3.17-SNAPSHOT) this behavior is still happening.

Let me know if I should get more data - thanks!



 Comments   
Comment by davidwinters1980 [ 03/Nov/14 ]

This appears to be occurring as a result of the http thread pool reaching its limit of 4096.

As per the default domain.xml setting:

<thread-pools>
<thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
<thread-pool name="http-thread-pool" max-queue-size="4096"></thread-pool>
<thread-pool name="thread-pool-1" max-thread-pool-size="200"/>
</thread-pools>

You could configure this to -1 or unlimited but this will likely lead to other issues such as out of memory etc

It would appear as though tasks are being added to this queue faster than the tasks can be processed. I would investigate why this occurring? If you could take a number of thread dumps over a period of time whereby we capture this issue occurring that would be useful.

Furthermore, it maybe worth increasing the value of your http request processing threads as this will allow more tasks to be handled concurrently off the http thread task queue and so it may reach the 4096 limit so quickly. What is the current value of the number of http request processing threads??

The issue you have here is very dependent on the number of http requests being pushed to the http task pool and how quickly these requests are being handled so appropriate tuning of the http parameters may resolve this issue. If this fails then looking at the state of all threads running over a period of time should give you a hint as to why requests are taking so long to process.

Comment by afcarv [ 03/Nov/14 ]

I don't think it's a configuration issue as the environment is able to handle much heavier loads - it may be due to specific and temporary environmental reasons (network latency, database slowdown, etc) but you'd think it would resume work as soon as this is normalized. This does not happen (waited for some hours to be sure), even if the consumer is stopped and there's no inbound traffic anymore - the only way to bring it back online is with a server/cluster restart. I did notice a lot of connections in the CLOSE_WAIT state in the server, though.

Haven't tried to raise the queue limit or remove it yet, but I suspect it would only delay the occurrence or eventually reach an OOM error.

I see no obvious reason for this looking at the thread pool dump, but will post it later for analysis. Thanks!

Comment by afcarv [ 04/Nov/14 ]

Please find attached the full thread dump and the server log file. The dump was taken about 30 minutes after the issue manifested itself - you can see all threads in the http-listener-1-kernel pool reach the queue limit and stop responding. http-thread-pool contains 32 threads; there are 8 acceptor threads.

Interestingly, http-listener-2 (SSL) continues to respond normally. http-listener-1 hanged and required a server restart. The configuration is a 2 instance cluster with a nginx load balancer in front; there are Jersey applications deployed serving RESTful webservices. The configuration can handle about 5x the average load on the server - no increased throughput was observed leading to the issue, which persisted after stopping all inbound traffic.

I will schedule a cron job to take a thread dump every 5 minutes to check on any odd behavior leading to the issue - thanks!

Thread dump: https://www.dropbox.com/s/qejdzhwejlv1zzp/threadump.txt?dl=0
Server log: https://www.dropbox.com/s/rbu24cep9y25aol/server.log?dl=0

Comment by afcarv [ 04/Nov/14 ]

Some more info I got from the memory dump -

I see lots of instances of TCPNIOConnection (1500+) in what appears to be a closing state; as the latest snapshot was applied I can see these with a CloseReason of "LOCALLY". May explain the connections in the CLOSE_WAIT state I saw? Is it possible that nginx closed the socket before a FIN packet could be sent from the server, and now it is not able to end the connection properly? Not sure if this could be just a consequence of some other issue, though.

Comment by oleksiys [ 06/Nov/14 ]

Which Grizzly version is used in 4.1_b10?

Thank you.

Comment by afcarv [ 06/Nov/14 ]

We're using b13 (couldn't find the tag for it so I selected the closest), but I believe it's the same version - 2.3.15.

Currently, 2.3.17-SNAPSHOT is applied.

By the way - we found out that what triggers this behavior is a DB performance degradation, causing the requests to queue and eventually reach the limit. No additional info on why queue isn't being reduced, though.

Comment by davidwinters1980 [ 06/Nov/14 ]

Could you take a number of thread dumps say every 5 minutes so that we can compare the different thread dump files leading up to the hang? Also could you send us on the contents of the <transports> which should contain the different tcp parameters used by Grizzly.

<transports>
<transport byte-buffer-type="HEAP" display-configuration="true" name="tcp" .....></transport>
</transports>

Useful to know db degradation issues are causing requests in the queue to fill up. It might be useful to get some debug grizzly logging on here: org.glassfish.grizzly.level=FINEST

Thanks.

Comment by afcarv [ 10/Nov/14 ]

I had some monitoring in place but we've been focusing on fixing the db degradation so the issue won't be triggered - so far we've been successful, so it looks unlikely I'll be able to collect more data in the production system.

What I'm going to try next is to create a sample application and configuration that will be able to recreate the issue - doesn't look too hard; just a sample RESTful webservice that performs a db query that has an artificial delay in response, small db connection pool and a sample JMeter test script with http requests that will timeout before the app has a chance to respond. Should replicate the conditions pretty closely (don't know if nginx in front plays a role in this or not, so will try without it first).

Will report on any news, thanks!

Comment by oleksiys [ 10/Nov/14 ]

pls. try to patch GFv4.1 with this patch [1].
I need server.log output message(s) like:
"The queue is overflowed. queuePermits=......."

Thank you.

[1] https://dl.dropboxusercontent.com/u/7319744/glassfish-21246/nucleus-grizzly-all.jar

Comment by afcarv [ 22/Oct/15 ]

Hi - I've been looking into this again. We still get a non-responsive cluster from time to time, and it's always due to some external resource that cause the task queue to overfill; I've seen it happen due to a DB slowdown (as I've reported before) and also due to an issue with ActiveMQ (slow response).

Recreating this in a test environment has been proving to be quite tricky, but it appears I have devised a somewhat reliable way to do it using the scenario I've described before and using a test thread pool with at least twice the number of the task queue maximum capacity to generate requests to the application server.

I've successfully triggered this issue in GFv4.0, GFv4.1 and GFv4.1.1.

I will apply your patch next and report back if I get any results - thanks!

Comment by afcarv [ 22/Oct/15 ]

Please find server.log file below:

https://dl.dropboxusercontent.com/u/106573849/GF-21246/server.log

Method "testDAOMethod()" of class "TestDAOBean" calls a stored procedure that waits for 1 minute before giving a response. Ran a test script that kept calling a RESTful endpoint which invoked this method; massive amount of requests caused the http-listener-1 task queue to quickly overfill and stop responding. At this point, I stopped the test script by killing the process.

About 1 hour later, http-listener-1 is still hung. I then made a test call to the SSL endpoint which is handled by http-listener-2; this request went through cleanly, as can also be seen in the log file.

Let me know if you want me to run additional tests or fetch additional information. Thanks!

Comment by ruVooDoo [ 12/Nov/15 ]

Hello, our prod env show the same pattern...
"http-listener-1(119)" daemon prio=10 tid=0x00007f6409038000 nid=0x27e2 waiting on condition [0x00007f62f62e1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x000000067d016e20> (a java.util.concurrent.LinkedTransferQueue)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:735)
    at java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:644)
    at java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1137)
    at org.glassfish.grizzly.threadpool.FixedThreadPool$BasicWorker.getTask(FixedThreadPool.java:105)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:556)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
    at java.lang.Thread.run(Thread.java:724)

Thats very wierd, becauseour app working perfect for month`s on GF 4.0, but now it`s hanging... We did not change anything in the app.

Could you please provide a fix?

Comment by oleksiys [ 12/Nov/15 ]

@ruVooDoo the stacktrace you provided doesn't mean GF hangs, it's just a thread waiting for a task to be assigned.
The problem can be somewhere else.
Please provide full stacktrace (all threads) snapshot at the time you see the problem.

Comment by ruVooDoo [ 12/Nov/15 ]

https://www.dropbox.com/s/9ur7963sf3tb2ja/gso_hung_27757.txt?dl=0
We are using GlassFish Server Open Source Edition 4.0 (build 89)

Comment by mmora [ 12/Apr/16 ]

Hi,
I have the same problem as you, I am using GlassFish 4.1.1 with JDK 8u77 and after a while operating the http-thread-pool stops responding, returning blank pages. It happens more often the more use the application.
How I can fix it?

Comment by oleksiys [ 02/May/16 ]

@ ruVooDoo from the stacktrace you shared - many threads are blocked in your WS/EJB/MQ code, I don't think it has anything to do with LinkedTransferQueue.

@mmora is it a blank with an HTTP response code, or connection is getting broken/closed? Please share the stacktrace dump when this happens.





[GLASSFISH-20850] classloader favors modules/guava.jar over guava library in the ear Created: 11/Oct/13  Updated: 01/May/16

Status: Open
Project: glassfish
Component/s: cdi, classloader
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Andres Assignee: Romain Grécourt
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JERSEY-1884 Jersey 2.0 Maven artiifact depends on... Closed

 Description   

I tried to upgrad the guava library in our application to version 15-0. When I deploy the application on glassfish 4.0, I see the following Exception:

Caused by: java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
at MyClient.buildClient(MyClient.java:159)
at MyClient.initClient(MyClient.java:143)
at MyClient.<init>(MyClient.java:74)
at MyClient.<init>(MyClient.java:62)
at MyClientFactory.createClient(MyClientFactory.java:12)
at MyClientProducer.createClient(MyClientProducer.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)

To verify where the class is loaded from, I added:
URL resource = this.getClass().getClassLoader()
.getResource(Stopwatch.class.getName().replaceAll("
.", "/") + ".class");
LOGGER.info("URL for Stopwatch:" + resource.toString());
which gives me
URL for Stopwatch:bundle://108.0:1/com/google/common/base/Stopwatch.class

MyClient, MyClientFactory and MyClientProducer are all inside an ejb jar file.
guava-15.0.jar is in a lib folder next to the ejb jar (with lib/guava-15.0.jar in the ear META-INF/MANIFEST.MF Class-Path)

All other libraries there can be found. It just seems, that the weld classloader favors the guava.jar bundled with glassfish 4 over the one I provide for the application. I would expect the classloader to give stuff deployed with the ear a higher priority.



 Comments   
Comment by Thomas Andres [ 11/Oct/13 ]

BTW: Deploying the same ear on glassfish 3.1.2.2 works. The guava class is loaded correctly from the jar inside my ear.

(with a patched beans.xml, but that's another story...)

Comment by Joe Di Pol [ 11/Oct/13 ]

When we have had similar problems in the past the issue was that an OSGi module was exporting packages without any mechanism to prevent them from being found by the application's hierarchy of class loaders.

The solution was to add mandatory OSGi attributes to the exported packages that must be declared by any other module that wanted to import the packages. This prevents the API/Packages from leaking into the application space. I looked at guava.jar and it does not appear to do this – so maybe this is the problem.

For some additional information on this issue see the following:

https://java.net/jira/browse/GLASSFISH-5385
https://java.net/jira/browse/GLASSFISH-18176

Comment by simon.schlachter [ 31/Oct/13 ]

Exactly the same problem here.

Comment by simon.schlachter [ 01/Nov/13 ]

We were able to workaround the problem, by "patching" the manifests (MANIFEST.MF) of the included guava.jar file and its dependencies.

in guava we added ;mandatory:=password;password="GlassFish to all export-statements.

In the dependent modules we added ;password="GlassFish" to all import statements concerning com.google.common.*

The list of modules we had to patch is

  • jersey-bean-validation.jar
  • jersey-client.jar
  • jersey-common.jar
  • jersey-container-servlet-core.jar
  • jersey-container-servlet.jar
  • jersey-gf-cdi.jar
  • jersey-media-moxy.jar
  • jersey-mvc-jsp.jar
  • jersey-mvc.jar
  • jersey-server.jar

The effect of this change is that guava.jar-classes do no longer leak into the class path of our deployed application. This solves the guava-version-problem for us. The root problem, however, is not solved: Glassfish still favors its own classpath instead of that of the deployed application.

(The Idea for this workaround is originally from GLASSFISH-5385)

Comment by hsaqallah [ 14/Feb/14 ]

Patching GF4's files is error-prone and very impractical for a sane development/test/stage/prod environment. There should have been an easier fix. Too bad. Time to switch to Tomcat 7.

Comment by gcruscoe [ 21/Jul/14 ]

#fishcat

Testing glassfish 4.0.1 b08. I am having this issue with the moduels/guava.jar being used over the guava I have in my .ear project. It is preventing migration from 3.1.2.2 to 4.0.1. This seems like a critical issue that should be fixed for b09. It makes it impossible to even test the rest of the system if your app is using a different / incompatible version of guava.

Also this links a bug that says Jersey is going to fix theirs and when it is incorporated it will fix this. I think that version of Jersey has been incorporated but this issue is still there.

Comment by cristim1979 [ 20/Aug/14 ]

We also encountered the same defect with our application which uses Guava 17.0, and which used to work well on Glassfish 3.1.2.2.
But on Glassfish 4.0 it crashed at deploy; to fix it, we came in the end to same workaround like described by simon.schlachter above - patch 11 of the jars in \modules\ folder. But this is very impractical for a clean/official upgrade to 4.0.

Comment by Thomas Andres [ 22/Aug/14 ]

I just did a quick test with our application on glassfish 4.1 (currently on glassfish 4.0)
Most work out of the box without any changes. Compliments on that!

However I noticed this issue got a bit worse, since v4.1 now has guava v13 bundled which is a downgrade from v14 in GF4.0. (WTF??? what's the reason for this?)
I hope you can fix this for 4.1 release.

Comment by Romain Grécourt [ 22/Aug/14 ]

guava is a dependency for both weld and jersey.
Jersey now shadows what it needs, what remains is weld's dependency.

It's too late to be included in 4.1 release (it will go in the next one).
The workaround is the same, but only involves guava + weld jars.

Comment by Thomas Andres [ 22/Aug/14 ]

But what's the reason to downgrade the guava libray? This will cause additional problem to people who now use guvava v14 to avoid this problem.

Comment by Romain Grécourt [ 22/Aug/14 ]

In v4, guava was provided twice: guava.jar (for jersey) and weld-osgi-bundle.jar: both are using different versions.
In v4.1 Jersey has removed its guava dependency (it's now shadowed).

As of weld 2.1.0.Beta2 guava is not part of weld-osgi-bundle.jar, but just an OSGi dependency.
GlassFish 4.1 bundles weld 2.2.2.Final, that's why we are providing a different guava version than what was in 4.0.

Comment by Thomas Andres [ 22/Aug/14 ]

Thanks for the explanation. Looks strange when you look just at the jar, but makes sense like this.
I just tried replacing guava.jar with the version provided with v4 and that works fine so far. You might wanna consider doing that if you can't fix this issue, since that makes at least the transition from v4 to v4.1 a bit smoother.

Comment by lprimak [ 26/Aug/14 ]

I just put guava-17.jar into Glassfish modules/ directory ant it worked.
Had to delete osgi-cache/* from the domain (but only once after the patch)

Is this not simpler than the other patch in the comments above?

Comment by Romain Grécourt [ 26/Aug/14 ]

This is a server wide workaround (you may want to test a few CDI things though).
The one described above (password=GlassFish) applies for applications (i.e WEB-INF/lib).

Comment by vps [ 24/Feb/15 ]

Still same in 4.1.b13.

I ended up using a custom class loader to work around this.
The code is below, if anyone's interested; obviously it's only meant to solve my particular problem, but can be easily changed to prevent delegation for more classes.
When I started, I tried to prevent delegation of everything, but quickly run into problems with the fact that I package (for some reason) too much API classes (JTA was the first that hit me). Even passing java* packages didn't help, as there was some problem with JSF classes, exacerbated by the fact that I had JSF that was older than what's in GF. It was quicker for me to just limit the delegation to the package prefix that I care about, then to clean up my EAR libraries (I'm sure most of the stuff that I package is my fault, and shouldn't be done that way)

I think the glassfish-application.xml should have a section that describes what should and should not be delegated, based on list of RegEx of class names. Then the EAR library classloader should use that list to determine what to delegate and what to not - this will give flexibility to solve virtually any use cases. I recall WebLogic has something that does that. In all cases, it's reasonable to expect that both GF will need to carry some libraries, and the application carry the same, and they may be in severe conflict, and that may be by design.

EarLibClassLoader.java
/*
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
 *
 * Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
 *
 * The contents of this file are subject to the terms of either the GNU
 * General Public License Version 2 only ("GPL") or the Common Development
 * and Distribution License("CDDL") (collectively, the "License").  You
 * may not use this file except in compliance with the License.  You can
 * obtain a copy of the License at
 * https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
 * or packager/legal/LICENSE.txt.  See the License for the specific
 * language governing permissions and limitations under the License.
 *
 * When distributing the software, include this License Header Notice in each
 * file and include the License file at packager/legal/LICENSE.txt.
 *
 * GPL Classpath Exception:
 * Oracle designates this particular file as subject to the "Classpath"
 * exception as provided by Oracle in the GPL Version 2 section of the License
 * file that accompanied this code.
 *
 * Modifications:
 * If applicable, add the following below the License Header, with the fields
 * enclosed by brackets [] replaced by your own identifying information:
 * "Portions Copyright [year] [name of copyright owner]"
 *
 * Contributor(s):
 * If you wish your version of this file to be governed by only the CDDL or
 * only the GPL Version 2, indicate your decision by adding "[Contributor]
 * elects to include this software in this distribution under the [CDDL or GPL
 * Version 2] license."  If you don't indicate a single choice of license, a
 * recipient has the option to distribute your version of this file under
 * either the CDDL, the GPL Version 2 or to extend the choice of license to
 * its licensees as provided above.  However, if you add GPL Version 2 code
 * and therefore, elected the GPL Version 2 license, then the option applies
 * only if the new code is made subject to such option by the copyright
 * holder.
 */

package org.glassfish.javaee.full.deployment;

import java.net.URL;
import com.sun.enterprise.loader.ASURLClassLoader;
//import com.sun.enterprise.util.CULoggerInfo;
import java.util.logging.Logger;
import java.util.logging.LogManager;
import java.util.logging.Level;
import java.util.regex.*;
import java.util.*;

/**
 * Classloader that is responsible to load the ear libraries (lib/*.jar etc)
 *
 */
public class EarLibClassLoader extends ASURLClassLoader
{

    // private static final Logger _logger=CULoggerInfo.getLogger();
    // private static final Logger _logger=LogManager.getLogManager().getLogger("earcl");
    private static final Logger _logger=Logger.getLogger("earcl");

    private static final Collection<Pattern> preventDelegate =
        new ArrayList<Pattern>();

    static {
        preventDelegate.add(Pattern.compile("^com\\.google\\..*$"));
    }

    public EarLibClassLoader(URL[] urls, ClassLoader classLoader) {
        super(classLoader); 

        for (URL url : urls) {
            addURL(url);
        }
    }

    @Override
    protected String getClassLoaderName() {
        return "EarLibClassLoader";
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            Class<?> c = super.findClass(name);
            // _logger.log(Level.INFO, "findClass() called for "+name + "->found");
            return c;
        } catch (ClassNotFoundException e) {
            // _logger.log(Level.INFO, "findClass() called for "+name + "->NOT FOUND");
            throw e;
        }
    }


    @Override
    protected Class<?> loadClass(String name, boolean r) throws ClassNotFoundException {

        // let's make it non-delegating!

        // logger.log(Level.INFO, "EAR loading "+name+", resolve:"+r);

        boolean matched = false;
        for (Pattern p : preventDelegate) {
            Matcher m = p.matcher(name);
            if (m.matches()) {
                matched = true;
                break;
            }
        }

        if (!matched) {
            try {
                Class<?> c = super.loadClass(name,r);
                // logger.log(Level.INFO, "not matched "+name+", delegating -> found");
                return c;
            } catch (ClassNotFoundException e) {
                // logger.log(Level.INFO, "not matched "+name+", delegating -> NOT FOUND");
                throw e;
            }
        }
    
        synchronized (getClassLoadingLock(name)) {

            ClassNotFoundException toThrow = null;

            Class<?> c = findLoadedClass(name);
            if (c == null) {
            
                try {
                    c = findClass(name);
                    // logger.log(Level.INFO, "-> self found class"+name+", will return.");
                } catch (ClassNotFoundException ne) {
                    toThrow = ne;
                    // _logger.log(Level.INFO, "-> self could not find class "+name);
                }
            
            }

            if (c == null) {
                ClassLoader parent = getParent();
                if (parent == null) {
                    // _logger.log(Level.INFO, "-> no parent, throwing CNF for "+name);
                    throw toThrow;
                }
                try {
                    c = parent.loadClass(name);
                    // _logger.log(Level.INFO, "-> parent loaded class "+name);
                } catch (ClassNotFoundException ignored) {
                    // _logger.log(Level.INFO, "-> parent could not load class, throwing CNF for "+name);
                    throw toThrow;
                }
            } else {
                // _logger.log(Level.INFO, "-> self class "+name+" is already loaded");
            }

            if (r) {
                // _logger.log(Level.INFO, "-> resolving class");
                resolveClass(c);
            }

            return c;

        }
    
    }

}

Applying this to GF:

# make sure JDK 1.8 is used
# note that the output is written to /tmp/bout
mkdir -p /tmp/bout
/opt/java/jdk1.8/bin/javac -d /tmp/bout/ -cp ~/soft/glassfish4/glassfish/lib/appserv-rt.jar: EarLibClassLoader.java
# now, we need to update the .jar file that contains that class
# it's expected that GlassFish distribution is unzipped somewhere
# change to glassfish home directory before running the next lines
cd glassfish/modules
# let's unzip existing .jar that needs to be updated
mkdir -p _z
cd _z
unzip ../deployment-javaee-full.jar
# copy the modified .class
# note that current directory is _z where we unpacked the existing .jar
cp /tmp/bout/org/glassfish/javaee/full/deployment/EarLibClassLoader.class org/glassfish/javaee/full/deployment/EarLibClassLoader.class
# let's update the .jar file. Note that the jar command is crazy, but we must preserve the manifest!
/opt/java/jdk1.8/bin/jar uvfmM  ../deployment-javaee-full.jar META-INF/MANIFEST.MF .
# now, if necessary, we can update the distribution
# change to the directory that contains the glassfish4 directory as was extracted from .zip file
cd /opt/soft
zip -u glassfish-4.1.zip glassfish4/glassfish/modules/deployment-javaee-full.jar
Comment by lprimak [ 24/Feb/15 ]

How do I apply the above code in my Glassfish installation?

Comment by lprimak [ 25/Feb/15 ]

Ah, this is unfortunate. It requires patching the server itself.
This needs to be fixed by GlassFish team IMHO.

Comment by kithouna [ 02/Jun/15 ]

Simple workaround: I added <class-loader delegate="false"/> to glassfish-web.xml, now Guava is loaded from the WAR.

Comment by lprimak [ 02/Jun/15 ]

Does this work for ear files?

Comment by gabor.varga [ 04/Jun/15 ]

If you set <class-loader delegate="false"/>, JNDI lookups (e.g. with InitialContext.lookup() will fail.

Comment by lprimak [ 07/Sep/15 ]

Just to recap the current status of this issue:
JARs in GF modules/ directory erroneously take precedence of JARs in user specified applications
Examples:

  • guava.jar
  • jackson-*.jar
  • Others?

Here are the current observations:

  •  <class-loader delegate="false"/> 

    works correctly for, but only for WAR files that have guava.jar and other JARs in it's lib/ directory

  • does NOT work correctly if updated JARs are in domain/lib directory
  • vps's patch above works correctly, but only for skinny WARs or EJB-JARs inside EAR files
  • simon.schlachter's patch above was not tested due to it's implementation complexity
Comment by lprimak [ 17/Apr/16 ]

Payara team is actively working to fix this issue

Comment by Thomas Andres [ 18/Apr/16 ]

Thanks for the information. Is there a payara issue to track for news regarding this issue?

Comment by lprimak [ 18/Apr/16 ]

Yes, Thomas,

https://github.com/payara/Payara/issues/419
https://github.com/payara/Payara/issues/431

Comment by lprimak [ 01/May/16 ]

This issue is now fixed in Payara, should be out with the next release (.162)
The functionality is enabled globally with system property:

fish.payara.classloading.delegate=false

similar to configuration in glassfish-web.xml

Also, the functionality can be enabled in individual EAR files with the entry:

<classloading-delegate>false</classloading-delegate>

in glassfish-application.xml





[GLASSFISH-21540] Cannot use non-default password in truststore from remote client (IIOP SSL) Created: 29/Apr/16  Updated: 29/Apr/16

Status: Open
Project: glassfish
Component/s: jms, security
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: epms.devteam Assignee: David Zhao
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits and Linux



 Description   

I'm trying to access a Message Queue configured in GlassFish, with SSL, from a standalone client, but I can only make it work if I use the default password (changeit) on my trustStore. I'm always getting "Keystore was tampered with, or password was incorrect" if I try to use a different password.
If I set the Trust Store with the default password and use the following property with a wrong value, it still works "-Djavax.net.ssl.trustStorePassword=<wrong value>", which confirms that it that it completely ignores this setting.
After digging a little deeper, I've detected a behavior that seems a bug. Looking at the stacktrace, one of the first methods being invoked is initJKS() from com.sun.enterprise.security.ssl.impl.SecuritySupportImpl. With the help of javassist, I realized that the following section is being invoked:

if (masterPasswordHelper == null && Globals.getDefaultHabitat() != null)

{ masterPasswordHelper = Globals.getDefaultHabitat().getByType(MasterPasswordImpl.class); }

if (masterPasswordHelper instanceof MasterPasswordImpl)

{ keyStorePass = masterPasswordHelper.getMasterPassword(); trustStorePass = keyStorePass; }

Causing the bypass of the next set of instructions:

if (keyStorePass == null)

{ keyStorePass = System.getProperty(KEYSTORE_PASS_PROP, DEFAULT_KEYSTORE_PASS).toCharArray(); trustStorePass = System.getProperty(TRUSTSTORE_PASS_PROP, DEFAULT_TRUSTSTORE_PASS).toCharArray(); }

And, as a consequence, to ignore the user defined property javax.net.ssl.trustStorePassword.

Why is Globals.getDefaultHabitat() returning a non null value? Why isn't a user defined property overriding any previous setting?

NOTE: Due to PCI compliance requisites, I do need to set a password on the trustStore.






[GLASSFISH-21340] CDI scope annotation on @Provider makes @NameBinding ignored Created: 26/Mar/15  Updated: 29/Apr/16

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: m-radzikowski Assignee: Marek Potociar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1.8.0_40



 Description   

Using CDI scope annotation (e.g. @javax.enterprise.context.RequestScoped) makes annotations with @javax.ws.rs.NameBinding ignored in @javax.ws.rs.ext.Provider.

Sample code:

EnableScopedFilter
@Retention(RUNTIME)
@NameBinding
public @interface EnableScopedFilter {	
}
ScopedFilter
@Provider
@EnableScopedFilter
@RequestScoped
public class ScopedFilter implements ContainerRequestFilter {
	@Override
	public void filter(ContainerRequestContext requestContext) throws IOException {
		System.out.println("Scoped filter triggered on path: " + requestContext.getUriInfo().getPath());
	}
}

This filter is executed on every REST method, not only on these annotated with @EnableScopedFilter. If @RequestScoped is removed everything is ok.

CDI scope annotation is needed is bean-discovery-mode in beans.xml is set to "annotation" and filter needs to @Inject some resources.



 Comments   
Comment by jjsnyder83 [ 30/Mar/15 ]

I don't think this is a CDI issue. I think it is a jax-rs issue. Assigning to jax-rs.

Comment by HeinBloed [ 29/Apr/16 ]

Was this bug resolved in a newer Jersey version? I couldn't find any other information about it. Also facing it with GF 4.1.





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

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

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

postgresql-9.3-1101.jdbc4.jar



 Description   

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

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

[2014-06-26T20:53:40.678+0400] [glassfish 4.0] [WARNING] [jts.unexpected_error_occurred_twopc_rollback] [javax.enterprise.system.core.transaction.com.sun.jts.jtsxa] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620678] [levelValue: 900] [[
  JTS5068: Unexpected error occurred in rollback
org.postgresql.xa.PGXAException: Error rolling back prepared transaction
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:418)
	at com.sun.gjc.spi.XAResourceImpl.rollback(XAResourceImpl.java:195)
	at com.sun.jts.jta.TransactionState._rollback(TransactionState.java:202)
	at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:180)
	at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:333)
	at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1040)
	at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:391)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:122)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:744)
Caused by: org.postgresql.util.PSQLException: ERROR: prepared transaction with identifier "4871251_UhsAAL/TCNl0ZXN0LmJ0Zi5sb2NhbCxzZXJ2ZXIsUDEwMA==_dGVzdC5idGYubG9jYWwsc2VydmVyLFAzNzAwLAA=" does not exist
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:559)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:331)
	at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:406)
	... 73 more
]]

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

[2014-06-26T20:53:40.694+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620694] [levelValue: 900] [[
  
javax.ejb.EJBException: Transaction aborted
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:725)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:744)
Caused by: javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	... 61 more
]]

[2014-06-26T20:53:40.697+0400] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=35 _ThreadName=http-listener-1(10)] [timeMillis: 1403801620697] [levelValue: 900] [[
  StandardWrapperValve[com.btf.soesg.api.rest.App]: Servlet.service() for servlet com.btf.soesg.api.rest.App threw exception
javax.transaction.RollbackException
	at com.sun.jts.jta.TransactionImpl.commit(TransactionImpl.java:127)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:509)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
	at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy337.updateIssue(Unknown Source)
	at com.btf.soesg.api.__EJB31_Generated__CommandEndpoint__Intf____Bean__.updateIssue(Unknown Source)
	at com.btf.soesg.api.rest.Endpoint.updateIssue(Endpoint.java:219)
	at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:354)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:744)
]]


 Comments   
Comment by MarioLovisi [ 27/Apr/16 ]

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

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





[GLASSFISH-21538] Admin Console shows blank page after some configuration changes Created: 21/Apr/16  Updated: 21/Apr/16

Status: Open
Project: glassfish
Component/s: admin, admin_gui
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: tmpsa Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14



 Description   

After certain changes in the configuration, and a restart of GF, the Admin Console goes bananas. It prompts for login all right, but then responds with a blank page (empty HTML page).

Any of the following two steps in my attempt to install and configure 4.1.1 will reproducibly cause this breakage on my server. There does not seem to be any significant entries in server.log, unfortunately.

+ Configurations > server-config > Security

  • In 'Default Realm' select admin-realm and click "Save"
  • Restart Glassfish to verify that it still works.

+ Use default principal-to-role mapping, no need for a sun-web.xml
In Configurations > server-config > Security

  • Check the box "Default Principal to Role Mapping"
  • Click "Save"
  • Restart Glassfish to verify that it still works.

I will happily assist with further details if necessary.
This problem is a show-stopper; it prevents me from upgrading from 3.1.2.2 to 4.1.1!



 Comments   
Comment by tmpsa [ 21/Apr/16 ]

Btw: Java version 1.8.0_74





[GLASSFISH-21532] com.sun.jts.CosTransactions.GlobalTID breaks the equals/hashCode contract Created: 09/Apr/16  Updated: 19/Apr/16

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

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


 Description   

Whilst testing JTS transaction propagation between glassfish and other application servers I hit a recovery problem (which I reported via https://java.net/projects/glassfish/lists/dev/archive/2016-04/message/0) caused by implementation of the GlobalTID.hashCode() method. It is possible to create to GlobalTID instances with are the same according to the equals method but have different hash codes. A simple test showing the problem is:

GlobalTID Test
import org.omg.CosTransactions.otid_t;
import com.sun.jts.CosTransactions.GlobalTID;

public class X {
    public static void main(String[] args) {
        test();
    }

    public static void test() {
        otid_t otid1 = toOtid("xyz".getBytes(), "a".getBytes());
        otid_t otid2 = toOtid("xyz".getBytes(), "".getBytes());

        GlobalTID tid1 = new GlobalTID(otid1);
        GlobalTID tid2 = new GlobalTID(otid2);

        if (!tid1.equals(tid2))
            throw new AssertionError("GlobalTIDs should be equal");

        // equal objects must have the same hashCode
        if (tid1.hashCode() != tid2.hashCode())
            throw new AssertionError("equal GlobalTID objects should have the same hash code");
    }

    private static otid_t toOtid(byte[] gtid, byte[] bqual) {
        otid_t otid = new otid_t();

        otid.formatID = 0;
        otid.tid = new byte[gtid.length + bqual.length];
        otid.bqual_length = bqual.length;

        /*
         * gtrid must be first then immediately followed by bqual.
         * bqual must be between 1 and 64 bytes if for XA.
         */

        System.arraycopy(gtid, 0, otid.tid, 0, gtid.length);
        System.arraycopy(bqual, 0, otid.tid, gtid.length, bqual.length);

        return otid;
    }
}

To compile and run the example put the following three jars on the classpath:

export CLASSPATH=.:glassfish-corba-omgapi.jar:jts.jar:common-util.jar






[GLASSFISH-21537] JsonObjectBuilder incorrect validation in add function Created: 19/Apr/16  Updated: 19/Apr/16

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

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


 Description   

The JsonObjectBuilder add method has a bug where if another name in the same scope is added it will overwrite that one with the new one without casting an exception or displaying any error of any kind. The problem is with no check before adding the value to the valueMap which makes it so that the old value overwrites the old one.

Relevant parts are in JsonObjectBuilderImpl method JsonObjectBuilder third line change from:
valueMap.put(name, new JsonStringImpl(value));
to:
if(valueMap.contains(name))

{ throw new SomeInvalidNameException("Two values cannot have the same name in the same scope"); }

valueMap.put(name, new JsonStringImpl(value));






[GLASSFISH-21536] NPE at "org.glassfish.api.jdbc.SQLTraceRecord.toString(SQLTraceRecord.java:231)" Created: 15/Apr/16  Updated: 15/Apr/16

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

Type: Bug Priority: Critical
Reporter: cistox Assignee: sfelts
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any



 Description   

The following code generates a NPE:
Class: SQLTraceRecord.java
Reason: The "param.toString()" is unsafe because it is quite normal that an SQL UPDATE provides a NULL param to force a NULL value in a given database table column.
As this is a trace the null should be simply printed as string "null".

@Override
public String toString() {
StringBuffer sb = new StringBuffer();
sb.append("ThreadID=" + getThreadID() + " | ");
sb.append("ThreadName=" + getThreadName() + " | ");
sb.append("TimeStamp=" + getTimeStamp() + " | ");
sb.append("ClassName=" + getClassName() + " | ");
sb.append("MethodName=" + getMethodName() + " | ");
if(params != null && params.length > 0) {
int index = 0;
for(Object param : params)

{ sb.append("arg[" + index++ + "]=" + param.toString() + " | "); // ERROR IS HERE }

}
//TODO add poolNames and other fields of this record.
return sb.toString();
}

This is the NPE trace:

Severe: java.lang.NullPointerException
at org.glassfish.api.jdbc.SQLTraceRecord.toString(SQLTraceRecord.java:231)
at com.sun.gjc.util.SQLTraceLogger.sqlTrace(SQLTraceLogger.java:69)
at com.sun.gjc.util.SQLTraceDelegator.sqlTrace(SQLTraceDelegator.java:94)
at com.sun.gjc.spi.JdbcObjectsFactory$1.invoke(JdbcObjectsFactory.java:142)
at com.sun.proxy.$Proxy244.prepareStatement(Unknown Source)






[GLASSFISH-21114] Failure to lookup EJB in ear/war Created: 01/Jul/14  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1_b05, 4.1_b06, 4.1_b07
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dbcjbn Assignee: Marek Potociar
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review, fishcat

 Description   

I have an ear which includes an EJB and a jax-rs WAR module, both listed in the application.xml file of the EAR.

The war contains jax-rs Application and resource bean classes, and the resource class injects stateless bean from the EJB module using @EJB annotation.

When I access the REST resource after deploy GlassFish is unable to locate the jax-rs resource bean, which lives inside the WAR. It looks like GlassFish assumes it is to be found in the EJB module (see Stacktrace below).

I have a small example application exhibiting this problem, that I will gladly upload if possible.

The problem does not appear to be in GlassFish versions 4.0 up to and including 4.0.1 b04.

We have done testing on both Java 7 and 8.

[2014-07-01T12:06:22.179+0200] [glassfish 4.0] [WARNING] [] [org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider] [tid: _ThreadID=123 _ThreadName=http-listener-1(1)] [timeMillis: 1404209182179] [levelValue: 900] [[
An instance of EJB class, dk.dbc.gf.ejb.HelloWorldBean, could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NamingException: Lookup failed for 'java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookupSimpleForm(EjbComponentProvider.java:378)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookup(EjbComponentProvider.java:360)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.access$000(EjbComponentProvider.java:100)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider$EjbFactory.provide(EjbComponentProvider.java:123)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2151)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:641)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:626)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:74)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:112)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:94)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:63)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:261)
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:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:252)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1025)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java: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.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 64 more
]]



 Comments   
Comment by Joe Di Pol [ 01/Jul/14 ]

There have been some recent Jersey integrations. Assigning to Jakub for initial evaluation.

Comment by dbcjbn [ 04/Aug/14 ]

Would you happen to have an estimate on when this issue will be addressed, please?

Comment by dbcjbn [ 10/Sep/14 ]

This bug has also been observed on GlassFish v4.1

Comment by sgerr [ 16/Sep/14 ]

Bug is reproduced at Glassfish 4.1. It seems it is related to https://java.net/jira/browse/JERSEY-2122, but Jersey bug is at fixed state (fix version is 2.6), whereas Glassfish 4.1 is packaged with jersey of version 2.10.4-0. Unfortunately, this bug still appears. Is it scheduled for resolution?

Comment by giates2000 [ 21/Sep/14 ]

Due to this issue all my working jee7 rest web services are now stopped on glassfish v. 4.1, is there any workaround ?

Comment by gray [ 20/Oct/14 ]

I've found what is causing this bug and added comment to https://java.net/jira/browse/JERSEY-2122.

Comment by gray [ 21/Oct/14 ]

https://java.net/jira/browse/JERSEY-2690

Comment by MarvinEmilBrach [ 08/Mar/15 ]

posssible workaround: replace @Stateless with:
@javax.enterprise.context.RequestScoped
@javax.enterprise.context.ApplicationScoped
@javax.enterprise.context.ConversationScoped // NOT tested
@javax.enterprise.context.SessionScoped // NOT tested

perhaps related to https://java.net/jira/browse/GLASSFISH-21199

Comment by dobromyslov [ 15/Mar/15 ]

@RequestScoped breaks transactions in Jersey and it requires to mark methods as @Transactional.

Also Weld does not work well with @RequestScoped and raises an exception sometimes:
https://issues.jboss.org/browse/WELD-1774

Comment by dobromyslov [ 22/Mar/15 ]

java.lang.IllegalStateException: WELD-000335: Context is already active
Raises when I redeploy with JRebel.
It's been fixed in WELD 2.2.8.Final.

Comment by Sparksis [ 16/May/15 ]

I've submitted a pull request which fixes the issue in Jersey: https://github.com/jersey/jersey/pull/162

Unfortunately the the pull request is still pending.

Comment by nabizamani [ 14/Apr/16 ]

Is this here still an open issue? I'm just wondering because there is no reaction from Oracle!

Comment by Jakub Podlesak [ 14/Apr/16 ]

I am no longer on Jersey team. IIUC, this has already been fixed in Jersey (as per https://github.com/jersey/jersey/commit/8636f65b992322008bb987409af0dd97dec3b95f ). So this bug should get fixed in GlassFish once the corresponding Jersey version gets integrated.





[GLASSFISH-21357] Entity Tables are not created during deployment time Created: 10/May/15  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: configuration, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

GlassFish Server Open Source Edition 4.1 (build 13) with latest JDK 8


Tags: create, deployment, entity, generate, jpa, persistence, table

 Description   

It seems that in Glassfish 4.1 DB tables for JPA entity classes are not generated during deployment time. Previously, when deploying the application with the correct persistence.xml file and with generation type "create" (in GF 4.1 this would be <property name="javax.persistence.schema-generation.database.action" value="create"/>) then the tables should be created at deployment time.

This does not happen anymore. It seems to be a change of behavior and has caused heavy backwards compatibility issues for us after migrating from GF 3.1.2.2 to GF 4.1. It seems that since Glassfish 4.1 you need to use your PU somewhere before the tables are created. In other words: tables are created only when they are needed the first time.

The following stack overflow articles discuss that topic as well:

http://stackoverflow.com/questions/25489359/entity-table-is-not-creating-using-jpa-2-1

https://stackoverflow.com/questions/25935866/how-to-use-jpa-with-java-ee-7-glassfish-4-1-and-maven-on-javadb/28841583#28841583



 Comments   
Comment by Lukas Jungmann [ 11/May/15 ]

if you're using eclipselink, then adding 'eclipselink.deploy-on-startup=true' to your persistence.xml should resolve the problem

Comment by nabizamani [ 07/Dec/15 ]

No progress after 6 months? This is a Java EE spec incompatibility or at least a change of the behavior from 3.1.2.2 to 4.1.x! How could the Java EE spec compliance tests pass??? I can see that this ticket is assigned to Masoud Kalali, but he has zero activity since May this year! So what is going on at Oracle?????

Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.

Comment by nabizamani [ 14/Apr/16 ]

Another 4 months have passed and no reaction. That means almost 1 year is over and there is no reaction!
No one at Oracle interested to work on this?





[GLASSFISH-21312] java.io.IOException: java.util.concurrent.TimeoutException comes up from time to time Created: 23/Feb/15  Updated: 14/Apr/16

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

Type: Bug Priority: Major
Reporter: nabizamani Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)



 Description   

Fo a client I migrated from Glassfish 3.1.2.2 to the latest Glassfish 4.1 and now suddenly I can see java.util.concurrent.TimeoutException (see logs below). I can't tell where this comes from. I checked all the log files from GF 3.1.2.2 and there I can't find even a single entry...

[2015-02-23T11:06:43.377+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=27 _ThreadName=http-listener-1(2)] [timeMillis: 1424686003377] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:973)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:686)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2199)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
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 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
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.util.concurrent.TimeoutException
at org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:357)
at org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:264)
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:962)
... 42 more
]]



 Comments   
Comment by oleksiys [ 23/Feb/15 ]

This Exception appears when the server can't write the data to a client. Most probably client or network can't keep up with the server's pace.
You're right, in 3.1.2 we throw different Exception, but logic is the same.

Do you see a particular problem related to this Exception?

Comment by nabizamani [ 23/Feb/15 ]

As of now I don't see any real problem other than annoying amount of logs.
I have also some other new log entries which we never had in Glassfish 3.1.2.2:

  • java.lang.IllegalStateException: getOutputStream() has already been called for this response
  • java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.apache.struts2.views.jsp.TextTag@ee5597c of class class org.apache.struts2.views.jsp.TextTag

I believe that latter one occurs during restart oder the server or when underlying, maybe deploying.
I will monitor this the next days and let you know about my findings.

Comment by oleksiys [ 23/Feb/15 ]

Well, I think we can reduce the logging level for this exception.
Regarding:

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

looks like you call response.getWriter() after response.getOutputStream() was called, you can't combine byte- and character-based writes, that's why you see the exception.

Comment by nabizamani [ 23/Feb/15 ]

Yes, I figured that. However, we did not change anything in the jsp that seems to produce this exception. Like I said, I will monitor and analyze things and post my findings here...

Comment by nabizamani [ 24/Feb/15 ]

I think I got some fIndings:

I get somehow java.io.IOException: java.util.concurrent.TimeoutException
I cannot really reproduce it, it just happens from time to time...
Because of the exception my error page defined in web.xml gets called:

web.xml (just the relevant part):

<!-- catch all errors -->
<error-page>
    <location>/WEB-INF/jsp/error/error.jsp</location>
</error-page>

/WEB-INF/jsp/error/error.jsp :

<%@page isErrorPage="true" session="false"
%><%@ page import="org.apache.log4j.Logger"
%><%@ page trimDirectiveWhitespaces="true" 
%><%
response.setStatus(response.getStatus());   //or some other code
%><html>
    <head>
        <title>Error <%= response.getStatus() %></title>
    </head>
    <body>
        <h2 style="color:red;">Error <%= response.getStatus() %></h2>
    </body>
</html>
<%
Logger log = Logger.getLogger("error");
String uri = (String) request.getAttribute("javax.servlet.error.request_uri");
String info = "(ip='"+request.getRemoteAddr()+"' x-forwarded-for='"+request.getHeader("x-forwarded-for")+"')";
String qs = request.getQueryString();
if (qs != null)
    log.error("HTTP Status "+response.getStatus() +" for request '"+uri+"?"+qs+"' "+info);
else
    log.error("HTTP Status "+response.getStatus() +" for request '"+uri+"' "+info);
%>

So the error.jsp is called, and right after that I get this error in the log file:
java.lang.IllegalStateException: getOutputStream() has already been called for this response

I guess that is because Glassfish has either already sent "some" response or because the connection is closed (i.e. by peer?). What does timeout exactly mean? What kind of timeout are we talking about?

However, I still get the log entries I have in the error.jsp. This is an example log entry:
2015-02-24 17:27:44,985 ERROR error._jspService:76 - HTTP Status 200 for request '/assets/plugins/bootstrap/css/bootstrap.css' (ip='41.216.47.46' x-forwarded-for='null')]]

As you can see the HTTP Status code is 200 (and that is correct, because the file is on the server). Although an error was thrown by the runtime, I guess because the connection was closed or something... I believe that throwing TimeoutException because maybe a connection has closed for some reason and passing it all the way up is the issue here. Do you know if there is some change in the code somewhere here between 3.1.2.2 and 4.1? I can also see some "java.io.IOException: Broken pipe" exceptions in the logs (I believe this is related somehow).

A log file with some relevant parts is attached.

Comment by nabizamani [ 24/Feb/15 ]

Sorry, I can't attach files... So here some logs:

[2015-02-24T17:27:44.984+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264984] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: java.util.concurrent.TimeoutException
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:973)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:686)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2199)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
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 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.web.filter.ForceHttpsFilter.doFilter(ForceHttpsFilter.java:51)
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.util.concurrent.TimeoutException
at org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:357)
at org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:264)
at org.glassfish.grizzly.http.io.OutputBuffer.blockAfterWriteIfNeeded(OutputBuffer.java:962)
... 45 more
]]

[2015-02-24T17:27:44.986+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1424795264986] [levelValue: 800] [[
2015-02-24 17:27:44,985 ERROR error._jspService:76 - HTTP Status 200 for request '/assets/plugins/bootstrap/css/bootstrap.css' (ip='41.216.47.46' x-forwarded-for='null')]]

[2015-02-24T17:27:44.986+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web.core] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264986] [levelValue: 900] [[
Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T17:27:44.987+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-2(2)] [timeMillis: 1424795264987] [levelValue: 900] [[
org.apache.catalina.core.StandardHostValve@6d45b284: Exception Processing ErrorPage[errorCode=0, location=/WEB-INF/jsp/error/error.jsp]
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:03:01.398+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=38 _ThreadName=Thread-8] [timeMillis: 1424797381398] [levelValue: 800] [[
2015-02-24 18:03:01,397 ERROR error._jspService:76 - HTTP Status 404 for request '/robots.txt' (ip='77.66.121.243' x-forwarded-for='null')]]

[2015-02-24T18:12:38.665+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958665] [levelValue: 900] [[
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(TCPNIOUtils.java:149)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeSimpleBuffer(TCPNIOUtils.java:133)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:109)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:91)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:261)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:170)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:70)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.ssl.SSLBaseFilter$SSLTransportFilterWrapper.handleWrite(SSLBaseFilter.java:1004)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.ssl.SSLBaseFilter.handleWrite(SSLBaseFilter.java:332)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.write(OutputBuffer.java:680)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:355)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:342)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:161)
at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:2477)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2212)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1085)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:568)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
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 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.web.filter.ForceHttpsFilter.doFilter(ForceHttpsFilter.java:51)
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)
]]

[2015-02-24T18:12:38.666+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1424797958666] [levelValue: 800] [[
2015-02-24 18:12:38,666 ERROR error._jspService:76 - HTTP Status 200 for request '/download/img/prifile.jpg‚ (ip='23.229.97.36' x-forwarded-for='null')]]

[2015-02-24T18:12:38.666+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web.core] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958666] [levelValue: 900] [[
Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:12:38.667+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-2(5)] [timeMillis: 1424797958667] [levelValue: 900] [[
org.apache.catalina.core.StandardHostValve@6d45b284: Exception Processing ErrorPage[errorCode=0, location=/WEB-INF/jsp/error/error.jsp]
java.lang.IllegalStateException: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:777)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:224)
at javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:152)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:195)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:188)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:240)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:185)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:137)
at org.apache.jsp.WEB_002dINF.jsp.error.error_jsp._jspService(error_jsp.java:88)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:695)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:626)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:500)
at org.apache.catalina.core.StandardHostValve.dispatchToErrorPage(StandardHostValve.java:699)
at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:309)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:232)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:417)
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)
]]

[2015-02-24T18:49:08.494+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=30 _ThreadName=Thread-8] [timeMillis: 1424800148494] [levelValue: 800] [[
2015-02-24 18:49:08,493 ERROR error._jspService:76 - HTTP Status 404 for request '/WEB-INF/tiles.xml' (ip='202.46.62.153' x-forwarded-for='null')]]

Comment by nabizamani [ 24/Feb/15 ]

I can confirm the assumptions I made above and I can reproduce it now:

1. I assume you have access to a remote glassfish server - NOT ON YOUR OWN MACHINE!
2. Deploy some large file onto that server which you download via browser in the next step - large enough so that you have enough time to disable the network connection (i.e. wifi) on you local machine abruptly
3. Use your browser to download that large file after you have deployed it
4. Once the download has started make sure to a abruptly disable your network connection (on your local machine) before the download finishes - that will simulate a lost network connection...
5. Now check the log files, they will be pretty close to what you can see in my logs

That means:
1. It seems from time to time people accessing our machine simply loose their connection while requesting/downloading some content (that ist not unusual)
2. In GF 4.1 these events are raised/logged as exceptions, it was not like this in GF 3.1.2.2
3. This can cause unwanted behavior, see my explanations in the previous comments. Was there some related change in the Java EE 7 specs???

I don't think that calling the error-page defined in the web.xml is a good decision in case some client has lost network connectivity (caused because the exception is thrown). I am not even sure if it's worth logging it, is it? Others might have different opinions...

Can you reproduce the issue? What do you think?
I think the caller of the Grizzly API should swallow the exceptions, unless there was a change in the Java EE specs...

Comment by oleksiys [ 25/Feb/15 ]

I changed the error message in Grizzly to be more understandable, TimeoutException will be hidden and user will see IOException only with better description.
Otherwise I'll redirect this issue to webcontainer, since it's webcontainer logging the exception and tries to serve the error page.

Comment by nabizamani [ 07/Dec/15 ]

Is this here still considered by anyone at oracle? Almost 10 months and no reaction? Is Oracle interested in Glassfish at all????????

Comment by nabizamani [ 14/Apr/16 ]

Well, again... is there anyone working on this here??????





[GLASSFISH-21535] The result of EntityManager.find() is not managed Created: 14/Apr/16  Updated: 14/Apr/16

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

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


 Description   
@Path("/employees")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
//@Stateless    //we can't use this because of bug in Glassfish 4.1, see http://stackoverflow.com/questions/25879898/glassfish-4-1-cant-run-restful-service-when-using-ear-ejb-web-module
@RequestScoped  //this is a workaround that works for us
public class Employees {
    
	@PersistenceContext(unitName = "myPU")
    private EntityManager em;
    
    @PUT
    @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
    @Path("/{empId}")
    public Response updateEmployeeFirstName(@NotNull @PathParam("empId") Long empId, @PathParam("firstName") String firstName) throws ParseException, JOSEException {
        Employee emp = em.find(Employee.class, empId);
    	if(emp != null){
    		System.out.println("em.contains(emp) ==> " + em.contains(emp)); //always false
    		emp.setFirstName(firstName);
    		//em.merge(emp);	//because emp is not managed this would be a workaround

    		//...
    	}else{
    		return Response.status(Status.NOT_FOUND).build();
    	}
    }
   
}

This issue is somehow related to https://java.net/jira/browse/GLASSFISH-20968, which is flagged as resolved - but that's false!

Dear Oracle team,
There are many GF issues open and many of the have a very high priority - these issues make GF even incompatible to the Java EE 7 spec!! Any other Java EE 7 server would have never been "certified" with all theses issues, especially because these issues break the Java EE 7 spec! Like another person mentioned in the other ticket "I still wonder if the TCK is so weak with regard to extended persistence context, or glassfish 4 was only declared passing it." How can this happen?

This issue is a blocker as it is breaking Java EE compliance! Furthermore, people who want to learn JPA, Java EE etc. will be confused a lot and might get a wrong impression of Java EE!



 Comments   
Comment by nabizamani [ 14/Apr/16 ]

Also see http://stackoverflow.com/questions/21356448/jpa-entity-found-by-find-in-a-stateful-ejb-extended-is-not-managed

Comment by nabizamani [ 14/Apr/16 ]

Little mistake: the parameter firstName does not come from @PathParam("firstName"). Instead it comes from a FormParam...





[GLASSFISH-20968] find() method with EXTENDED Persistence Context and TX_TYPE: NOT_SUPPORTED Created: 02/Feb/14  Updated: 14/Apr/16  Resolved: 27/Jun/14

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: sdmoralesma Assignee: ethan.wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 64bits, OpenJDK 7, JavaDB


Tags: 4_0_1-evangelists, 4_0_1-mustfix

 Description   

According to spec:

"The find method (provided it is invoked without a lock or invoked with LockModeType.NONE)
and the getReference method are not required to be invoked within a transaction. If an entity man-
ager with transaction-scoped persistence context is in use, the resulting entities will be detached; if an
entity manager with an extended persistence context is used, they will be managed. See section 3.3 for
entity manager use outside a transaction."

That's is not properly working for GF4 (I have tested that with GF3 and works as expected):

If I have a Gateway like this:

@Stateful
@TransactionAttribute(NOT_SUPPORTED)
public class CustomerGateway {

@PersistenceContext(unitName = "customersPU", type = EXTENDED)
private EntityManager em;
private Customer customer;

public Customer find(Long id)

{ // customer is not managed! this.customer = em.find(Customer.class, id); // Prints false! System.out.println("Method find: " + em.contains(customer)); // Prints false too (2 is the id of an entity)! System.out.println("Method find: " + em.contains(em.find(Customer.class, 2L)); // A workaround customer = em.merge(customer); // Print true. System.out.println("Method find after merge: " + em.contains(customer)); return this.customer; }

Is not working according to spec.

I have create a GitHub project, maybe is useful for you:
https://github.com/sdmoralesma/SO-21356448



 Comments   
Comment by jclingan [ 01/May/14 ]

If evaluation of this issue shows spec compliance issues, then this bug should be fixed.

Comment by Ed Bratt [ 20/May/14 ]

This is marked Must Fix for 4.0.1. Please evaluate. Thank you.

Comment by ethan.wang [ 27/Jun/14 ]

Fixed by change 63399

Comment by pdudits [ 22/Jan/16 ]

It looks that this is not entirely fixed. Making any query in extended persistence context will detach all entities. I'll file a new issue for that.

Comment by nabizamani [ 10/Apr/16 ]

@pdudits you are absolutely right! This issue is still not fixed! When calling em.find(...) the result is not managed. At least in Glassfish 4.1.1 and I'm not very happy about this! Did you already open another issue for this? If not I will open one and mention it here.

Comment by pdudits [ 10/Apr/16 ]

My pull request will fix that in next Payara release. I still wonder if the TCK is so weak with regard to extended persistence context, or glassfish 4 was only declared passing it.

Comment by nabizamani [ 14/Apr/16 ]

@pdudits Thanks for that! I totally agree with what you say, also because this is not the first issue of that kind (and the other are still open)! I have just opened another ticket here: https://java.net/jira/browse/GLASSFISH-21535

To everyone: please not for the other ticket! I can't even believe that this issue is naked as "fixed" - this is wrong!





[GLASSFISH-21534] Jersey Client POSTs between GF apps (microservice) timeout Created: 13/Apr/16  Updated: 13/Apr/16

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

Type: Bug Priority: Major
Reporter: jmanko Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish Server Open Source Edition 4.1.1 (build 1)
Windows Server 2008R2


Tags: Jersey

 Description   

I'm attempting a REST request from one GF deployed app to another (on same server), but the request is times out. I've tried to increased the timeout value, but that doesn't work.

Here is some sample code:

ClientConfig clientConfig = null;
Client client = null;
WebTarget webTarget = null;
FormDataMultiPart formDataMultiPart = null;
Invocation.Builder invocationBuilder = null;
Response response = null;

clientConfig = new ClientConfig();
clientConfig.register(MultiPartFeature.class);
clientConfig.register(ListReader.class);

String url = "http://localhost:8080/someapp"
String urlPath = "/rest/path";

Map<String, String> params = new HashMap<>();
params.put("option", "value");

Map<String, String> formFields = new HashMap<>();
formFields.put("field1", "value");

List<BodyPart> fileParts = null;

// See http://www.adam-bien.com/roller/abien/entry/setting_timeout_for_the_jax
clientConfig.property("jersey.config.client.connectTimeout", 7000);
clientConfig.property("jersey.config.client.readTimeout", 7000);
client = ClientBuilder.newClient(clientConfig);
webTarget = client.target(url).path(urlPath);

if (params != null && !params.isEmpty()) {
for (String key : params.keySet())

{ webTarget = webTarget.queryParam(key, params.get(key)); }

}

formDataMultiPart = new FormDataMultiPart();
formDataMultiPart.setMediaType(MediaType.MULTIPART_FORM_DATA_TYPE);
if (fileParts != null && !fileParts.isEmpty()) {
for (BodyPart bodyPart : fileParts)

{ formDataMultiPart.bodyPart(bodyPart); }

}

if (formFields != null && !formFields.isEmpty()) {
for (Map.Entry<String, String> formField : formFields.entrySet())

{ formDataMultiPart.field(formField.getKey(), formField.getValue()); }

}

invocationBuilder = webTarget.request(MediaType.APPLICATION_JSON);
response = invocationBuilder.post(Entity.entity(formDataMultiPart, formDataMultiPart.getMediaType()));






[GLASSFISH-19104] NullPointerException was thrown out when delete a nonexistent lifecycle module Created: 25/Sep/12  Updated: 12/Apr/16  Resolved: 25/Sep/12

Status: Resolved
Project: glassfish
Component/s: lifecycle_modules
Affects Version/s: 4.0_b54
Fix Version/s: 4.0_b56_ms5

Type: Bug Priority: Critical
Reporter: zhouronghui Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP, Windows 7


Attachments: Text File GLASSFISH-19104.patch    
Tags: admin

 Description   

[Bug Description]
When executed "delete-lifecycle-module" command by specifing a name that does not exist, it will be failed and the NullPointerException was thrown out.

[Operations]
STEP1 Start the domain

asadmin> start-domain
Waiting for domain1 to start ..............................
Successfully started the domain : domain1
domain Location: D:\glassfish3\glassfish\domains\domain1
Log File: D:\glassfish3\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Command start-domain executed successfully.

STEP2. Execute the delete-lifecycle-module to delete a lifecycle-module that does not exist.

asadmin> delete-lifecycle-module not_exist
remote failure: User is not authorized for this command
java.lang.NullPointerException
Command delete-lifecycle-module failed.

[affected versions]
1 4.0_b54
2 Glassfish's trunk until 2012/09/25



 Comments   
Comment by zhouronghui [ 25/Sep/12 ]

The patch of GLASSFISH-19104

Comment by zhouronghui [ 25/Sep/12 ]

Dear Tom

I think it's caused by the NULL check was omitted
in DeleteLifecycleModuleCommand#getAccessChecks,
and I made a patch for this issue and attached to
the ISSUE. Would you please check it?

PS:
The NullPointerException was thrown out and
the stack trace in server.log was as follows:

 
[#|2012-09-25T15:46:58.318+0900|SEVERE|44.0|javax.enterprise.system.tools.admin.security.authorization|_ThreadID=12;_ThreadName=admin-listener(1);|org.glassfish.deployment.admin.DeleteLifecycleModuleCommand
java.lang.NullPointerException
	at java.net.URI$Parser.parse(URI.java:3004)
	at java.net.URI.<init>(URI.java:577)
	at java.net.URI.create(URI.java:839)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.resourceURIFromAccessCheck(CommandSecurityChecker.java:244)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.checkAccessRequired(CommandSecurityChecker.java:189)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:139)
~omitted~
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
	at java.lang.Thread.run(Thread.java:662)
|#]
Comment by Hong Zhang [ 25/Sep/12 ]

As Tim helped make this part of the security changes, I will let Tim take a look to see if the attached patch is the best place to fix (or should the NPE check made in CommandSecurityChecker.resourceURIFromAccessCheck so other similar code paths are covered as well).

Comment by Tim Quinn [ 25/Sep/12 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 56123
Author: tjquinn
Date: 2012-09-25 15:54:10 UTC
Link:

Log Message:
------------
Fix for 19104.

The code which prepares the access check did not adequately protect against a null resource name being used (which happens if the specified life cycle module does not exist).

Revisions:
----------
56123

Modified Paths:
---------------
trunk/main/nucleus/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeleteLifecycleModuleCommand.java

Comment by Hari92 [ 12/Apr/16 ]

I'm getting the below error while deploying a war which is worked earlier in Tomcat but not working in Glassfish 4.0
[2016-04-13T00:02:23.156+0530] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1460485943156] [levelValue: 1000] [[
An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:187)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:183)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:183)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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:745)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
... 52 more
]]

Comment by Hari92 [ 12/Apr/16 ]

C:\Soft64\glassfish-4.0\glassfish4\glassfish\bin>asadmin deploy --force=true C:\Users\HA288049\Desktop\recoengine\recoengine.war
remote failure: Error during authorization
java.lang.RuntimeException: java.lang.NullPointerException
Command deploy failed.





[GLASSFISH-21533] The WAR file working in Tomcat server is not working in Glassfish 4.0 Created: 12/Apr/16  Updated: 12/Apr/16

Status: Open
Project: glassfish
Component/s: admin, deployment
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hari92 Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: maven
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

java 1.8



 Description   

[2016-04-13T00:02:23.156+0530] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1460485943156] [levelValue: 1000] [[
An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:187)
at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:183)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:183)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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:745)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
... 52 more
]]






[GLASSFISH-21510] class including invokedynamic is breaking deployment - BufferUnderflowException Created: 04/Feb/16  Updated: 08/Apr/16

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

Type: Bug Priority: Major
Reporter: floR Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java 1.8.0_72
glassfish 4.1.1
ubuntu 14.4



 Description   

When trying to deploy an enterprise application including classes with bytecode containing invokedynamic, the deployment randomly stops with throwing a BufferUnderflowException:

java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at com.sun.enterprise.deployment.annotation.introspection.ConstantPoolInfo.containsAnnotation(ConstantPoolInfo.java:86)
...

This is always preceeded by severe warnings like

Severe: Unknow type constant pool 18 at position5
Severe: Unknow type constant pool 0 at position6
Severe: Unknow type constant pool 0 at position7

This is a problem especially when using Java 8's method reference operator/lamdas.



 Comments   
Comment by floR [ 04/Feb/16 ]

The problem seems to be the missing support of Java 7's contstant pool types Method handle, Method type and InvokeDynamic (ids 15, 16 and 18) in the class
com.sun.enterprise.deployment.annotation.introspection.ConstantPoolInfo of modules/dol.jar.

This class is used for checking the existence of annotations. For that reason, it inspects the constant pool part of the .class files byte by byte.
When trying to process any of the unsupported types, it simply logs the warning "Unknow [sic] type constant pool x at position i" and proceeds processing with the next byte, missing to skip bytes blonging to the types data structure.

This can result in trying to read bytes belonging to an irregular inferred constant pool entry of type string with an illegal length (inferred from the constant pool entry) => BufferUnderflowException.

Comment by koen.serneels [ 08/Apr/16 ]

Hi. We are experiencing the exact same problem. Is there any news on this issue?

Btw; it is very surprising to me that no one reported this issue before. I mean, it cannot be that no one experienced this issue since Java8 and GF4?
Moreover, we are experiencing this in an older version of GF. So this gives a pretty good indication that this is not something that has been introduced recently.

Comment by payara_steve [ 08/Apr/16 ]

This may be due to an old asm jar packaged with GlassFish. We have had something which sounds the same in Payara see https://github.com/payara/Payara/issues/689 . If you can deploy to a prerelease buid of Payara this would indicate the problem is in the asm library version and needs some refactoring to fix.

Comment by koen.serneels [ 08/Apr/16 ]

@payara_steve : I don't directly see how this would be ASM related. As pointed out by floR, the problem resides in ConstantPoolInfo which is called at deployment time.
This class has no dependency on ASM and performs some bytecode interpretation by itself. However, as (also pointed out by floR in his excellent post http://stackoverflow.com/questions/28301584/javaee-glassfish-bufferunderflowexception) this code tries to ignore unknown types (new types introduced with Java8 in the meantime) by skipping the current byte and continuing at the next byte. However, the next byte is in this case still part of the data structure of the unknown type. It should have skipped the amount of bytes the type data structure is composed of instead, before assuming the next type. This leads to misinterpretation and (depending on the case) exceptions as these bytes have different meaning than what is expected. But for what it's worth, I tried upgrading the GF ASM in our GF version to the latest one, but no difference as expected.

Now, the ConstantPoolInfo is apparently no longer used when deploying WARs on GF4 (as also pointed out by floR). Based on the things I'm seeing here I can confirm this as none of my breakpoints are triggered when deploying WARs on GF4, while they are on the (older) version we are using. On GF4 it seems that this code is indeed only executed for EAR and EJB modules while it is also executed on WARs on older GF versions. Upgrading to GF4 might solve our problem as we currently only have WARs. But it is clear that this problem needs attention. This code is still in the codebase and still causing trouble depending on conditions. Moreover, there is some randomness involved as we have several classes with lambda's but only one is currently posing a problem. It will probably depend on some factors and value of the misinterpreted bytes if the BufferUnderflowException is triggered or not





[GLASSFISH-4634] Don't EXPUNGE failed periodic timers unconditionally Created: 06/Apr/08  Updated: 08/Apr/16  Resolved: 07/Oct/10

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 9.1peur1
Fix Version/s: 3.1_ms06

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,634

 Description   

I set up a periodic timer and then caused it to throw an exception. After number
of retries was done and failed the timer was expunged/destroyed.

==

For example,

[#|2008-03-03T12:47:47.859+1100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=31;_ThreadName=p:
thread-pool-1; w: 30;'5@@1204499852281@@server@@domain1' 'TimedObject =
TimerServiceSessionBean' 'Application = testtimerservice_server'
'BEING_DELIVERED' 'PERIODIC' 'Container ID = 78938621512646656' 'Mon Mar 03
12:47:42 EST 2008' '30000' ;2;|EJB5119:Expunging timer
['5@@1204499852281@@server@@domain1' 'TimedObject = TimerServiceSessionBean'
'Application = testtimerservice_server' 'BEING_DELIVERED' 'PERIODIC' 'Container
ID = 78938621512646656' 'Mon Mar 03 12:47:42 EST 2008' '30000' ] after [2]
failed deliveries|#]

==

But I had expected that after the timer period had elapsed it might try again.

Perhaps there can be a check-box in the Admin GUI to allow the user to decide if
period timers should be EXPUNGED on failure, or whether they should fire again
next time the timer period elapses.



 Comments   
Comment by rsoika [ 25/Jun/09 ]

I have the same problem running a timer service on "Sun Java System Application
Server 9.1_02 (build b04-fcs)"
The timer service runs more than 10 hours without a problem.
Than I got a EJB exception and the timer is canceled.
See server.log snipped below:

[ScheduledWorkflowService] 0 workitems processed|#]
[#|2009-06-25T05:05:09.534+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;ScheduledWorkflowServiceImplementation;|EJB5018: An
exception was thrown during an ejb invocation on
[ScheduledWorkflowServiceImplementation]|#]

[#|2009-06-25T05:05:09.535+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;|
javax.ejb.EJBException
at
com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:3869)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3769)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2855)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.lang.NullPointerException
at java.util.Date.getMillisOf(Date.java:939)
at java.util.Date.after(Date.java:912)
at
org.imixs.workflow.jee.ejb.ScheduledWorkflowServiceImplementation.processWorkItems(ScheduledWorkflowServiceImplementation.java:325)
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:585)
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.callEJBTimeout(BaseContainer.java:2824)
... 6 more

#]

[#|2009-06-25T05:05:09.537+0100|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=16;_ThreadName=p:
thread-pool-1; w: 4;'3@@1245854622991@@server@@domain1' 'TimedObject =
ScheduledWorkflowServiceImplementation' 'Application =
imixs-shareyourwork-ear-1.0.2' 'BEING_DELIVERED' 'PERIODIC' 'Container ID =
81602958556332042' 'Wed Jun 24 15:55:00 GMT+01:00 2009' '600000'
;2;|EJB5119:Expunging timer ['3@@1245854622991@@server@@domain1' 'TimedObject =
ScheduledWorkflowServiceImplementation' 'Application =
imixs-shareyourwork-ear-1.0.2' 'BEING_DELIVERED' 'PERIODIC' 'Container ID =
81602958556332042' 'Wed Jun 24 15:55:00 GMT+01:00 2009' '600000' ] after [2]
failed deliveries|#]

Comment by marina vatkina [ 06/Oct/10 ]

I'm changing that part of the code...

Comment by marina vatkina [ 07/Oct/10 ]

With rev is the "reschedule-failed-timer" property is set on the
ejb-timer-service property (i.e. globally), the timers that failed redelivery
will be rescheduled for the next timeout. The server needs to be restarted for
the property to be applied.

Comment by marina vatkina [ 07/Oct/10 ]

It was with rev 41521

Comment by ashishkp [ 17/Nov/11 ]

Nice instructions on .

http://javabarista.blogspot.com/2011/10/reschedule-failed-timer-in-glassfish-31.html

Comment by tkruse [ 08/Apr/16 ]

We faced the same problem, in our case marking an inner transaction with @Transactional, and the TimerBean with @TransactionManagement(TransactionManagementType.BEAN) seemed a viable workaround, I assume this would also mean there will be no immediate retry.

Also in some cases not rolling back transactions via @Transactional(dontRollbackOn=RuntimeException.class) might be viable.





[GLASSFISH-21448] Can not enable secure admin Created: 23/Oct/15  Updated: 31/Mar/16

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

Type: Bug Priority: Major
Reporter: muellermi Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7



 Description   

1. Start GlassFish admin console
2. choose server, Secure Admin
GF displays "an error occured"

3. click onto enable...

GF displays internal error:
HTTP Status 500 - Internal Server Error

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.faces.component.UpdateModelException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

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

Excerpt from log:
[2015-10-23T09:42:58.356+0200] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=46 _ThreadName=admin-listener(3)] [timeMillis: 1445586178356] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null
at com.sun.el.parser.AstValue.getTarget(AstValue.java:192)
at com.sun.el.parser.AstValue.setValue(AstValue.java:226)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:294)
at javax.faces.component.UIInput.updateModel(UIInput.java:832)
at javax.faces.component.UIInput.processUpdates(UIInput.java:749)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1254)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
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.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
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:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Unknown Source)
]]

[2015-10-23T09:44:31.411+0200] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=47 _ThreadName=admin-listener(4)] [timeMillis: 1445586271411] [levelValue: 800] [[
Exception Occurred :null]]



 Comments   
Comment by pczurak [ 25/Mar/16 ]

I am getting the same issue with Glassfish version 4.1.1 running on Linux
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Has anyone found a fix for this?

Comment by hora1806 [ 31/Mar/16 ]

I have the same issue.

I did workaround

asadmin enable-secure-admin

Comment by phendley [ 31/Mar/16 ]

I have seen something similar in past and while not 100% positive, I believe a problem may be that there has to be non-empty password in effect. I believe one can enable the secure admin by doing sequence similar to following:
asadmin change-admin-password (not sure if we need to recycle GF afterwards??)
asadmin enable-secure-admin (not sure if we need to recycle GF afterwards??)
-phendley

Comment by pczurak [ 31/Mar/16 ]

I've found a workaround
Installed Glassfish 4.1 and then updated Glassfish to 4.1.1





[GLASSFISH-21531] Glassfish fails to start with jdk9 due to wrong jdk version detection Created: 31/Mar/16  Updated: 31/Mar/16

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

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


 Description   

"SEVERE: GlassFish requires JDK 7, you are using JDK version 1"






[GLASSFISH-21530] What is GRIZZLY0013? Created: 24/Mar/16  Updated: 24/Mar/16

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

Type: Bug Priority: Major
Reporter: t.shimada Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61



 Description   

Hello I'm TOSHIKAZU. Our Glassfish have problem.
Please teach me how to fix or workaround.

Overview
========
In my client & server of commercially operating of our system has came up with the message of [WARNING][Error] in Glassfish's server.log as problem.
We don't know why has occuerd these problem from our glassfish server.

the following message:
■a part of server.log
---------------------------------------------------
[YYYY-MM-DDT18:51:02.575+0900] [glassfish 4.1] [WARNING] [] [org.glassfish.grizzly.filterchain.DefaultFilterChain] [tid: _ThreadID=132 _ThreadName=BidRateTimer] [timeMillis: 1458553862575] [levelValue: 900] [[
GRIZZLY0013: Exception during FilterChain execution
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:275)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.fill(TCPNIOUtils.java:200)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeCompositeBuffer(TCPNIOUtils.java:81)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:112)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:91)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:261)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:170)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:70)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
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.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBinaryBuffers(OutputBuffer.java:1011)
at org.glassfish.grizzly.http.io.OutputBuffer.flushAllBuffers(OutputBuffer.java:982)
at org.glassfish.grizzly.http.io.OutputBuffer.flush(OutputBuffer.java:737)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:291)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:275)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:175)
at jp.co.fractal.fx.webpublisher.handler.EventHandler.onEvent(EventHandler.java:88)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify0(DefaultNotificationHandler.java:117)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:93)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:83)
at org.glassfish.grizzly.comet.CometContext.notify(CometContext.java:437)
at jp.co.my.do.publisher.management.CometManagement.notifyPrd(CometManagement.java:115)
at jp.co.my.do.publisher.management.timertask.DataPushTask.eventNotify(DataPushTask.java:131)
at jp.co.my.do.publisher.management.timertask.DtatPushTask.run(DataPushTask.java:99)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
]]
---------------------------------------------------

Symptom
=======
#1 When Occuer, Many sessions from rich client will be disconnected to Glassfish server.

#2 Since we will be unbale to connect to server from rich clients every one.

#3 When we tried to reboot the domain(process) of Glassfish, But it was not fix.
In fact the domain(process) couldn't be started by restart command.

#4 Stop its Domain -> Reboot OS -> Start its Domain
Then We try to do the bellow of methods, We can recover our system. Since the rich clients can connect to server as usual.

Our environments
=====
Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61

Question 1
=====
Do you know why come up this [WARNING][Error]?
What happen has this [WARNING][Error] our glassfish?

Question 2
=====
Do you know how to workaround?

Question 3
=====
Do you know how to fix?

Question 4
=====
Do you has experienced improving this problem as case example?

Question 5
=====
How should we invest when we has this problem?

Best Regards.






[GLASSFISH-21529] after running asadmin enable-secure-admin , encounter problem stop/start glassfish Created: 23/Mar/16  Updated: 23/Mar/16

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: None
Fix Version/s: None

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

running Glassfish-4.0-b59 on window XP platform with jdk1.7.0_07


Issue Links:
Cloners
clones GLASSFISH-19207 after running asadmin enable-secure-a... Closed

 Description   

This started on glassfish-4.0-b59 and b58, did not have this issue on glassfish-4.0-b57.

after running asadmin enable-secure-admin, and re-cycling glassfish
you cannot stop/start glassfish anymore.

error from the command line is this:
Z:\glassfish3\glassfish\bin>asadmin stop-domain
NCLS-ADMIN-0010
CLI306: Warning - The server located at Z:\glassfish3\glassfish\domains\domain
is not running.
Command stop-domain executed successfully.

When the process is checked glassfish is running.
Also, this was confirmed multiple times on b58 and 59 with same results.

The server.log is attached.



 Comments   
Comment by wfsaxton [ 23/Mar/16 ]

I wasn't able to re-open this previous issue, but I'm encountering this same exact issue on the latest version of glassfish (4.1.1) on Linux

host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start .......
Successfully started the domain : domain1
domain Location:/glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin change-admin-password
Enter admin user name [default: admin]>
Enter the admin password>
Enter the new admin password> (adminadmin)
Enter the new admin password again> (adminadmin)
Command change-admin-password executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File: /glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin enable-secure-admin
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin start-domain
Waiting for domain1 to start ....
Successfully started the domain : domain1
domain Location: /glassfish/glassfish4/glassfish/domains/domain1
Log File:/glassfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
host:/glassfish/glassfish4/bin$ ./asadmin stop-domain
CLI306: Warning - The server located at /glassfish/glassfish4/glassfish/domains/domain1 is not running.
Command stop-domain executed successfully.





[GLASSFISH-19207] after running asadmin enable-secure-admin , encounter problem stop/start glassfish Created: 22/Oct/12  Updated: 23/Mar/16  Resolved: 02/Mar/13

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b58, 4.0_b59
Fix Version/s: None

Type: Bug Priority: Major
Reporter: teelucksingh Assignee: Ryan Lubke
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

running Glassfish-4.0-b59 on window XP platform with jdk1.7.0_07


Attachments: XML File after-change-domain.xml     XML File after-startup-domain.xml     File server.log-b59    
Issue Links:
Cloners
is cloned by GLASSFISH-21529 after running asadmin enable-secure-a... Open
Related
is related to JAVASERVERFACES-2557 Failure with client side state saving... Closed

 Description   

This started on glassfish-4.0-b59 and b58, did not have this issue on glassfish-4.0-b57.

after running asadmin enable-secure-admin, and re-cycling glassfish
you cannot stop/start glassfish anymore.

error from the command line is this:
Z:\glassfish3\glassfish\bin>asadmin stop-domain
NCLS-ADMIN-0010
CLI306: Warning - The server located at Z:\glassfish3\glassfish\domains\domain
is not running.
Command stop-domain executed successfully.

When the process is checked glassfish is running.
Also, this was confirmed multiple times on b58 and 59 with same results.

The server.log is attached.



 Comments   
Comment by Tim Quinn [ 22/Oct/12 ]

I could not reproduce this on Mac OS X with Java 1.7.0_7 and promoted GlassFish build 59.

The error from the server log (thanks for that) shows that there is something going wrong in the SSL handshake. The secure admin logic has not changed in the recent builds, so it's not yet clear why the errors are happening in your environment.

I'm now trying to get a Windows XP system set up to try to reproduce the error there.

Comment by Tim Quinn [ 22/Oct/12 ]

I was able to reproduce the problem on Windows XP with Java 1.7.0_7 and GlassFish build 59.

I also saw the problem using Java 1.6.0 instead.

There was a Grizzly integration just prior to build 58, so I am transferring this to the Grizzly component.

Comment by oleksiys [ 23/Oct/12 ]

I see nothing wrong w/ Grizzly, the exception is thrown from SSL layer.
Reassigning to security team, may be this is caused by recent JDK updates.

Thanks.

Comment by Tim Quinn [ 23/Oct/12 ]

I have reproduced the problem on a Windows XP system.

Using GlassFish build 57 things work with both Java 1.6.0-37 and 1.7.0_09.

Using build 58 the sequence of steps fails with both versions of Java.

Here are the steps I used:

Install GlassFish.

asadmin start-domain
asadmin change-admin-password # answer prompts to give a non-empty admin password
asadmin enable-secure-admin # you should be prompted for the user and pw; press enter for the user and enter the new pw you set for the pw
asadmin stop-domain
asadmin start-domain
asadmin uptime

Both b57 and b58 will display the server's SSL cert information and prompt the user whether to trust it. (This is normal.)

b57 then prompts for the password and, if you provide it, the uptime command completes normally as expected.
b58 does not prompt for the password but instead reports the error.

Comment by larry.mccay [ 31/Oct/12 ]

After careful review, I am reassigning this to the grizzly team. There was a change made for SPDY which you can view here: http://java.net/projects/grizzly/sources/git/revision/f51d0801c29505b1c74768b73b15207c4b0ac418

SSLUtils and SSLFilter were both modified in this change and appear in the stacktrace in windows environments.
There have been issues with SPDY on windows due to a lack of support for NPN - perhaps there is some assumption of SPDY support leaking into SSL here?

Comment by Ryan Lubke [ 05/Dec/12 ]

The code referenced in the Oct 31 comment isn't currently what is integrated in v4 so it's not relevant.. For what it's worth, the correct code is in the 2.3.x branch.

That said, I've looked at the stacktrace and I'm in agreement with Alexey - this isn't a Grizzly issue.

See:

Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
	at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:158)
	at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:207)
	at sun.security.ssl.JsseJce.getKeyGenerator(JsseJce.java:267)
	at sun.security.ssl.RSAClientKeyExchange.generateDummySecret(RSAClientKeyExchange.java:249)

This implies something isn't installed correctly or a configuration option is messing things up.
One possible problem that the searches pointed to was java.ext.dirs property causing issues.

I don't currently have a Windows VM available for testing. Tim or Tee, could either of you provide the domain.xml from your win32 environment once you start getting the error?

Note: I'm still of the opinion that this isn't a Grizzly issue, but will spend a few cycles to see if we can narrow down the issue.

Comment by Tim Quinn [ 05/Dec/12 ]

Attaching two domain.xml files:

after-startup-domain.xml - the file just after creating a new domain and starting it
after-change-domain.xml - the file just after enabling secure admin and restarting the domain

Both are from b58 (the first GlassFish build where this problem first appeared)

Comment by Tim Quinn [ 05/Dec/12 ]

At Ryan's request, here's some more information.

The GlassFish server.log shows java.ext.dirs defined as

C:\Program Files\Java\jre7/lib/ext:C:\Program Files\Java\jre7/jre/lib/ext:C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1/lib/ext

There is no lib directory under the jre directory on my system, so I ran

dir "C:\Program Files\Java\jre7\lib\ext" "C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1\lib\ext"

and here's the result:

Volume in drive C has no label.
Volume Serial Number is 8C50-8553

Directory of C:\Program Files\Java\jre7\lib\ext

10/23/2012 06:45 AM <DIR> .
10/23/2012 06:45 AM <DIR> ..
09/24/2012 09:28 PM 84,196 access-bridge.jar
09/24/2012 09:17 PM 8,934 dnsns.jar
09/24/2012 09:27 PM 43,593 jaccess.jar
09/24/2012 10:00 PM 1,013,521 localedata.jar
10/22/2012 05:05 PM 829 meta-index
09/24/2012 09:16 PM 15,943 sunec.jar
09/24/2012 09:26 PM 198,176 sunjce_provider.jar
09/24/2012 09:17 PM 30,695 sunmscapi.jar
09/24/2012 09:17 PM 238,226 sunpkcs11.jar
09/24/2012 09:29 PM 68,654 zipfs.jar
10 File(s) 1,702,767 bytes

Directory of C:\tim\asgroup\b58\glassfish3\glassfish\domains\domain1\lib\ext

12/05/2012 01:34 PM <DIR> .
12/05/2012 01:34 PM <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 8,502,603,776 bytes free

Comment by Ryan Lubke [ 22/Feb/13 ]

Sorry for the delay in coming back to this.

I've just tested this with b76 on Windows 7 without issue.

@Tim and/or @Tee: Are you still able to reproduce this on XP with b76 (or later)?

Comment by Ryan Lubke [ 02/Mar/13 ]

Closing as cannot reproduce. If someone is still able to reproduce this, please re-open with details.





[GLASSFISH-21238] Response code 400 on a DELETE request with a body Created: 21/Oct/14  Updated: 22/Mar/16

Status: Reopened
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: ganichev Assignee: oleksiys
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Same behavior on linux x64, windows 7 x64. jdk1.8.0_20



 Description   

When a browser sends a request with a method DELETE and some body, glassfish replies with the response code 400. No corresponding filters or a servlet are called.

When a DELETE request contains no body, then servlet's methods are called as usual.

Glassfish 4.0 has no such problem.

Th sample request is:

DELETE /struct/StructureElement/3751?_dc=1413865817878 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 11
Origin: http://localhost:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36
Content-Type: application/json
Accept: */*
Referer: http://localhost:8080/struct-client/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Cookie: BPMSESSIONID=8aMBU61U7xn1RFSObP1slBhkvMCC; JSESSIONID=d116d19d27d9a381eef12b5acacd; treeForm_tree-hi=treeForm:tree:resources:JDBC:connectionPoolResources:ypool

{"id":3751}


 Comments   
Comment by timuralp [ 22/May/15 ]

This comes up when attempting to implement OpenStack Swift, as the Bulk Delete operation specifies the DELETE verb with an entity containing the list of (container, object) pairs to remove – http://docs.openstack.org/kilo/config-reference/content/object-storage-bulk-delete.html

Comment by gaul [ 15/Jun/15 ]

Calling HttpServer.getServerConfiguration().setAllowPayloadForUndefinedHttpMethods(true) addresses this issue for me.

Comment by oleksiys [ 15/Jun/15 ]

Right, but IMO we have to keep the existing behavior as default and introduce new configuration attribute for <http> element to enable "allow-payload-for-undefined-http-methods".

Comment by oleksiys [ 23/Jun/15 ]

fixed.

Revision: 63971
Date: 2015-06-23 14:35:37 UTC

introduced new http attribute allow-payload-for-undefined-http-methods, which is false by default.

Comment by obi_orjiekwe [ 07/Mar/16 ]

Hi,

I have set this property in asadmin but I am still getting HTTP 400 when I call DELETE with request body:

asadmin set server-config.network-config.protocols.protocol.http-listener-1.http.allow-payload-for-undefined-http-methods=true

Are there any further settings to be applied to make this work?
Please can you also confirm this is fixed in GlassFish 4.1.1?

Regards

Comment by oleksiys [ 08/Mar/16 ]

you're right, it's not fix in 4.1.1
I've just commited the fix to the 4.1.x branch

Comment by obi_orjiekwe [ 22/Mar/16 ]

hi oleksiys, what is the easiest way to obtain I can obtain this patch/fix? thanks for your help





[GLASSFISH-21528] AdminGui does not start after changing master password Created: 21/Mar/16  Updated: 21/Mar/16

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

Type: Bug Priority: Major
Reporter: LeoLux Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

Windows 10
Glassfish Nightly from 2016-03-21 (http://download.oracle.com/glassfish/5.0/nightly/latest-glassfish.zip)


Tags: admin_gui, security

 Description   

Reproduce:
1. Use a clean version of glassfish 5
2. Execute "asadmin change-master-password --savemasterpassword=true domain1" and change the password from "changeit" to "whatever"
3. start the domain by executing "asadmin start-domain domain1"
4. Watch the stacktrace in the server log:

2016-03-21T12:27:19.290+0100|Information: GlassFish Server Open Source Edition 5.0 (1) startup time : Felix (2.125ms), startup services(1.122ms), total(3.247ms)
2016-03-21T12:27:19.400+0100|Information: JTS5014: Recoverable JTS instance, serverId = [100]
2016-03-21T12:27:19.572+0100|Warnung: Cannot start JMX connector JmxConnector config:

{ name = system, Protocol = rmi_jrmp, Address = 0.0.0.0, Port = 8686, AcceptAll = false, AuthRealmName = admin-realm, SecurityEnabled = false}

due to exception java.net.MalformedURLException: Bad URL path: _W_724V_01011603_00_007:8686/jndi/rmi://mathias-lenovo.Speedport_W_724V_01011603_00_007:8686/jmxrmi
2016-03-21T12:27:19.587+0100|Schwerwiegend: java.net.MalformedURLException: Bad URL path: _W_724V_01011603_00_007:8686/jndi/rmi://mathias-lenovo.Speedport_W_724V_01011603_00_007:8686/jmxrmi
at javax.management.remote.JMXServiceURL.validate(JMXServiceURL.java:406)
at javax.management.remote.JMXServiceURL.validate(JMXServiceURL.java:411)
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:226)
at org.glassfish.admin.mbeanserver.RMIConnectorStarter.start(RMIConnectorStarter.java:306)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:313)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:350)
2016-03-21T12:27:19.790+0100|Information: Grizzly Framework 2.3.23 started in: 187ms - bound to [/0.0.0.0:7676]
2016-03-21T12:27:19.822+0100|Information: HV000001: Hibernate Validator 5.1.2.Final
2016-03-21T12:27:22.994+0100|Information: Listening to REST requests at context: /management/domain.
2016-03-21T12:27:23.087+0100|Information: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@1f52eb6f as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@44cb460e.
2016-03-21T12:27:23.509+0100|Information: visiting unvisited references
2016-03-21T12:27:24.009+0100|Information: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2016-03-21T12:27:24.009+0100|Information: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2016-03-21T12:27:24.025+0100|Information: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2016-03-21T12:27:24.041+0100|Information: Created virtual server server
2016-03-21T12:27:24.041+0100|Information: Created virtual server __asadmin
2016-03-21T12:27:24.259+0100|Information: Setting JAAS app name glassfish-web
2016-03-21T12:27:24.259+0100|Information: Virtual server server loaded default web module
2016-03-21T12:27:24.462+0100|Schwerwiegend: Exception while deploying the app [__admingui]
2016-03-21T12:27:24.462+0100|Schwerwiegend: Exception during lifecycle processing
MultiException stack 1 of 6
java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:251)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.initJKS(SecuritySupportImpl.java:184)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:139)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:134)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1350)
at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:271)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:365)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1433)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadKS(SecuritySupportImpl.java:288)
at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:242)
... 59 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)
... 63 more
MultiException stack 2 of 6
java.lang.IllegalStateException: Unable to perform operation: create on com.sun.enterprise.security.ssl.impl.SecuritySupportImpl
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:392)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 3 of 6
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.ssl.SSLUtils errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:246)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 4 of 6
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.ssl.SSLUtils
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:386)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 5 of 6
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.SecurityLifecycle errors were found
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:246)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
MultiException stack 6 of 6
java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.SecurityLifecycle
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:386)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at com.sun.enterprise.security.ee.SecuritySniffer.setup(SecuritySniffer.java:115)
at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:97)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)

2016-03-21T12:27:24.541+0100|Schwerwiegend: Application deployment failed: Exception while deploying the app [__admingui]



 Comments   
Comment by LeoLux [ 21/Mar/16 ]

I tried to reproduce the issue by myself without success. There is no exception even if change the keystore.jsk file by adding another key-pair entry.

I think that the cause is outside of the information given by the stacktrace and outside of the reproduction steps given in this issue. However I am sure that the changing the master password has lead to this issue somehow and for once.

As the bug can't be reproduced reliably this issue can be closed.





[GLASSFISH-21437] Can't create new JDBC Resource from admin web interface Created: 08/Oct/15  Updated: 14/Mar/16  Resolved: 14/Mar/16

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ionut_ursuleanu Assignee: Joe Di Pol
Resolution: Duplicate Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Java 8 update 51


Issue Links:
Duplicate
duplicates GLASSFISH-21443 Impossible to create a mail session Open

 Description   

After pressing the "New" button from JDBC Resources page the following exception is thrown:

2015-10-08T16:58:53.729+0300|Severe: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event215'.
	at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
	at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
	at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
	at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
	at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
	at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:256)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
	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.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
	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.doChainInvoke(StandardPipeline.java:678)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	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:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	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:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEv