[GLASSFISH-21567] glassfish.java.net/javaee5 is obsolete Created: 28/Sep/16  Updated: 28/Sep/16

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

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


 Description   

This directory, and everything underneath it, is long since obsolete
and should be removed.






[GLASSFISH-21544] imqcmd failed when the command repeats many times at 2-minute intervals Created: 31/May/16  Updated: 27/Sep/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";
Comment by tsyama [ 27/Sep/16 ]

OpenMQ 5.1 becomes this error, too.

I propose an another idea that is better than before.

__JMQAdmin had been deleted by the timer task to delete __JMQAdmin automatically.
The imqcmd command internally create the producer to __JMQAdmin, and the timer task is scheduled by this producer when the producer is closed and disconnect from the broker.

It's not necessary to delete __JMQAdmin because imqcmd command surely use it when the command works.
Therefore, I think that I should correct logic so as not to schedule the timer task to delete __JMQAdmin automatically at the end of the work of the imqcmd command.
The imqbridgemgr command also similarly schedules the timer task to delete __JMQBridgeAdmin automatically.
I think that this is also unnecessary.

There is no connection from Consumer though in __JMQAdmin and __JMQBridgeAdmin, there is a connection from producer.
Therefore, I think that only the correction of logic concerning scheduling the timer task by the disconnection from producer is necessary.
If the imqcmd command is not executed after the broker starts, __JMQAdmin is unnecessary.
Therefore, I think that the broker need not generate __JMQAdmin at the time of starup.

I propose the following correction methods for the reasons mentioned above.

Destination.diff Open MQ 5.1-b09
--- mq-broker/broker-core/src/main/java/com/sun/messaging/jmq/jmsserver/core/Destination.java	
+++ mq-broker/broker-core/src/main/java/com/sun/messaging/jmq/jmsserver/core/Destination.java	
@@ -3712,6 +3712,7 @@
         producerFlow.removeProducer(p);
         producerFlow.checkResumeFlow(p, false);
 
+        if (!(MessageType.JMQ_ADMIN_DEST.equals(getDestinationName()) || MessageType.JMQ_BRIDGE_ADMIN_DEST.equals(getDestinationName()))) {
         synchronized (this) {
             if (shouldDestroy()) {
                 if (destReaper != null) {
@@ -3728,6 +3729,7 @@
                 }
             }
         }
+        }
     }
 
     /*




[GLASSFISH-21495] Transaction Rolled back due to timeout Created: 26/Jan/16  Updated: 26/Sep/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: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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

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

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

Using GF 4.1, the method worked correctly.



 Comments   
Comment by napu [ 12/Feb/16 ]

I can confirm the same issue.

Comment by iordannalbantov [ 25/Feb/16 ]

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

Comment by douglasjunior [ 20/Apr/16 ]

I also have a method that persists much data.

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

I can ignore it?

Comment by fgonzales [ 25/May/16 ]

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

Comment by lprimak [ 28/May/16 ]

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

Comment by rgrashel [ 23/Sep/16 ]

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

Comment by lprimak [ 25/Sep/16 ]

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

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

Comment by fgonzales [ 25/Sep/16 ]

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

Comment by lprimak [ 25/Sep/16 ]

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

Comment by lprimak [ 26/Sep/16 ]

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

Comment by fgonzales [ 26/Sep/16 ]

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

Comment by rgrashel [ 26/Sep/16 ]

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





[GLASSFISH-21566] BATCH CLI: NPE on asadmin list-batch-job-executions Created: 26/Sep/16  Updated: 26/Sep/16

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

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


 Description   

When there is no job execution on the remote cluster, asadmin list-batch-job-executions shows:

>asadmin list-batch-job-executions --target cluster1
remote failure: java.lang.NullPointerException
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
An error occurred during replication
Failure: Command _ListBatchJobExecutions failed on server instance cluster_ins1: remote failure: No Job Executions found
Command list-batch-job-executions failed.

The above 'remote failure: java.lang.NullPointerException' doesn't say anything meaningful. Here is the statck trace :

[2016-09-26T10:34:51.746+0900] [glassfish 5.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=52 _ThreadName=admin-listener(2)] [timeMillis: 1474853691746] [levelValue: 1000] [[
  Exception while running a command
java.lang.NullPointerException
	at org.glassfish.batch.ListBatchJobExecutionsProxy.postInvoke(ListBatchJobExecutionsProxy.java:133)
	at org.glassfish.batch.AbstractListCommandProxy.execute(AbstractListCommandProxy.java:133)
	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:360)
	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)
<snip>

the following 'subProperties' is null, but I'm not so sure it is intended or not.

org.glassfish.batch.ListBatchJobExecutionsProxy.java:130
    protected void postInvoke(AdminCommandContext context, ActionReport subReport) {
        Properties subProperties = subReport.getExtraProperties();
        Properties extraProps = context.getActionReport().getExtraProperties();
NPE here----> if (subProperties.get("listBatchJobExecutions") != null)
            extraProps.put("listBatchJobExecutions", subProperties.get("listBatchJobExecutions"));
    }





[GLASSFISH-21565] Memory leak under high transaction throughput Created: 22/Sep/16  Updated: 24/Sep/16

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

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


 Description   

I have found that when running a process which creates and commits many small transactions per second my JVM can quickly run out of memory.

Looking at a memory dump shows an instance of java.util.TimerTask[] holding on to hundreds of thousands of JavaEETransactionImpl. The vast majority of these tasks have status == 3 (which means the timer task has been cancelled). The transactions have been either committed or rolledback.

I can see that JavaEETransactionImpl.java's cancelTimerTask() calls TimerTask.cancel() (which is setting the status to 3), but this does not remove it from the list of tasks in the timer, so the method attempts to purge the timer, but that can only succeed if there are no other active transactions... which rarely occurs under sustained load. It seems that these transactions will only be cleared from the array when they finally time out or after all of the transactions have been committed or rolled back.

I guess a work around might be to reduce the transaction timeout (default appears to be 3600s) or reduce the number of transactions.

With a JVM with 2.5gb of heap I have 816,000 transactions, consuming about 1.2gb of heap.

JavaEETransactionImpl.java:
// Cancels the timertask and returns the timeout
public int cancelTimerTask() {
cancel();
int mod = javaEETM.getPurgeCancelledTtransactionsAfter();
if (mod > 0 && timerTasksScheduled % mod == 0) {
int purged = timer.purge();
if (_logger.isLoggable(Level.FINE))

{ _logger.log(Level.FINE, "Purged " + purged + " timer tasks from canceled queue"); }

}
return timeout;
}



 Comments   
Comment by roycea [ 22/Sep/16 ]

Re-reading that code above, I actually don't understand it... why the modulo? Anyway, there's a problem here nonetheless

Comment by roycea [ 24/Sep/16 ]

Can reproduce this with:

Transactor.java:
package royce;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class Transactor
{
@PersistenceContext(unitName="mypool")
EntityManager em;

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void runTx()
{
}

}

Spinner.java
package royce;

import java.util.logging.Logger;

import javax.ejb.Asynchronous;
import javax.ejb.ConcurrencyManagement;
import javax.ejb.ConcurrencyManagementType;
import javax.ejb.EJB;
import javax.ejb.Singleton;

@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class Spinner
{
private static final Logger log = Logger.getLogger(Spinner.class.getName());
@EJB
private Transactor tx;

private static boolean stop = false;

@Asynchronous
public void spin()
{
Spinner.stop = false;
int count = 0;
while (!stop)

{ tx.runTx(); count++; if (count % 10000 == 0) log.info("Spun " + count + " times"); }

}

public void stop()

{ Spinner.stop = true; }

}

Comment by roycea [ 24/Sep/16 ]

This works around the problem:
asadmin set server-config.transaction-service.timeout-in-seconds=0





[GLASSFISH-21564] Unable to create http-listeners Created: 22/Sep/16  Updated: 22/Sep/16

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

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

Windows 10 x64
NetBeans 8.1
GlassFish Server 4.1.1



 Description   

It seems that the server is not able to create the http-listeners in time (marked with !!!)

Launching GlassFish on Felix platform
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFORMATION: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNUNG: Skipping entry because it is not an absolute URI.
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNUNG: Skipping entry because it is not an absolute URI.
Sep 21, 2016 3:56:06 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner startBundles
WARNUNG: Can not start bundle file:/C:/Program%20Files/glassfish-4.1.1/glassfish/modules/core.jar because it is not contained in the list of installed bundles.
Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@3f6b4900 in service registry.
#!## LogManagerService.postConstruct : rootFolder=C:\Program Files\glassfish-4.1.1\glassfish
#!## LogManagerService.postConstruct : templateDir=C:\Program Files\glassfish-4.1.1\glassfish\lib\templates
#!## LogManagerService.postConstruct : src=C:\Program Files\glassfish-4.1.1\glassfish\lib\templates\logging.properties
#!## LogManagerService.postConstruct : dest=C:\Users\Tobias\AppData\Roaming\NetBeans\8.1\config\GF_4.1.1\domain1\config\logging.properties
Information: Running GlassFish Version: GlassFish Server Open Source Edition 4.1.1 (build 1)
Information: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
Information: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
Information: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
Information: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
Information: Network listener http-listener-1 on port 8080 disabled per domain.xml
Information: Authorization Service has successfully initialized.
Information: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
Information: JTS5014: Recoverable JTS instance, serverId = [100]
Schwerwiegend: Application previously deployed is not at its original location any more: file:/E:/Work/Projects/Java/XWars/XWars-ear/target/gfdeploy/XWars-ear/
! ! ! Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=http-listener-2, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 20ms - bound to [/0.0.0.0:8181]
Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=admin-listener, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:4848]
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:3700]
Information: GlassFish Server Open Source Edition 4.1.1 (1) startup time : Felix (10.819ms), startup services(1.002ms), total(11.821ms)
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:7676]
Information: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@32b9bd12 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@576c5536.
Information: JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://Tobias-PC.fritz.box:8686/jndi/rmi://Tobias-PC.fritz.box:8686/jmxrmi
Information: HV000001: Hibernate Validator 5.1.2.Final
! ! ! Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=http-listener-2, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 15ms - bound to [/0.0.0.0:8181]
Warnung: Originally deployed application at E:\Work\Projects\Java\XWars\XWars-ear\target\gfdeploy\XWars-ear not found
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: Java security manager is disabled.
Information: Entering Security Startup Service.
Information: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
Information: Security Service(s) started successfully.
Information: de.dnhax.xwars.persistence.entities.Player actually got transformed
Information: EclipseLink, version: Eclipse Persistence Services - 2.6.3.v20160428-59c81c5
Information: /file:/E:/Work/Projects/Java/XWars/XWars-ear/target/gfdeploy/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT_jar/_XWarsPU login successful
! ! ! Information: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
Information: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
Information: Created virtual server server
Information: Created virtual server __asadmin
Information: Setting JAAS app name glassfish-web
Information: Virtual server server loaded default web module
Information: JTS5014: Recoverable JTS instance, serverId = [3700]
Information: Portable JNDI names for EJB XWarsLogicImpl: [java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/XWarsLogicImpl!de.dnhax.xwars.logic.XWarsLogic, java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/XWarsLogicImpl]
Information: Glassfish-specific (Non-portable) JNDI names for EJB XWarsLogicImpl: de.dnhax.xwars.logic.XWarsLogic#de.dnhax.xwars.logic.XWarsLogic, de.dnhax.xwars.logic.XWarsLogic
Information: Portable JNDI names for EJB PlayerAccess: [java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/PlayerAccess, java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/PlayerAccess!de.dnhax.xwars.persistence.PlayerAccess]
Information: WELD-000900: 2.2.13 (Final)
WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled
WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jms.injection.JMSCDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jms.injection.JMSCDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
Information: Mojarra 2.2.12 ( 20150720-0848 https://svn.java.net/svn/mojarra~svn/tags/2.2.12@14885) für Kontext '/xwars' wird initialisiert.
Information: RewritePhaseListener starting up.
Information: Monitoring jndi:/server/xwars/WEB-INF/faces-config.xml for modifications
Information: Running on PrimeFaces 6.0
Information: RewriteFilter starting up...
Information: Loaded [4] org.ocpsoft.rewrite.servlet.spi.RewriteLifecycleListener [org.ocpsoft.rewrite.prettyfaces.PrettyFacesRewriteLifecycleListener<-100>, org.ocpsoft.rewrite.faces.FacesRewriteLifecycleListener<0>, org.ocpsoft.rewrite.servlet.impl.DefaultRewriteLifecycleListener<2147483647>, org.ocpsoft.rewrite.servlet.config.lifecycle.JoinRewriteLifecycleListener<2147483647>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RequestCycleWrapper [org.ocpsoft.rewrite.servlet.impl.HttpRewriteRequestCycleWrapper<0>]
Information: Loaded [1] org.ocpsoft.rewrite.spi.RewriteProvider [org.ocpsoft.rewrite.servlet.impl.DefaultHttpRewriteProvider<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RewriteResultHandler [org.ocpsoft.rewrite.servlet.impl.HttpRewriteResultHandler<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.InboundRewriteProducer [org.ocpsoft.rewrite.servlet.impl.HttpInboundRewriteProducer<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.OutboundRewriteProducer [org.ocpsoft.rewrite.servlet.impl.HttpOutboundRewriteProducer<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.ContextListener [org.ocpsoft.rewrite.prettyfaces.PrettyConfigContextListener<0>]
Information: Loaded [0] org.ocpsoft.rewrite.servlet.spi.RequestListener []
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RequestParameterProvider [org.ocpsoft.rewrite.prettyfaces.PrettyFacesRequestParameterProvider<0>]
Information: Loaded [1] org.ocpsoft.rewrite.el.spi.ExpressionLanguageProvider [org.ocpsoft.rewrite.faces.FacesExpressionLanguageProvider<30>]
Information: Loaded [1] org.ocpsoft.rewrite.spi.InvocationResultHandler [org.ocpsoft.rewrite.faces.NavigatingInvocationResultHandler<100>]
Information: Loaded [0] org.ocpsoft.common.spi.ServiceEnricher []
Information: Loaded [1] org.ocpsoft.rewrite.spi.ConfigurationCacheProvider [org.ocpsoft.rewrite.servlet.impl.ServletContextConfigurationCacheProvider<0>]
Information: Loaded [2] org.ocpsoft.rewrite.config.ConfigurationProvider [org.ocpsoft.rewrite.annotation.config.AnnotationConfigProvider<100>, org.ocpsoft.rewrite.prettyfaces.PrettyFacesRewriteConfigurationProvider<1>]
Information: Loaded [0] org.ocpsoft.rewrite.spi.RuleCacheProvider []
Information: Loaded [1] org.ocpsoft.rewrite.spi.GlobalParameterProvider [org.ocpsoft.rewrite.instance.WildcardParameterProvider<0>]
Information: Rewrite 3.4.1.Final initialized.
Information: Loading application XWars-ear#XWars-web-1.0.0-SNAPSHOT.war at [/xwars]
Information: XWars-ear was successfully deployed in 10.439 milliseconds.






[GLASSFISH-21563] BATCH CLI: asadmin list-batch-jobs/list-batch-job-executions (with long option) is slow if a large number of jobs are stored in DB Created: 20/Sep/16  Updated: 20/Sep/16

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

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

Windows, Oracle12c



 Description   

I found that asadmin list-batch-jobs/list-batch-job-executions (with -l option) command freezes for around 80--120 seconds in my environment. There are 3000 job executions in the remote job DB host (Oracle12c). I understand deleting job in the DB makes the command replies faster, but I'm afraid it might be a bother if we need to keep always the number of jobs below several dozens or several hundreds in the DB.



 Comments   
Comment by kunisada [ 20/Sep/16 ]

I found some methods such as 'JobExecution#getBatchStatus()' etc. are relatively heavy because they establish a DB connection and submit a SQL statement on every call.

The following patch reduces them by keeping method-results in local values if possible.

https://gist.github.com/k2sd/869aeb6cf6092c9c6565687f5e06b708

The modification is very small but it improves performance by 20--30% on listing jobs (I know it's still too long though..).





[GLASSFISH-21562] Changing the default value to set upper bounds of pool size of ManagedExecutorService and ManagedScheduledExecutorService Created: 16/Sep/16  Updated: 16/Sep/16

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

Type: Improvement Priority: Major
Reporter: uno_kohei Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The default value of the configuration of the ManagedExecutorService is
set as follows.

ManagedExecutorService default value
core-pool-size 0
maximum-pool-size 2147483647 (Integer.MAX_VALUE)

The default value of the configuration of the ManagedScheduledExecutorService is set as follows.

ManagedScheduledExecutorService default value
core-pool-size 0

(maximum-pool-size does not exist in the ManagedScheduledExecutorService)

At the above-mentioned setting, there is no upper bounds of the number of threads in the thread pool of the ManagedExecutorService or ManagedScheduledExecutorService.
Therefore, a large amount of threads may be created by mistake of the application, and there is a risk of excessively consuming the resource of the server.

I hope to set upper bounds of the number of threads in the thread pool by changing the default value of the configuration of the ManagedExecutorService or ManagedScheduledExecutorService as follows. (64 is an example value enough for usual use)

ManagedExecutorService default value
core-pool-size 64
maximum-pool-size 64
ManagedScheduledExecutorService default value
core-pool-size 64





[GLASSFISH-21561] The warning message "AS-CONCURRENT-00001" is written to server.log many times. Created: 15/Sep/16  Updated: 15/Sep/16

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

Type: Bug Priority: Major
Reporter: uno_kohei Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

User application submits a task to ManagedExecutorService or ManagedScheduledExecutorService.
Once the task processing time exceeds the "hung-after-seconds" value of ManagedExecutorService or ManagedScheduledExecutorService, a warning message "AS-CONCURRENT-00001" is written to server.log file repeatedly every minute until the task finishes.

When a lot of tasks do hang, a large amount of same "AS-CONCURRENT-00001" messages are written to server.log file.
In that case, there is a risk that other important messages are missed or lost by rotating the server.log file.

Therefore, I hope to change behavior so that the "AS-CONCURRENT-00001" message is written only once for each task when the task processing time exceeds the "hung-after-seconds".

I also hope to maintain compatibility by adding an additional property to ManagedExecutorService and ManagedScheduledExecutorService, so user can specify the behavior when the task processing time exceeds the "hung-after-seconds".

The "hung-after-seconds" value of ManagedExecutorService can be specified by the command below:

asadmin set resources.managed-executor-service.<jndi-name>.hung-after-seconds





[GLASSFISH-21443] Impossible to create a mail session Created: 16/Oct/15  Updated: 14/Sep/16

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

Type: Bug Priority: Major
Reporter: mbutton Assignee: Anissa Lam
Resolution: Unresolved Votes: 6
Labels: mail
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Enterprise Linux Server release 6.6 (Santiago)


Issue Links:
Duplicate
is duplicated by GLASSFISH-21437 Can't create new JDBC Resource from a... Closed
is duplicated by GLASSFISH-21444 error java.lang.RuntimeException Closed

 Description   

Context :
JVM invocation command line:
/logiciels/jdk1.8.0_60/bin/java [ ... ]
Running GlassFish Version: GlassFish Server Open Source Edition 4.1.1 (build 1)]]

Hi, I've freshly installed the GlassFish 4.1.1.
I then ran those commands :

asadmin create-domain myDomain
asadmin start-domain myDomain
asadmin --host localhost --port 4848 enable-secure-admin

When I log in to the admin console, I'm trying to create a mail session, and I get a "class java.lang.RuntimeException" message.
In the log file, I can see :

[2015-10-16T11:41:27.535+0200] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=96 _ThreadName=admin-listener(8)] [timeMillis: 1444988487535] [levelValue: 800] [[
Exception Occurred :null]]

[2015-10-16T11:41:27.541+0200] [glassfish 4.1] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=96 _ThreadName=admin-listener(8)] [timeMillis: 1444988487541] [levelValue: 1000] [[
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event143'.
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.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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor158.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 60 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 65 more
]]



 Comments   
Comment by mbutton [ 16/Oct/15 ]

I also tried with a 5.0 beta, and it's the same result.

However, I just confirmed that it is correctly working with 3.1.2.2 (build 5).

Comment by Romain Grécourt [ 16/Oct/15 ]

Looking at the stack trace you tried to create a mail session using the admin console.

Can you try against GF 4.0 and 4.1 ?
Can you also try using jdk7 ?

Thanks.

Comment by mbutton [ 20/Oct/15 ]

Bonjour Romain,

you're right : I tried to create a mail session through the admin console.

I first tried with a JDK 7, and then when I encountered the problem, I read about the recommandations, which were :
Java EE 7 requires JDK 7 or above, JDK 8 u60 or above is recommended for GlassFish 4.1.1

I then decided to try with a JDK 8u60, and since it didn't fix my problem, I opened that case.
Now, everything is working fine with a GF 3.1.2.2, but I unfortunately have no more time to spend on the subject (thus, I won't be able to test against GF 4.0 & 4.1)
I just thought it would be useful for the community to know about that regression.

Thanks.

Comment by ekremkucuk [ 25/Dec/15 ]

I had similar problem.

I have started glassfish 4.1.1 instance as usual running with JDK 1.8.0_65

I have clicked Resources -> Java Mail Sessions

On right frame "class java.lang.RuntimeException" is written on blank page.

On Console:

2015-12-25T18:32:04.324+0200|Info: Exception Occurred :null
2015-12-25T18:32:04.328+0200|Severe: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event144'.
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.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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 51 more

Comment by fmateo [ 22/Jan/16 ]

This problem is not just for mail session. There is a similar exception for every "New" operation using the web console.
I have confirmed that this was working ok on Glassfish 4.0 and 4.1.

Comment by enot [ 14/Sep/16 ]

Seems the bug is in REST client. RestUtil class uses the "OPTIONS" method to get json response, from the nucleus management service, violating the REST specification. I changed the request method to "GET" to fix this issue.
A week of debugging and here is the patch

glassfish-21443.patch
Index: RestUtil.java
===================================================================
--- RestUtil.java	(revision 64298)
+++ RestUtil.java	(working copy)
@@ -320,7 +320,7 @@
     public static Map<String, String> buildDefaultValueMap(String endpoint) throws ParserConfigurationException, SAXException, IOException {
         Map<String, String> defaultValues = new HashMap<String, String>();
 
-        RestResponse response = options(endpoint, "application/json");
+        RestResponse response = get(endpoint);
         //System.out.println("=========== response.getResponse():\n " + response.getResponse());
         Map<String, Object> data = (Map<String, Object>) response.getResponse().get("data");
         List<Map<String, Object>> methods = null;




[GLASSFISH-21299] GlassFish looses connection pool Created: 05/Feb/15  Updated: 14/Sep/16

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

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


 Description   

Our app is talking to a PostgreSQL database via JPA layer, and when under load it intermittently looses the connection pool entirely.

Our production setup is running with GlassFish 4.0 b89 (we are unable to move or test on 4.1 due to GlassFish-21114).

We have tested with postgresql drivers 9.3-1102.jdbc41 and 9.4-1200.jdbc41, and we have tried substituting baked in eclipselink version for 2.5.2.v20140319, all to no avail.

Any suggestions as to what could be the cause of this?

Stacktrace:

[2015-02-05T15:15:45.649+0100] [glassfish 4.0] [INFO] [] [dk.dbc.dataio.commons.utils.service.AbstractMessageConsumerBean] [tid: _ThreadID=92 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1423145745649] [levelValue: 800] [[
Validating message<ID:1073-127.0.1.1(b3:7d:c0:af:d7:e0)-1-1423145745644> with deliveryCount=1]]

[2015-02-05T15:15:45.651+0100] [glassfish 4.0] [INFO] [] [dk.dbc.dataio.sink.utils.messageproducer.JobProcessorMessageProducerBean] [tid: _ThreadID=92 _ThreadName=p: thread-pool-1; w: 5] [timeMillis: 1423145745651] [levelValue: 800] [[
Sending delivered Chunk 215 for job 1]]

[2015-02-05T15:15:45.758+0100] [glassfish 4.0] [INFO] [] [dk.dbc.dataio.commons.utils.service.AbstractMessageConsumerBean] [tid: _ThreadID=163 _ThreadName=p: thread-pool-1; w: 7] [timeMillis: 1423145745758] [levelValue: 800] [[
Validating message<ID:1078-127.0.1.1(b3:7d:c0:af:d7:e0)-1-1423145745751> with deliveryCount=1]]

[2015-02-05T15:15:45.760+0100] [glassfish 4.0] [INFO] [] [dk.dbc.dataio.sink.utils.messageproducer.JobProcessorMessageProducerBean] [tid: _ThreadID=163 _ThreadName=p: thread-pool-1; w: 7] [timeMillis: 1423145745760] [levelValue: 800] [[
Sending delivered Chunk 216 for job 1]]

[2015-02-05T15:15:45.786+0100] [glassfish 4.0] [WARNING] [jdbc.pool_not_reachable] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745786] [levelValue: 900] [[
RAR7010: Pool not reachable. ]]

[2015-02-05T15:15:45.787+0100] [glassfish 4.0] [WARNING] [] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745787] [levelValue: 900] [[
jdbc.exc_get_conn]]

[2015-02-05T15:15:45.795+0100] [glassfish 4.0] [WARNING] [] [org.eclipse.persistence.session.file:/home/jbn/dev/repos/dataio/integration-test/glassfish/home/glassfish4/glassfish/domains/domain1/applications/new-job-store-service/WEB-INF/lib/dataio-new-job-store-service-ejb-1.0-SNAPSHOT.jar_jobstorePU] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745795] [levelValue: 900] [[

Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
Error Code: 0
Call: UPDATE job SET PARTNUMBER = ? WHERE (ID = ?)
bind => [2 parameters bound]
Query: UpdateObjectQuery(dk.dbc.dataio.jobstore.service.entity.JobEntity@6393c78b)
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:316)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:135)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:307)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1619)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:613)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:296)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.updateObject(DatasourceCallQueryMechanism.java:797)
at org.eclipse.persistence.internal.queries.StatementQueryMechanism.updateObject(StatementQueryMechanism.java:435)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1057)
at org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1730)
at org.eclipse.persistence.internal.sessions.CommitManager.commitChangedObjectsForClassWithChangeSet(CommitManager.java:267)
at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:130)
at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4200)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1529)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3166)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:352)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:158)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:452)
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.$Proxy262.addChunkProcessed(Unknown Source)
at dk.dbc.dataio.jobstore.service.ejb._EJB31_GeneratedJobsBeanIntf__Bean_.addChunkProcessed(Unknown Source)
at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1625)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnection(ConnectorRuntime.java:639)
at org.glassfish.jdbcruntime.service.JdbcDataSource.getConnection(JdbcDataSource.java:86)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:123)
... 96 more
Caused by: javax.resource.ResourceException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:661)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1617)
... 99 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: This pool is not bound in JNDI : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1093)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:989)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:654)
... 100 more
Caused by: javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/jdbc/dataio/jobstore/pool' 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: pool not found]
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.resourcebase.resources.naming.ResourceNamingService.lookup(ResourceNamingService.java:238)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnectorConnectionPool(ConnectorConnectionPoolAdminServiceImpl.java:876)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1009)
... 102 more
Caused by: javax.naming.NameNotFoundException: pool not found
at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
... 108 more
]]

[2015-02-05T15:15:45.803+0100] [glassfish 4.0] [WARNING] [enterprise_distributedtx.before_completion_excep] [javax.enterprise.resource.jta.com.sun.enterprise.transaction] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745803] [levelValue: 900] [[
DTX5014: Caught exception in beforeCompletion() callback:
javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
Error Code: 0
Call: UPDATE job SET PARTNUMBER = ? WHERE (ID = ?)
bind => [2 parameters bound]
Query: UpdateObjectQuery(dk.dbc.dataio.jobstore.service.entity.JobEntity@6393c78b)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl$1.handleException(EntityManagerSetupImpl.java:692)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.handleException(AbstractSynchronizationListener.java:275)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:170)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:452)
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.$Proxy262.addChunkProcessed(Unknown Source)
at dk.dbc.dataio.jobstore.service.ejb._EJB31_GeneratedJobsBeanIntf__Bean_.addChunkProcessed(Unknown Source)
at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
Error Code: 0
Call: UPDATE job SET PARTNUMBER = ? WHERE (ID = ?)
bind => [2 parameters bound]
Query: UpdateObjectQuery(dk.dbc.dataio.jobstore.service.entity.JobEntity@6393c78b)
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:316)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:135)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:307)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1619)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:613)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:296)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.updateObject(DatasourceCallQueryMechanism.java:797)
at org.eclipse.persistence.internal.queries.StatementQueryMechanism.updateObject(StatementQueryMechanism.java:435)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1057)
at org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1730)
at org.eclipse.persistence.internal.sessions.CommitManager.commitChangedObjectsForClassWithChangeSet(CommitManager.java:267)
at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:130)
at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4200)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1529)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3166)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:352)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:158)
... 62 more
Caused by: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1625)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnection(ConnectorRuntime.java:639)
at org.glassfish.jdbcruntime.service.JdbcDataSource.getConnection(JdbcDataSource.java:86)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:123)
... 96 more
Caused by: javax.resource.ResourceException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:661)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1617)
... 99 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: This pool is not bound in JNDI : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1093)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:989)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:654)
... 100 more
Caused by: javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/jdbc/dataio/jobstore/pool' 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: pool not found]
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.resourcebase.resources.naming.ResourceNamingService.lookup(ResourceNamingService.java:238)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnectorConnectionPool(ConnectorConnectionPoolAdminServiceImpl.java:876)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1009)
... 102 more
Caused by: javax.naming.NameNotFoundException: pool not found
at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
... 108 more
]]

[2015-02-05T15:15:45.808+0100] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745808] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB JobsBean, method: public javax.ws.rs.core.Response dk.dbc.dataio.jobstore.service.ejb.JobsBean.addChunkProcessed(javax.ws.rs.core.UriInfo,java.lang.String,long,long) throws dk.dbc.dataio.jsonb.JSONBException,dk.dbc.dataio.jobstore.types.JobStoreException]]

[2015-02-05T15:15:45.808+0100] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745808] [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.$Proxy262.addChunkProcessed(Unknown Source)
at dk.dbc.dataio.jobstore.service.ejb._EJB31_GeneratedJobsBeanIntf__Bean_.addChunkProcessed(Unknown Source)
at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.transaction.RollbackException: Transaction marked for rollback.
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:490)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
... 58 more
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
Error Code: 0
Call: UPDATE job SET PARTNUMBER = ? WHERE (ID = ?)
bind => [2 parameters bound]
Query: UpdateObjectQuery(dk.dbc.dataio.jobstore.service.entity.JobEntity@6393c78b)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl$1.handleException(EntityManagerSetupImpl.java:692)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.handleException(AbstractSynchronizationListener.java:275)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:170)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:452)
... 60 more
Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
Error Code: 0
Call: UPDATE job SET PARTNUMBER = ? WHERE (ID = ?)
bind => [2 parameters bound]
Query: UpdateObjectQuery(dk.dbc.dataio.jobstore.service.entity.JobEntity@6393c78b)
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:316)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:135)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:307)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1619)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:613)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:296)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.updateObject(DatasourceCallQueryMechanism.java:797)
at org.eclipse.persistence.internal.queries.StatementQueryMechanism.updateObject(StatementQueryMechanism.java:435)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1057)
at org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1730)
at org.eclipse.persistence.internal.sessions.CommitManager.commitChangedObjectsForClassWithChangeSet(CommitManager.java:267)
at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:130)
at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4200)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1529)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3166)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:352)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:158)
... 62 more
Caused by: java.sql.SQLException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1625)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnection(ConnectorRuntime.java:639)
at org.glassfish.jdbcruntime.service.JdbcDataSource.getConnection(JdbcDataSource.java:86)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:123)
... 96 more
Caused by: javax.resource.ResourceException: This pool is not registered with the runtime environment : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:661)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1617)
... 99 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: This pool is not bound in JNDI : jdbc/dataio/jobstore/pool
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1093)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:989)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:654)
... 100 more
Caused by: javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/jdbc/dataio/jobstore/pool' 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: pool not found]
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.resourcebase.resources.naming.ResourceNamingService.lookup(ResourceNamingService.java:238)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnectorConnectionPool(ConnectorConnectionPoolAdminServiceImpl.java:876)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1009)
... 102 more
Caused by: javax.naming.NameNotFoundException: pool not found
at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
... 108 more
]]

[2015-02-05T15:15:45.815+0100] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=22 _ThreadName=http-listener-1(3)] [timeMillis: 1423145745815] [levelValue: 900] [[
StandardWrapperValve[dk.dbc.dataio.jobstore.service.rs.JobStoreApplication]: Servlet.service() for servlet dk.dbc.dataio.jobstore.service.rs.JobStoreApplication threw exception
javax.naming.NameNotFoundException: pool not found
at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
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.resourcebase.resources.naming.ResourceNamingService.lookup(ResourceNamingService.java:238)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnectorConnectionPool(ConnectorConnectionPoolAdminServiceImpl.java:876)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:1009)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.obtainManagedConnectionFactory(ConnectorConnectionPoolAdminServiceImpl.java:989)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:654)
at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getConnection(ConnectorConnectionPoolAdminServiceImpl.java:1617)
at com.sun.enterprise.connectors.ConnectorRuntime.getConnection(ConnectorRuntime.java:639)
at org.glassfish.jdbcruntime.service.JdbcDataSource.getConnection(JdbcDataSource.java:86)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:123)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:330)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:307)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:565)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1619)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:305)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:613)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:296)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.updateObject(DatasourceCallQueryMechanism.java:797)
at org.eclipse.persistence.internal.queries.StatementQueryMechanism.updateObject(StatementQueryMechanism.java:435)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1057)
at org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84)
at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1730)
at org.eclipse.persistence.internal.sessions.CommitManager.commitChangedObjectsForClassWithChangeSet(CommitManager.java:267)
at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:130)
at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4200)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1529)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3166)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:352)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:158)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:452)
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.$Proxy262.addChunkProcessed(Unknown Source)
at dk.dbc.dataio.jobstore.service.ejb._EJB31_GeneratedJobsBeanIntf__Bean_.addChunkProcessed(Unknown Source)
at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
]]



 Comments   
Comment by dbcjbn [ 01/Jun/15 ]

Turned out this was a case of a malformed domain.xml. The resources were there, but the resource-ref was missing. Behaviour still seems a bit odd, though.

Comment by muellermi [ 14/Sep/16 ]

We frequently faces the same or similar problem using Microsoft SQL Server. If traffic goes high, then GlassFish looses the connection pool-

Comment by muellermi [ 14/Sep/16 ]

Affects 4.1 and 4.1.1 too.





[GLASSFISH-21560] "asadmin list-logger-levels" does not list java.util.logging.ConsoleHandler Created: 13/Sep/16  Updated: 13/Sep/16

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

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

Mac OS X: Yosemite 10.10.5
NetBeans8.1
Glassfish4.1.1 (and same with Glassfish4.1 or Payara 4.1.1.163)



 Description   

Given as docs component here but may be a bug.

The docs I refer to are:

GlassFish Server Open Source Edition
Administration Guide
Release 4.0

The docs (and the help list-log-levels both give java.util.logging.ConsoleHandler in the output example:

Glassfish4 admin guide:

Example 7–3 Listing Logger Levels for Modules
This example shows a partial list of the existing loggers and their log levels in the
DAS.

asadmin> list-log-levels
javax.enterprise.system.container.cmp <INFO>
javax.enterprise.system.tools.admin <INFO>
java.util.logging.ConsoleHandler <FINEST>
javax.enterprise.system.container.web <INFO>
javax.enterprise.system.util <INFO>
javax.enterprise.resource.webcontainer.jsf.timing <INFO>
javax <INFO>
javax.enterprise.resource.corba <INFO>
...
Command list-log-levels executed successfully.

When I perform this with or without a server target the java.util.logging.ConsoleHandler does not appear:

asadmin> list-log-levels server
ShoalLogger	<CONFIG>
 
 
javax.enterprise.resource.corba	<INFO>
javax.enterprise.resource.javamail	<INFO>
javax.enterprise.resource.jdo	<INFO>
javax.enterprise.resource.jms	<INFO>
javax.enterprise.resource.jta	<INFO>
javax.enterprise.resource.resourceadapter	<INFO>
...

I can change it in the domain1/domain/config/logging.properties, but then I have to restart:

$ grep Console /Applications/NetBeans-8.1/glassfish-4.1.1/glassfish/domains/domain1/config/logging.properties 
 
handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.formatter=com.sun.enterprise.server.logging.UniformLogFormatter
com.sun.enterprise.server.logging.GFFileHandler.logtoConsole=false
java.util.logging.ConsoleHandler.level=FINEST

This executes without error but does not seem to do anything, and the Console logger still does not appear in the list:

Example 7–5 Changing the Global Log Level for All Module Loggers

By setting the log level of the ConsoleHandler, you set the global log level for all
loggers. This example sets the global log level in the DAS to INFO:

asadmin> set-log-levels java.util.logging.ConsoleHandler=INFO
java.util.logging.ConsoleHandler package set with log level INFO.
These logging levels are set for server.
Command set-log-levels executed successfully.





[GLASSFISH-21559] Deployment of web from NB8.1 takes ages (over 10 mins) AND on Payara Server 4.1.1.163 (over 20 minutes ) Created: 13/Sep/16  Updated: 13/Sep/16

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

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

Mac OS X: Yosemite 10.10.5
NetBeans8.1
Glassfish4.1.1
Mojarra 2.2.12 OR Mojarra 2.2.18 (same result)
ObjectDB as JPA provider



 Description   

Reported also as:


Reported here as a BUG because the other categories did not quite fit.
Major, because it effectively completely prevents practical development.

Because of this issue with Glassfish4.1.1 I have kept (am trapped) using the following for development of a certain large web app, because the problem does not happen with Glassfish4.1:

NetBeans8.1beta
Glassfish4.1
Mojarra 2.2.7 (or other more recent, same result)

With a very large JSF web app I am experiencing massively longer deployment times to Glassfish4.1.1 (over 10 minutes) than to Glassfish4.1 (around 2 minutes). That's about 5 times slower, and utterly impractical. Nothing has changed in the code, it's the exact same web app.

(I also tried with Payara 163 Full (Payara Server 4.1.1.163) and it took over 20 minutes, even slower than on Glassfish4.1.1, with an identical setup.)

I can't possibly reproduce here or provide examples of the large web app, not least because using the commercial ObjectDB as JPA provider requires a licence, and it can't be simply swapped out with another JPA-compliant DB provider (because, for example, other providers can't handle enough entity classes), and for commercial reasons

I tried to investigate it by using the NetBeans Profiler, but could not find the cause.

I have also tried Glassfish logging (which I use frequently and command well) and all I could see so far is the same steps taking painfully longer than usual.

I am even using screencasting to try to time it and find the main point of slowness, it just seem to be slow across the board at every step so far.

I am nearly at the point now of giving up on Glassfish forever, and Payara 163 Full seems to have been spawned from a version with the same problem, leaving me little choice but to use something like Wildfly or TomEE (with considerably more migration effort).

I would be grateful if somebody could please at least explain:

  • What changed since Glassfish4.1 that might have caused it.
  • Other things I could diagnose to find the point of difference.





[GLASSFISH-21558] Secured EJB lookup fails after AppClientContainer instantiation Created: 07/Sep/16  Updated: 09/Sep/16

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

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


 Description   

We followed the documentation at https://docs.oracle.com/cd/E19226-01/820-7695/gipkt/index.html to set up a standalone ACC-Client application.

Although the callback-handler in the META-INF/application-client.xml is configured properly, the lookup for a secured SLSB fails and the handler is never called.

The lookup for unsecured SLSB works as expected.

Sep 07, 2016 12:28:26 PM com.sun.enterprise.iiop.security.SecurityMechanismSelector getUsernameAndPassword
SCHWERWIEGEND: IIOP1001: Exception getting username and password
java.lang.SecurityException: java.io.IOException: Konfigurationsfehler:
	Datei oder Verzeichnis nicht vorhanden
	at sun.security.provider.ConfigFile$Spi.<init>(ConfigFile.java:137)
	at sun.security.provider.ConfigFile.<init>(ConfigFile.java:102)


 Comments   
Comment by andydr [ 07/Sep/16 ]

If the AppClientContainer is instantiated via AppClientContainer.Builder#newContainer(ClientModule.class) we get the following exception

Sep 07, 2016 2:15:20 PM com.sun.enterprise.deployment.archivist.Archivist readAnnotations
SCHWERWIEGEND: com.sun.proxy.$Proxy25 cannot be cast to javax.ejb.EJB
SCHWERWIEGEND: null
java.lang.IllegalStateException: com.sun.proxy.$Proxy25 cannot be cast to javax.ejb.EJB. Related annotation information: annotation [@javax.ejb.EJB(name=, lookup=, description=, beanName=, beanInterface=class java.lang.Object, mappedName=)] on annotated element [private static de.ejb.UserBeanRemote de.client.ClientModule.userBean] of type [FIELD]
	at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:519)

The field in the ClientModule class is defined as

@EJB
private static UserBeanRemote userBean;
Comment by andydr [ 09/Sep/16 ]

The java.lang.SecurityException was a configuration issue, but the EJB injection problem still remains.

Comment by andydr [ 09/Sep/16 ]

We figured out, that the ACC module runs, if we start it via command 'appclient -client <accmodule.jar>'.

The ACC Container startup project is maven based and requires the following dependency, which seems not sufficient

  <dependency>
            <groupId>org.glassfish.main.appclient</groupId>
            <artifactId>gf-client</artifactId>
            <version>4.1.1</version>
   </dependency>

Do we need other dependencies?





[GLASSFISH-21557] 'list-batch-jobs -l' shows instance counts more than expected Created: 07/Sep/16  Updated: 07/Sep/16

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

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

windows,jdk1.7.0_51



 Description   

asadmin list-batch-jobs -l shows an instance count that is more than expected.

To reproduce:

  • Need 2 clusters (clusterA, clusterB)
  • Both clusters have their own JDBC resource that refers to the same JDBC connection pool.
  • Both clusters use the same name job XML.
  • Submit some jobs on each cluster respectively.
  • asadmin list-batch-jobs -l --target clusterA

In another words, If two or more clusters uses the same-name jobXML and the
same JDBC connection pool, the job instance count will be the sum total of each cluster's. The '--long' option is mandatory to reproduce this bug.

I think the value specified by the '-target' is ignored when the list-batch-jobs command is executed with the '-long' option. It's necessary to take into account the target option when counting job instances.






[GLASSFISH-19475] "Connection closed" despite connection validation Created: 21/Dec/12  Updated: 05/Sep/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: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2 b23 on CentOS 6.2 x86_64
Oracle 10.2.0.5 RAC ia64, 2 nodes


Tags: closed, connection, validation

 Description   

We were having occasional connection problems and therefore switched on connection validation, with a dummy query to DUAL. It validates at most every 60 seconds and will not close all connections on failure.

However, it seems that ConnectionHolder.checkValidity() throws a 'connection closed' which then goes all the way to the application. I was in belief that connection validation was the thing exactly designed to prevent this, is it not? If validation failed, it would automatically reconnect before handing out the connection?

The connection is indeed validated, but there's no effort to fix the connection when the validation fails:

[#|2012-12-21T04:56:03.707+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=45;_ThreadName=Thread-2;|
        at fi.foo.bar.AvepsiKuittausDAO.hae(AvepsiKuittausDAO.java:67)
        at fi.foo.bar.AvepsiSanomaKasittelija.hae(AvepsiSanomaKasittelija.java:56)
        at sun.reflect.GeneratedMethodAccessor222.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 $Proxy244.hae(Unknown Source)
        at fi.foo.bar.__EJB31_Generated__AvepsiSanomaKasittelija__Intf____Bean__.hae(Unknown Source)
        at fi.foo.bar.baz.JmsToXml.<init>(JmsToXml.java:70)
        at fi.foo.bar.baz.PerusvalvontadataKasittelijaMDB.onMessage(PerusvalvontadataKasittelijaMDB.java:87)
        at sun.reflect.GeneratedMethodAccessor676.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 $Proxy333.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: org.hibernate.exception.GenericJDBCException: could not load an entity:
[fi.foo.bar.AvepsiKuittaus#component[sanomaId,kasittelija]{kasittelija=Perusvalvonta, sanomaId=69618960}]
        at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:140)
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:128)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
        at org.hibernate.loader.Loader.loadEntity(Loader.java:2041)
        at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
        at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
        at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293)
        at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
        at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
        at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
        at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
        at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
        at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090)
        at org.hibernate.impl.SessionImpl.get(SessionImpl.java:1005)
        at org.hibernate.impl.SessionImpl.get(SessionImpl.java:998)
        at fi.foo.bar.AvepsiKuittausDAO.hae(AvepsiKuittausDAO.java:59)
        ... 42 more
Caused by: java.sql.SQLException: Connection closed
        at com.sun.gjc.spi.base.ConnectionHolder.checkValidity(ConnectionHolder.java:730)
        at com.sun.gjc.spi.base.ConnectionHolder.prepareStatement(ConnectionHolder.java:560)
        at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:255)
        at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareCachedStatement(ConnectionWrapper40.java:52)
        at com.sun.gjc.spi.ManagedConnection.prepareCachedStatement(ManagedConnection.java:993)
        at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.prepareStatement(ConnectionWrapper40.java:173)
        at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:534)
        at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:452)
        at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161)
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1700)
        at org.hibernate.loader.Loader.doQuery(Loader.java:801)
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
        at org.hibernate.loader.Loader.loadEntity(Loader.java:2037)
        ... 54 more
|#]


 Comments   
Comment by jifeng [ 01/Mar/13 ]

if you execute the following logic in you application :
step1: connection.close();

step2: connection.prepareStatement();

there will be throw this exception :

Caused by: java.sql.SQLException: Connection closed
at com.sun.gjc.spi.base.ConnectionHolder.checkValidity(ConnectionHolder.java:730)

because the logic connectin(connectionHolder) is closed
ConnectionHolder.checkValidity() is used to check the connection is closed or not

Comment by Heikki Salokanto [ 01/Mar/13 ]

Quite obviously, yes, but we are never doing a connection.close() in the application. Connections are pooled and the JDBC Connection Pools are managed by GlassFish. It opens new connections as required and closes those that have been idle for some time.

The problem here is that the connections are getting closed suddenly for an unknown reason and GlassFish's connection validator is not capable of handling that. Connections getting closed suddenly also looks like a GlassFish problem since we're not experiencing that with any other (sort of) application.

Comment by sfelts [ 01/Mar/13 ]

This is working as expected. Based on the stack trace, you are not in the process of getting a connection. You are in the process of using a connection that you already reserved to do a prepared statement. Since GF and the driver don't know what other operations have been executed on the connection before this, we can't just give out a new connection and hope that everything is OK.

To do something like that, you would need to run with the Application continuity feature that was announced at Oracle Open World for Oracle 12c. In that case, the driver and database actually do keep track of what has been executed on the connection so it can be replayed on the new connection.

Comment by hrstoyanov [ 09/Mar/13 ]

This is, indeed, a major bug in GlassFish Server Open Source Edition 3.1.2.2 (build 5). The workaround that works for me is to disable statement cache (Statement Cache Size: 0, Advanced Tab) - the behaviour of this mug made me believe that this is some statements cache mess. Note, that I have not configured connection validation as described in the initial bug report, neverthless, the issue is still present.

Here is another manifestation of the same issue as seen in the SmartGWT product:

http://forums.smartclient.com/showthread.php?t=25771

"...Best guess, this is an application server or JDBC driver bug or misconfiguration at the JDBC driver or application server level, hence out of our control.

What's happening is: we successfully execute your SQL ("INSERT INTO batch_job_share...") using PreparedStatement.executeUpdate(). Then, a few lines later, using the same preparedStatement object, we are calling preparedStatement.getConnection().getMetaData().

At this point, your JDBC driver - well actually, some wrapper around it, looks like a manager class from Glassfish? - throws an Exception indicating the connection we just successfully used for an update is now closed. So it seems like it's either configured to auto-close connections right after certain SQL operations are executed, or your JDBC driver has some kind of bug where it get mixed up about which Connection belongs with which Statement, or the wrapper classes in use are not correctly tracking the open/closed state of the wrapped connections."

Comment by sfelts [ 09/Mar/13 ]

The connection close is not caused by the connection validation feature. My point was that turning on the connection validation feature doesn't prevent this from happening.

Here's an example that I ran into this week with the Oracle thin driver. The application configured oracle.jdbc.ReadTimeout. When the database was slow and the read timeout was exceeded, the applcation got a mysterious "SQLRecoverableException: Closed Connection".

I have also found that the expected new JDBC auto-close behavior leads to some surprises (IMO) but I don't think that is the case here.

If the driver has a debug feature to log all SQL operations, that would be the way to check if close is explicitly closed.

Comment by Heikki Salokanto [ 12/Mar/13 ]

Thank you for your ideas.

hrstoyanov: Last time I tried, setting up statement caching on the Advanced tab just completely messed up everything. I found out on some forums that it has to be configured on the Additional properties tab with "ImplicitCachingEnabled=true" and "MaxStatements=nnn". At least it didn't fill up all the logs with errors anymore, but I never benchmarked if it was actually in use then.

sfelts: I wasn't saying that 'Connection closed' was caused by the connection validation, but despite it. I now understand that it cannot solve the problem, in the current design at least.

I am running out of ideas, though. I'm getting the occasional 'Connection closed' on different application servers (physical servers, virtual servers), different Oracle RACs (10.2.0.5 and 11.2.0.3), different Oracle JDBC drivers (10.2.0.5 and 11.2.0.3) as well as with and without statement caching. The only thing common to all the setups is now GlassFish 3.1.2.2 (build 5).

Furthermore, I am not getting my connections closed in a Tomcat webapp using the same databases and drivers.

Comment by hrstoyanov [ 14/Mar/13 ]

sfelts:
1. I am using MS SQL JDBC Type 4 driver
2. It can not be a timing issue (look at the URL I provided and description of events). The SmartGWT comments indicated error in the Wrpper/Caching , which lead me to teh workaround.

Comment by samyomar82 [ 27/Jul/14 ]

Currently I am facing the same issue , (using GF 3.1.2.2 and Oracle 10G)
I am getting my Connection object from GlassFish connection Pool and I get this issue when the result set expected to return around 1/2 million records, but I did not get this exception when the result set contains lower set of records.

My poor workaround is to use a traditional JDBC connection instead of getting the connection object from Data Source It worked fine.

Has anybody a solution or workaround ?
Also we dont know if this bug is going to be fixed or not

Comment by joyli [ 30/Dec/15 ]

We have the same problem,used the prepareStatement database connection to get the getMetaData,
“Initial and Minimum Pool Size:” 、“Maximum Pool Size:” and “Statement Cache Size:” are 1,
code:
DataSource dn = (DataSource) initContext.lookup("DB");
Connection ccon = dn.getConnection();
PrepareStatement pstam = ccon.prepareStatement(sql);
ResultSet rs = pstam.executeQuery();
pstam.getConnection().getMetaData();

the concurrent situation,appear:
java.sql.SQLException: Connection closed
at com.sun.gjc.spi.base.ConnectionHolder.checkValidity(ConnectionHolder.java:774)
at com.sun.gjc.spi.base.ConnectionHolder.getMetaData(ConnectionHolder.java:388)
at com.sun.gjc.spi.jdbc40.ConnectionWrapper40.getMetaData(ConnectionWrapper40.java:114)
at jdbc1.Servese1.serverdd(Servese1.java:122)
at jdbc1.Servese1.doGet(Servese1.java:58)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:336)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:236)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
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:619)

Comment by joyli [ 04/Jan/16 ]

Glassfish 4.1 has the same problem.

Comment by sahlix [ 19/Aug/16 ]

I had the same problem on GF 4.1.1. After updating the oracle driver to version 11g 2.0.4.0 it vanished away without further interference!





[GLASSFISH-21556] java.lang.IllegalStateException: WELD-000341: Unable to load current conversations from the associated request, something went badly wrong when associate() was called Created: 26/Aug/16  Updated: 26/Aug/16

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

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

Glassfish 4.0



 Description   

At the present, I have a trouble with GlassFish 4.0. I don't know what
happen with it when I let it run for a long time without shutdown.
I just receive this exception:

2016-08-25T17:12:53.090+0700|Warning: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.IllegalStateException: WELD-000341: Unable to load current conversations from the associated request, something went badly wrong when associate() was called
at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:447)
at org.jboss.weld.servlet.ConversationContextActivator.deactivateConversationContext(ConversationContextActivator.java:145)
at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:274)
at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:139)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:5293)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:255)
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)

Can you help me resolve this exception?
Thanks for your help.






[GLASSFISH-20581] FileNotFoundException while uploading large file 174 MB Created: 28/May/13  Updated: 15/Aug/16

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

Type: Bug Priority: Major
Reporter: jitendra.c48 Assignee: michael.y.chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows7, restlet-jse-2.1.2, uploaded file size 174MB, Apache HTTPClient 4.2.5



 Description   

Simple bug to solve, I written a jersey web service, Send a large file to server from client. I am getting FileNotFoundException.
To bypass the exception, I create a tmp folder in specified path, i guess developer should use mkdirs().

The detailed stack trace is as follows

stacktrace in server log
SEVERE: java.io.FileNotFoundException: C:\Program Files (x86)\glassfish-3.1.2.2\glassfish\domains\domain1\generated\jsp\FinalRestPOC\tmp\upload__4bab405d_13ee546b58a__7ff2_00000059.tmp (The system cannot find the path specified)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:165)
	at org.apache.catalina.fileupload.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:201)
	at org.apache.catalina.fileupload.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:264)
	at org.apache.catalina.fileupload.ThresholdingOutputStream.write(ThresholdingOutputStream.java:170)
	at org.apache.catalina.fileupload.Streams.copy(Streams.java:144)
	at org.apache.catalina.fileupload.Streams.copy(Streams.java:107)
	at org.apache.catalina.fileupload.Multipart.initParts(Multipart.java:158)
	at org.apache.catalina.fileupload.Multipart.getPart(Multipart.java:194)
	at org.apache.catalina.connector.Request.getPart(Request.java:4091)
	at org.apache.catalina.connector.RequestFacade.getPart(RequestFacade.java:1126)
	at sun.reflect.GeneratedMethodAccessor189.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.jersey.server.impl.ThreadLocalInvoker.invoke(ThreadLocalInvoker.java:96)
	at com.sun.proxy.$Proxy116.getPart(Unknown Source)
	at cdac.medinfo.rest.server.WebService.serObj(WebService.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
	at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
	at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
	at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
	at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
	at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
	at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
	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)



 Comments   
Comment by jitendra.c48 [ 28/May/13 ]

In my web.xml
<multipart-config>
<location>/tmp</location>
<max-file-size>208488200000</max-file-size>
<max-request-size>418018841</max-request-size>
<file-size-threshold>1048576</file-size-threshold>
</multipart-config>

now i have a question on Bug itself.

Comment by ralfhauser [ 15/Aug/16 ]

See also https://issues.apache.org/jira/browse/IO-512





[GLASSFISH-21555] Application-scoped resources not bound in JNDI when deploying with version number Created: 12/Aug/16  Updated: 12/Aug/16

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

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

Confirmed on Windows 10, Mac OS X 10.11, CentOS 5.11


Tags: deployment, glassfish-resources.xml, version

 Description   

When deploying an application ear file using a version number the resources inside an included META-INF/glassfish-resources.xml file are not created in JNDI. When repeating this deployment without using a version number for the application, the resources are correctly bound.



 Comments   
Comment by Meatwad [ 12/Aug/16 ]

Section 1-9 of the Glassfish 4.1 Application Deployment Guide describes the process of deploying an application with a version number. I could not find any mention of this behavior there. Is it possible the documentation is missing this behavior or have I found a bug?

I am uploading a test case that demonstrates this behavior in a simple web service.





[GLASSFISH-21471] Oracle Database Change Notification (DCN/QCN) - java.lang.NoClassDefFoundError: oracle/jdbc/driver/OracleConnection Created: 26/Nov/15  Updated: 09/Aug/16

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

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

Glassfish 4.1, Oracle 11 XE, Linux Ubuntu 14



 Description   

I was trying to build a basic example with L2-Cache invalidation over Oracle Database Change Notification (DCN/QCN). Following the description from EclipseLink website: https://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/DatabaseEvents the following property was added to the persistence.xml:
<property
name="eclipselink.cache.database-event-listener" value="org.eclipse.persistence.platform.database.oracle.dcn.OracleChangeNotificationListener"/>
Since DCN is a custom Oracle extension the ojdbc6-11.2.0.2.0.jar was put into the directory domainname/lib/ext/. During deployment the following exception occures:
java.lang.NoClassDefFoundError: oracle/jdbc/driver/OracleConnection
at org.eclipse.persistence.platform.database.oracle.dcn.OracleChangeNotificationListener.register(OracleChangeNotificationListener.java:96)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:856)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:752)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:265)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:731)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:337)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:303)
at org.glassfish.persistence.jpa.JPADeployer$2.visitPUD(JPADeployer.java:451)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:510)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:492)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:398)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:487)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:487)
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:360)
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:360)
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 com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
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)
:



 Comments   
Comment by mvawork [ 09/Aug/16 ]

This is not GlassFish bug. You can see fix in the master branch EclipseLink (https://github.com/eclipse/eclipselink.runtime/commit/1e287f11c6e5671e208c38a730c0215d53b1926b#diff-977452f0fb90d57b6bf7d3069f2b0b76).





[GLASSFISH-20822] org.glassfish.jersey.internal.util.Base64.encode(byte[]) method doesn't work properly - it throws ArrayIndexOutOfBoundsException Created: 24/Sep/13  Updated: 08/Aug/16

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

Type: Bug Priority: Major
Reporter: Ruslan.Shchuchinov Assignee: michael.y.chen
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4, JDK 1.7.0_40, Windows 7


Tags: base64, glassfish4

 Description   

An implementation of encode(byte[]) method is completely wrong.

89 public static byte[] encode(byte[] buffer) {
90 int ccount = buffer.length / 3;
91 int rest = buffer.length % 3;
92 byte[] result = new byte[(ccount + (rest > 0 ? 1 : 0)) * 4];
93
94 for (int i = 0; i < ccount; i++)

{ 95 result[i * 4] = CHAR_SET[(buffer[i * 3] >> 2) & 0xff]; 96 result[i * 4 + 1] = CHAR_SET[(((buffer[i * 3] & 0x03) << 4) | (buffer[i * 3 + 1] >> 4)) & 0xff]; 97 result[i * 4 + 2] = CHAR_SET[(((buffer[i * 3 + 1] & 0x0f) << 2) | (buffer[i * 3 + 2] >> 6)) & 0xff]; 98 result[i * 4 + 3] = CHAR_SET[buffer[i * 3 + 2] & 0x3f]; 99 }

100
101 int temp = 0;
102
103 if (rest > 0) {
104 if (rest == 2)

{ 105 result[ccount * 4 + 2] = CHAR_SET[((buffer[ccount * 3 + 1] & 0x0f) << 2) & 0xff]; 106 temp = buffer[ccount * 3 + 1] >> 4; 107 }

else

{ 108 result[ccount * 4 + 2] = CHAR_SET[CHAR_SET.length - 1]; 109 }

110 result[ccount * 4 + 3] = CHAR_SET[CHAR_SET.length - 1];
111 result[ccount * 4 + 1] = CHAR_SET[(((buffer[ccount * 3] & 0x03) << 4) | temp) & 0xff];
112 result[ccount * 4] = CHAR_SET[(buffer[ccount * 3] >> 2) & 0xff];
113 }
114
115 return result;
116 }

Line 95. The "CHAR_SET" array has 65 bytes length, thus the suitable bit mask for its indexes is "0x3F", not "0xFF".
Otherwise it will throw ArrayIndexOutOfBoundsException.
The smallest test that checks the bit masks is "Base64.encode(byte[]

{ 0xFF, 0xFF, 0xFF}

);" call.

I am not an expert in a bit-wise arithmetic, but I assume that lines 95-98 should be replaced with:
result[i * 4] = CHAR_SET[buffer[i * 3] >> 2 & 0b00111111];
result[i * 4 + 1] = CHAR_SET[buffer[i * 3] << 4 & 0b00110000 | buffer[i * 3 + 1] >> 4 & 0b00001111];
result[i * 4 + 2] = CHAR_SET[buffer[i * 3 + 1] << 2 & 0b00111100 | buffer[i * 3 + 2] >> 6 & 0b00000011];
result[i * 4 + 3] = CHAR_SET[buffer[i * 3 + 2] & 0b00111111];

The rest of the Base64.encode(byte[]) method (lines 105-112) also contains bugs, because it uses wrong bit masks - 0xFF.



 Comments   
Comment by hhund [ 12/Jul/14 ]

This issue is still present in jersey-common-2.10. And can be easily reproduced by executing:

import org.glassfish.jersey.internal.util.Base64;

public class Base64Test
{
public static void main(String[] args)

{ String string = Base64.encodeAsString("asdfö"); System.out.println(string); }

}

Please notice the German umlaut 'ö' in the encodeAsString Line.

Comment by bfreuden [ 08/Aug/16 ]

This issue is still present in jersey-common-2.23.1 and it prevents the HTTP basic authentication feature of Jersey from working properly when the username or the password is containing a non-ASCII ISO-8859-1 character like the accented characters mentioned above.
Although the spec of http basic authentication is quite odd, it seems that supporting ISO-8859-1 (and failing for anything else) is a wide-spread choice that should be supported by Jersey:
http://stackoverflow.com/questions/7242316/what-encoding-should-i-use-for-http-basic-authentication
I can confirm that replacing the org.glassfish.jersey.internal.util.Base64 class with a version calling commons-codec makes HTTP basic authentication functional again in Jersey:

package org.glassfish.jersey.internal.util;

import java.nio.charset.StandardCharsets;

public class Base64 {

public static byte[] encode(final byte[] buffer)

{ return org.apache.commons.codec.binary.Base64.encodeBase64(buffer); }

public static byte[] decode(final byte[] buffer)

{ return org.apache.commons.codec.binary.Base64.decodeBase64(buffer); }

public static String encodeAsString(final byte[] buffer)

{ return new String(org.apache.commons.codec.binary.Base64.encodeBase64(buffer), StandardCharsets.ISO_8859_1); }

public static String encodeAsString(final String text)

{ return new String(org.apache.commons.codec.binary.Base64.encodeBase64(text.getBytes(StandardCharsets.ISO_8859_1)), StandardCharsets.ISO_8859_1); }

public static String decodeAsString(final byte[] buffer)

{ return new String(org.apache.commons.codec.binary.Base64.decodeBase64(buffer), StandardCharsets.ISO_8859_1); }

public static String decodeAsString(final String text)

{ return new String(org.apache.commons.codec.binary.Base64.decodeBase64(text.getBytes(StandardCharsets.ISO_8859_1)), StandardCharsets.ISO_8859_1); }

}





[GLASSFISH-21467] Session replication not working in glassfish on multi node cluster Created: 18/Nov/15  Updated: 03/Aug/16

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

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

CentOS on Amazon AWS



 Description   

1) application contains distributable tag in web.xml 2) application when deployed in cluster c1, which contains 2 instances present on same node, session replication works. 3) Same application when deployed in cluster c2, which contains 2 instances present on two CentOS machines, session replication does not work.

Following are content of glassfish-web.xml (if required for reference) :

<glassfish-web-app error-url="">
<session-config>
<session-manager persistence-type="replicated">
<manager-properties>
<property name="persistenceFrequency" value="web-method" />
<property name="relaxCacheVersionSemantics" value="true"/>
</manager-properties>
<store-properties>
<property name="persistenceScope" value="session" />
</store-properties>
</session-manager>
<!--<cookie-properties>
<property name="cookieDomain" value="node2"/>
<property name="cookieDomain" value="node4"/>
</cookie-properties> -->
<cache max-entries="4096" timeout-in-seconds="30" enabled="false">
<default-helper/>
</cache>
</session-config>
<context-root>/contextNaam</context-root>
<class-loader delegate="true"/>
<resource-ref>
<res-ref-name>jdbc/safe</res-ref-name>
<jndi-name>jdbc/safe</jndi-name>
</resource-ref>
<jsp-config>
<property name="keepgenerated" value="true">
<description>Keep a copy of the generated servlet class' java code.</description>
</property>
</jsp-config>
</glassfish-web-app>



 Comments   
Comment by fredaabedi [ 18/Nov/15 ]

This blog post by David Matějček
http://stackoverflow.com/questions/28062516/session-replication-not-working-in-glassfish-on-multi-node-cluster/33669515?lastactivity
indicates there was a bug in Shoal and incompatibility with Grizzly. He has fixed it in Payara and the fix is now in Glassfish too.
I do not find the fix in Glassfish and I have installed the latest Glassfish 4.1.1 and session replication does not work but I verified that it works with paraya-4.1.1.154 on the same machines.
Can you please indicate where is the fix in the source/build?

Thank you!

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 emilio0281 [ 03/Aug/16 ]

Same problem!
Any update?





[GLASSFISH-21554] Undepoyment fails with message "Application not registered" Created: 29/Jul/16  Updated: 29/Jul/16

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

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


 Description   

Undepoyment fails with message "Application not registered" under certain conditions.

[Case 1]
After deploying an application that fails to be loaded on a server instance, undeployment fails.
How to reproduce:
1. asadmin create-local-instance i1
2. asadmin start-local-instance i1
3. asadmin deploy --target i1 hello.war
--------
Application deployed with name hello.
Warning: Command _deploy did not complete successfully on server instance i1: remote failure: Failed to load the application on instance i1. The application will not run properly. Please fix your application and redeploy.
Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.RuntimeException: HelloServlet. Please see server.log for more details.
Command deploy completed with warnings.
--------
4. asadmin undeploy --target i1 hello
--------
hello disabled failed
An error occurred during replication
Failure: Command disable failed on server instance i1: remote failure: Application not registered
Command undeploy executed successfully.
--------
Step 4 fails.

[case 2]
After deploying an application to domain, undeployment fails.
How to reproduce:
1. asadmin deploy --target domain hello.war
2. asadmin restart-domain
3. asadmin undeploy --target domain hello
--------
hello disabled failed
Application not registered
Command undeploy executed successfully.
--------
Stpe 3 fails.

This problem seems to be introduced by r48518.
--------
— ApplicationLifecycle.java (revision 48517)
+++ ApplicationLifecycle.java (revision 48518)
@@ -1950,13 +1967,17 @@
public void disable(UndeployCommandParameters commandParams,
Application app, ApplicationInfo appInfo, ActionReport report,
Logger logger) throws Exception {

  • // if the application is not loaded, do not unload
  • if (domain.isCurrentInstanceMatchingTarget(commandParams.target, commandParams.name, server.getName(), null)) {
  • if (appInfo == null || !appInfo.isLoaded()) { - return; - }

    + if (appInfo == null)

    { + report.failure(logger, "Application not registered", null); + return; }

    --------

This can be fixed by the following modification.


public void disable(UndeployCommandParameters commandParams,
Application app, ApplicationInfo appInfo, ActionReport report,
Logger logger) throws Exception {
if (appInfo == null)

{ - report.failure(logger, "Application not registered", null); return; }





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