[GLASSFISH-21322] Threads blocking in ApplicationContext.mergeParameters method Created: 02/Mar/15  Updated: 11/May/15

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

Type: Bug Priority: Blocker
Reporter: Yury_Morozov Assignee: Shaifali Kansal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javaee_ri_target

 Description   

Related to GLASSFISH-20670

During performance tests of our application we discovered that most of http threads were eventually locked on org.apache.catalina.core.ApplicationContext.mergeParameters method.

Part of stack trace of one blocked thread:
Thread "http-thread-pool-8181(2)": at org.apache.catalina.core.ApplicationContext.mergeParameters() at org.apache.catalina.core.ApplicationContext.getInitParameter(java.lang.String) at org.apache.catalina.core.ApplicationContextFacade.getInitParameter(java.lang.String) at com.sun.faces.context.ExternalContextImpl.getInitParameter(java.lang.String) at javax.faces.context.ExternalContextWrapper.getInitParameter(java.lang.String) at javax.faces.component.UIComponent.popComponentFromEL(javax.faces.context.FacesContext)

First call to mergeParameters() will execute and only the few threads trying to access it during that time need to be synchronized. After that all calls just check condition and finish. Since synchronizing a method could in some extreme cases decrease performance by a factor of 100 or higher, the overhead of acquiring and releasing a lock every time this method is called seems unnecessary: once the execution of this method has been completed, acquiring and releasing the locks would appear unnecessary.

The bug hasn't been fixed in "GLASSFISH-20670", the method mergeParameters is still synchronized and blocks all threads.
Solution that is submitted in commets for "GLASSFISH-20670" fixes the problem.
Please, include this in your next release.



 Comments   
Comment by Yury_Morozov [ 02/Mar/15 ]

This bug can be easily fixed by double-checked locking pattern (as suggested for ''GLASSFISH-20670'' by Sergey Rezvan):

ApplicationContext.java
org.apache.catalina.ApplicationContext

public class ApplicationContext implements ServletContext {
....
private volatile Object lockObject = new Object();
....
	private void mergeParameters() {
		if (!this.parametersMerged) {
			synchronized (this.lockObject) {
				if (!this.parametersMerged) {
					for (String name : this.context.findParameters()) { 
						this.parameters.put(name, this.context.findParameter(name)); 
					}
					List<ApplicationParameter> params = this.context.findApplicationParameters();
					Iterator<ApplicationParameter> i = params.iterator();
					while (i.hasNext()) {
						ApplicationParameter param = (ApplicationParameter)i.next();
						if (param.getOverride()) {
							if (this.parameters.get(param.getName()) == null) { 
								this.parameters.put(param.getName(), param.getValue()); 
							}
						} else { 
							this.parameters.put(param.getName(), param.getValue()); 
						}
					}
					this.parametersMerged = true;
				}
			}
		}
	}
...
}
Comment by Shaifali Kansal [ 11/May/15 ]

This issue has been resolved in revision 63827 on 03/Apr/15 as a part of bug fix for GLASSFISH-20670.





[GLASSFISH-21293] DAS becomes deadlock at start-up after setting log level Created: 22/Jan/15  Updated: 05/May/15

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

Type: Bug Priority: Blocker
Reporter: xj Assignee: Arindam Bandyopadhyay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 8.1 64bits
RI: glassfish-4.1
JDK: 7u25, 8u20


Tags: javaee_ri_target

 Description   

Follow the steps below, asadmin command waits for a response forever.

(1)asadmin create-domain --nopassword=true mydomain
(2)asadmin start-domain mydomain
(3)asadmin set-log-levels org.jvnet.hk2.osgiadapter=FINER
(4)asadmin stop-domain mydomain
(5)asadmin start-domain mydomain

Here is a thread dump for this.
It looks like a deadlock happened on these threads.
"RunLevelControllerThread-1421897830803" daemon prio=6 tid=0x000000000ba99800
"RunLevelControllerThread-1421897830796" daemon prio=6 tid=0x000000000b99f000

2015-01-22 12:44:33
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.76-b04 mixed mode):

"pool-1-thread-1" daemon prio=6 tid=0x000000000bb1b800 nid=0x3fe4 waiting on condition [0x000000000d98f000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000000f7fd57f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"RunLevelControllerThread-1421897830803" daemon prio=6 tid=0x000000000ba99800 nid=0x2c20 in Object.wait() [0x000000000e0de000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f7879d08> (a org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext)
    at java.lang.Object.wait(Object.java:503)
    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:188)
  • locked <0x00000000f7879d08> (a org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext)
    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)
  • locked <0x00000000f86b5398> (a java.lang.Object)
    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)
  • locked <0x00000000f7d55060> (a java.lang.Object)
    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:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"RunLevelControllerThread-1421897830796" daemon prio=6 tid=0x000000000b99f000 nid=0x2398 waiting on condition [0x000000000dd5c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000000f85fbde8> (a java.util.concurrent.FutureTask)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:425)
    at java.util.concurrent.FutureTask.get(FutureTask.java:187)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.get(LRUHybridCache.java:164)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:303)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:1147)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:687)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:655)
    at com.sun.enterprise.server.logging.UniformLogFormatter.getProductId(UniformLogFormatter.java:192)
    at com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:291)
    at com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:178)
    at java.util.logging.StreamHandler.publish(StreamHandler.java:196)
  • locked <0x00000000f85b3260> (a java.util.logging.ConsoleHandler)
    at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:105)
    at java.util.logging.Logger.log(Logger.java:616)
    at java.util.logging.Logger.doLog(Logger.java:641)
    at java.util.logging.Logger.logp(Logger.java:810)
    at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:181)
  • locked <0x00000000e1045178> (a org.jvnet.hk2.osgiadapter.OSGiModuleImpl)
    at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2058)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:413)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2120)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.access$900(ServiceLocatorImpl.java:119)
    at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1063)
    at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1058)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:115)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:111)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.run(LRUHybridCache.java:173)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:292)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:1147)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:687)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:655)
    at com.sun.enterprise.server.logging.UniformLogFormatter.getProductId(UniformLogFormatter.java:192)
    at com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:291)
    at com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:178)
    at java.util.logging.StreamHandler.publish(StreamHandler.java:196)
  • locked <0x00000000f85b3260> (a java.util.logging.ConsoleHandler)
    at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:105)
    at java.util.logging.Logger.log(Logger.java:616)
    at java.util.logging.Logger.doLog(Logger.java:641)
    at java.util.logging.Logger.logp(Logger.java:810)
    at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:181)
  • locked <0x00000000e103b210> (a org.jvnet.hk2.osgiadapter.OSGiModuleImpl)
    at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2058)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:413)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2120)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.access$900(ServiceLocatorImpl.java:119)
    at org.jvnet.hk2.internal.ServiceLocatorImpl$10.compute(ServiceLocatorImpl.java:1260)
    at org.jvnet.hk2.internal.ServiceLocatorImpl$10.compute(ServiceLocatorImpl.java:1255)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:115)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:111)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.run(LRUHybridCache.java:173)
    at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:292)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1333)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:726)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServices(ServiceLocatorImpl.java:714)
    at com.sun.enterprise.server.logging.LogManagerService.getHandlerServices(LogManagerService.java:639)
    at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:404)
    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)
  • locked <0x00000000f7d54fd8> (a java.lang.Object)
    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:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"Timer-0" daemon prio=6 tid=0x0000000009eec000 nid=0x2b70 in Object.wait() [0x000000000dabf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f786d2a0> (a java.util.TaskQueue)
    at java.lang.Object.wait(Object.java:503)
    at java.util.TimerThread.mainLoop(Timer.java:526)
  • locked <0x00000000f786d2a0> (a java.util.TaskQueue)
    at java.util.TimerThread.run(Timer.java:505)

"FelixStartLevel" daemon prio=6 tid=0x000000000a011800 nid=0x1b28 in Object.wait() [0x000000000a3ae000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f9be27a8> (a java.util.ArrayList)
    at java.lang.Object.wait(Object.java:503)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:279)
  • locked <0x00000000f9be27a8> (a java.util.ArrayList)
    at java.lang.Thread.run(Thread.java:745)

"FelixDispatchQueue" daemon prio=6 tid=0x000000000906f000 nid=0xfc0 in Object.wait() [0x000000000923e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f9c16020> (a java.util.ArrayList)
    at java.lang.Object.wait(Object.java:503)
    at org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1063)
  • locked <0x00000000f9c16020> (a java.util.ArrayList)
    at org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
    at org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:101)
    at java.lang.Thread.run(Thread.java:745)

"Service Thread" daemon prio=6 tid=0x0000000008d77000 nid=0x136c runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x0000000008d5b000 nid=0x17b0 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x0000000008d5a000 nid=0x382c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Attach Listener" daemon prio=10 tid=0x00000000076ed000 nid=0x439c runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00000000076e4800 nid=0x3f50 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x000000000767f000 nid=0x13ec in Object.wait() [0x0000000008b6f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000e09c93b8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
  • locked <0x00000000e09c93b8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" daemon prio=10 tid=0x0000000007678000 nid=0x4014 in Object.wait() [0x000000000899f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000e09b4e98> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
  • locked <0x00000000e09b4e98> (a java.lang.ref.Reference$Lock)

"main" prio=6 tid=0x00000000020fe800 nid=0x2304 in Object.wait() [0x000000000261e000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)

  • waiting on <0x00000000f7cad488> (a java.lang.Object)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$UpAllTheWay.waitForResult(CurrentTaskFuture.java:485)
  • locked <0x00000000f7cad488> (a java.lang.Object)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.get(CurrentTaskFuture.java:334)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.get(CurrentTaskFuture.java:306)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFutureWrapper.get(CurrentTaskFutureWrapper.java:75)
    at org.glassfish.hk2.runlevel.internal.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:73)
    at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:534)
    at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:315)
    at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:228)
    at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:219)
  • locked <0x00000000f7c3c538> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
  • locked <0x00000000f7c486a0> (a com.sun.enterprise.glassfish.bootstrap.GlassFishImpl)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
    at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.start(EmbeddedOSGiGlassFishImpl.java:75)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
    at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
    at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)

"VM Thread" prio=10 tid=0x0000000007674800 nid=0x4098 runnable

"GC task thread#0 (ParallelGC)" prio=6 tid=0x0000000002114000 nid=0x4080 runnable

"GC task thread#1 (ParallelGC)" prio=6 tid=0x0000000002115800 nid=0x2588 runnable

"GC task thread#2 (ParallelGC)" prio=6 tid=0x0000000002117000 nid=0x1568 runnable

"GC task thread#3 (ParallelGC)" prio=6 tid=0x0000000002118800 nid=0x3ad4 runnable

"VM Periodic Task Thread" prio=10 tid=0x0000000008d6c000 nid=0xddc waiting on condition

JNI global references: 370






[GLASSFISH-21278] SessionScoped object sharing between different sessions when Async Servlet 3.0 involved in execution path Created: 22/Dec/14  Updated: 23/Apr/15

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

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

JDK 1.7.0_62


Tags: javaee_ri_target

 Description   

We've noticed a bug related to Session "sharing" between threads when using the Servlet 3.0 Async implementation in Glassfish.
If few users log in to the application, use an Async Servlet and logout, there is a reuse of a @javax.enterprise.context.SessionScoped object between the frontend threads.

Find attached a test case that easely reproduces the errors, with the following configuration at the application server domain:

server-config -> Web Container -> (Tab) Manager Properties -> Max Sessions: 2
server-config -> Thread Pools -> http-thread-pool -> Max Thread Pool Size : 6, Min Thread Pool Size: 6
server-config -> Network Config -> Network Listeners -> http-listener-1 -> (Tab) HTTP -> Comet Support: true, Websocket support: true

The code is commented to enable easy change, and STOP the problem from happening by setting asyncSupported=false in both the AuditFilter and the AsyncDownloadProxy servlet (the AsyncDownloadProxy servlet has comments to indicate where to change the code to support synchronous mode only - marked by "//COMMENT FOR SYNC TESTING")...

The problem shows in the domain's server.log file in the following forms:

1.Looking for the String "REUSING INSTANCES", as by this example:

[#|2014-11-17T17:16:19.624+0000|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-2;|AuditFilter: ************** REUSING INSTANCES!!!!!|#]

2. Checking for this exception in the logs:
[#|2014-11-17T17:16:21.059+0000|SEVERE|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=108;_ThreadName=Thread-2;|java.lang.NullPointerException
at com.sun.grizzly.arp.AsyncProcessorTask.obtainAndSetThreadAttachment(AsyncProcessorTask.java:233)
at com.sun.grizzly.arp.AsyncProcessorTask.enableTimeout(AsyncProcessorTask.java:227)
at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:131)
at com.sun.grizzly.http.TaskBase.run(TaskBase.java:193)
at com.sun.grizzly.http.TaskBase.execute(TaskBase.java:175)
at com.sun.grizzly.arp.DefaultAsyncHandler.handle(DefaultAsyncHandler.java:145)
at com.sun.grizzly.arp.AsyncProtocolFilter.execute(AsyncProtocolFilter.java:210)
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:745)

#]

[#|2014-11-17T17:16:21.060+0000|INFO|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=108;_ThreadName=Thread-2;|Processor exception
java.lang.RuntimeException: java.lang.NullPointerException
at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:144)
at com.sun.grizzly.http.TaskBase.run(TaskBase.java:193)
at com.sun.grizzly.http.TaskBase.execute(TaskBase.java:175)
at com.sun.grizzly.arp.DefaultAsyncHandler.handle(DefaultAsyncHandler.java:145)
at com.sun.grizzly.arp.AsyncProtocolFilter.execute(AsyncProtocolFilter.java:210)
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:745)
Caused by: java.lang.NullPointerException
at com.sun.grizzly.arp.AsyncProcessorTask.obtainAndSetThreadAttachment(AsyncProcessorTask.java:233)
at com.sun.grizzly.arp.AsyncProcessorTask.enableTimeout(AsyncProcessorTask.java:227)
at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:131)
... 14 more

#]

We've allready tried to use the following strategies:
1. Update the grizzly-*.jar from the "modules" directory (don't forget to clean the osgi-cache from the domain dir after this process) to the latest minor released version 1.9.60
2. Update only the grizzly-websockets.jar with the fix indicated at the https://java.net/jira/browse/GRIZZLY-1289

None of them resolved the problem efectively.

Moreover, the NullPointerException is confirmed on this line:

case AsyncTask.FINISH:
enableTimeout();

asyncExecutor.finishExecute();
asyncExecutor.getAsyncHandler().returnTask(this);
return;

caused by the highlighted code returning "null".

final SelectionKey selectionKey = asyncExecutor.getProcessorTask().getSelectionKey();

And I think that on NPE, the code

asyncExecutor.finishExecute();

is not allowed to run, and so the "session" is left associated with the thread, which will come to cause trouble later on following requests.

The most similar report we found is on StackOverflow:
http://stackoverflow.com/questions/25017334/weld-gf4-sessionscoped-sometimes-wrong-bean
which states the same problem very accurately, although with Glassfish 4 instead.



 Comments   
Comment by moonysun [ 22/Dec/14 ]

I also have example code to show this (the code that is referenced by my initial comment) but I can't seem to find any way to upload it to the issue...

Comment by oleksiys [ 22/Dec/14 ]

can you pls. try to apply this patch first
https://dl.dropboxusercontent.com/u/7319744/grizzly-gf3122-patch.zip
?

If you still can reproduce the problem - then we'll need a testcase. Unfortunately you can't upload it here

Comment by moonysun [ 23/Dec/14 ]

Bug is still very much reproducible even with the patch provided.

During this last test, some exceptions showed up in the logs:

[#|2014-12-23T01:49:13.524+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=83;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:56)
at javax.servlet.ServletRequestEvent.<init>(ServletRequestEvent.java:77)
at javax.servlet.ServletRequestAttributeEvent.<init>(ServletRequestAttributeEvent.java:83)
at org.apache.catalina.connector.Request.removeAttribute(Request.java:1625)
at org.apache.catalina.connector.RequestFacade.removeAttribute(RequestFacade.java:581)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:32)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:163)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

and

[#|2014-12-23T01:49:14.772+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=85;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.apache.catalina.connector.Request.doGetSession(Request.java:2845)
at org.apache.catalina.connector.Request.getSession(Request.java:2583)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.jboss.weld.context.http.HttpConversationContextImpl.setSessionAttribute(HttpConversationContextImpl.java:16)
at org.jboss.weld.context.http.HttpConversationContextImpl.setSessionAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:157)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)
14566,15-22 72%

and even more:

[#|2014-12-23T01:49:13.973+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=82;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.apache.catalina.connector.Request.removeAttribute(Request.java:1621)
at org.apache.catalina.connector.RequestFacade.removeAttribute(RequestFacade.java:581)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:32)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:163)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

Relative to the test, at this web addres:

https://www.dropbox.com/sh/stk0cgehvch4ecd/AABI-mPTo9722U5PiIxMNFfCa?dl=0

You will find three files:
session-share-bug.war (deploy to glassfish)
session-share-bug.zip (maven project source code)
TestCDILogout.jmx (jmeter test plan to show the problem)

To reproduce the issue:
Use apache-jmeter to run the TestCDILogout.jmx

and loof for messages in the server.log as:

REUSING

Comment by oleksiys [ 24/Dec/14 ]

Just wanted to confirm, you are able to reproduce the problem with only one jmeter user thread?
How long you normally wait?

Comment by jpereira@linkare.com [ 24/Dec/14 ]

I am able to reproduce it with 2 user threads. But with 10 users it takes about 1 min (sometimes less) to get a few errors like the one i mentioned (finding in the logs REUSING is considered an error as you might understand from the code for obvious reasons).

I can also do it using two browsers each with two tabs/windows and hitting refresh in a quick but random order on the two servlet urls... so you don't actually need too much load to run into it...

Comment by oleksiys [ 25/Dec/14 ]

Pls. try this patch

https://dl.dropboxusercontent.com/u/7319744/grizzly-gf3122-patch.zip

Comment by moonysun [ 25/Dec/14 ]

Nope. Still nothing changes... It even looks like the problem repeated faster... (but that might be my new laptop being faster).

Oh, and by the way, I tested again with a single thread on jmeter and the problem also shows.

Comment by oleksiys [ 25/Dec/14 ]

can you pls. attach the stacktrace?

Comment by moonysun [ 25/Dec/14 ]

The problem shows up even in the event of no StackTrace.
I hope you understand the severity of the problem of sharing session objects in between sessions from different users.

Sometimes, this NPE also shows up, but it is quite rare:

[#|2014-12-25T20:06:08.337+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=94;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.apache.catalina.connector.Request.doGetSession(Request.java:2845)
at org.apache.catalina.connector.Request.getSession(Request.java:2583)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:23)
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:156)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]
Comment by oleksiys [ 25/Dec/14 ]

Do you see NPE similar to the one you reported earlier:

_ThreadName=Thread-2;|java.lang.NullPointerException
at com.sun.grizzly.arp.AsyncProcessorTask.obtainAndSetThreadAttachment(AsyncProcessorTask.java:233)
at com.sun.grizzly.arp.AsyncProcessorTask.enableTimeout(AsyncProcessorTask.java:227)
at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:131)
.....

?

Comment by jpereira@linkare.com [ 25/Dec/14 ]

This time I didn't. But before it only showed up sometimes so there is an amount of uncertainty on tthe observation

even so the main issue of session sharing is still present

Comment by oleksiys [ 26/Dec/14 ]

I think Grizzly part is fixed, the rest IMO is related to webcontainer.
It (webcontainer) must not executes chain postInvoke in the service() thread, if Servlet request was suspended.

Comment by jpereira@linkare.com [ 26/Dec/14 ]

Ok. So I will test your last patch more throughly and report if I can find the NPE or some other bugs related to grizzly... meanwhile have you seen my initial comment stating that an error at the enableTimeout() method call would never allow the finishExecute to be reached?

One other thing... what were the code changes related to your last patch?

Comment by oleksiys [ 26/Dec/14 ]

Right, enableTimeout() race is fixed
https://java.net/jira/browse/GRIZZLY-1729

Comment by moonysun [ 26/Dec/14 ]

So now, as far as I can tell, the only exceptions that remained are:

[#|2014-12-26T22:13:28.230+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=75;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.apache.catalina.connector.Request.removeAttribute(Request.java:1621)
at org.apache.catalina.connector.RequestFacade.removeAttribute(RequestFacade.java:581)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:32)
at org.jboss.weld.context.http.HttpConversationContextImpl.removeRequestAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:163)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

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

[#|2014-12-26T22:13:28.235+0000|SEVERE|glassfish3.1.2|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=75;_ThreadName=Thread-2;|PWC3989: An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at org.apache.catalina.connector.Request.setAttribute(Request.java:1689)
at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:570)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4654)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

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

[#|2014-12-26T22:13:32.325+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=79;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:24)
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:159)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

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

[#|2014-12-26T22:13:39.775+0000|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=77;_ThreadName=Thread-2;|WebModule[/session-share-bug]PWC1322: Error invoking requestDestroyed method on ServletRequestListener org.jboss.weld.servlet.WeldListener
java.lang.NullPointerException
at org.apache.catalina.connector.Request.doGetSession(Request.java:2845)
at org.apache.catalina.connector.Request.getSession(Request.java:2583)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:23)
at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:12)
at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:156)
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:117)
at org.apache.catalina.core.StandardContext.fireRequestDestroyedEvent(StandardContext.java:4648)
at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:242)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:333)
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:1042)
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:745)

#]

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

[#|2014-12-26T22:13:46.649+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=78;_ThreadName=Thread-2;|StandardWrapperValve[AsyncDownloadProxy]: PWC1406: Servlet.service() for servlet AsyncDownloadProxy threw exception
java.lang.IllegalStateException: Missing wrapper
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:226)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at pt.segsocial.ii.session.AuditFilter.doFilter(AuditFilter.java:63)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at 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:1042)
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:745)

#]

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

And the main problem still remains, as reported in the initial statement.

Comment by moonysun [ 26/Dec/14 ]

Meanwhile, sorry for bothering, but the error still seems to be present, just by inspection of the code... I'll explain my reasoning:

in the following lines, at method doTask of class AsyncProcessor Task:

case AsyncTask.FINISH:
enableTimeout(); //If this method fails for some reason, the "finishExecute" will never get called...

asyncExecutor.finishExecute(); //this might never get called at all, if enableTimeout() above fails
asyncExecutor.getAsyncHandler().returnTask(this);
return;

on the other hand, at the method enableTimeout(), we have:

private void enableTimeout()

{ final ThreadAttachment attachment = obtainAndSetThreadAttachment();//check this method for possible exceptions... attachment.setIdleTimeoutDelay(SelectionKeyAttachment.UNSET_TIMEOUT); //this is not prone to exceptions unless "attachment" is null attachment.setTimeout(System.currentTimeMillis()); //this is not prone to exceptions unless "attachment" is null }

and on the method obtainAndSetThreadAttachment() we have:

private ThreadAttachment obtainAndSetThreadAttachment() {
final ProcessorTask processorTask = asyncExecutor.getProcessorTask();//
final SelectionKey selectionKey = processorTask.getSelectionKey();

//those two previous lines were previously written
//final SelectionKey selectionKey = asyncExecutor.getProcessorTask().getSelectionKey();
//so the NPE at asyncExecutor.getProcessorTask() might still occur nonetheless...

Object attachment = selectionKey.attachment();
if (attachment == null || !(attachment instanceof ThreadAttachment))

{ attachment = obtainThreadAttachment(); selectionKey.attach(attachment); }

return (ThreadAttachment) attachment;
}

(check my comments in the code snippets above)...

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

Nonetheless, I made a more comprehensive run (100 virtual users, download -> logout) and I didn't find the original NPE in the logs anymore...

Comment by jpereira@linkare.com [ 10/Feb/15 ]

Bump





[GLASSFISH-21254] Usertransactions are blocked by firewall Created: 14/Nov/14  Updated: 21/Nov/14

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

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

Windows (or any client / server setup separated by a firewall)


Tags: firewall, usertransaction

 Description   

EJB method calls are blocked by the firewall if run in a UserTransaction. This appears to be because the server will attempt to connect to the client on a different port to the original, which the firewall will then block.

Steps to reproduce are fairly straightforward.

1. Ensure that the firewall has been configured to allow EJB lookups.
2. Deploy an EJB with a method that has a transaction type of REQUIRED or SUPPORTS to the web server.
3. On the client machine, look up the UserTransaction and call begin().
4. Next, look up the EJB and call the method with the transaction type of REQUIRED or SUPPORTS.
5. The client code will eventually time out and stacktrace. The webserver log file will report that the connection to the client machine failed.

If the UserTransaction.begin() method is never called, then the method invocation will succeed as expected.



 Comments   
Comment by riksweeney [ 21/Nov/14 ]

[#|2014-11-10T04:21:43.852+0000|WARNING|glassfish3.1.2|javax.enterprise.system.core.transaction.com.sun.jts.jta|_ThreadID=16;_ThreadName=Thread-4;|JTS5071: Unexpected error occurred in registerSynchronization
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: xx.xx.xxx.x; port: 52574 vmcid: OMG minor code: 1 completed: No
at sun.reflect.GeneratedConstructorAccessor168.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy149.connectFailure(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:313)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
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.RuntimeException: java.net.ConnectException: Connection timed out: connect
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:339)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:314)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:215)
... 5 more
Caused by: java.net.ConnectException: Connection timed out: connect
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:532)
at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:110)
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:324)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:313)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
... 5 more





[GLASSFISH-21228] glassfish web IO hangs on html5 video requests(mp4) from client Created: 09/Oct/14  Updated: 23/Apr/15

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

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

Glassfish running on any envirenment, Client is Google Chrome


Tags: javaee_ri_target

 Description   

This is related to Grizzly.

Caused by: java.io.IOException: Client is busy or timed out
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:129)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)


 Comments   
Comment by pradyut [ 09/Oct/14 ]

Any further requests to the server fails and the proxy server shows that the server failed to respond to the GET request.
Shutting down the client browser(chrome) resumes the services from the server.

The logs show -

org.apache.catalina.connector.ClientAbortException: java.io.IOException: Client is busy or timed out
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:430)
at com.sun.grizzly.util.buf.ByteChunk.flushBuffer(ByteChunk.java:458)
at com.sun.grizzly.util.buf.ByteChunk.append(ByteChunk.java:380)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:455)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:442)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:160)
at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:2365)
at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2100)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1090)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:466)
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.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at newa.StoreImage.doFilter(StoreImage.java:100)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at newa.CEFilter.doFilter(CEFilter.java:193)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at 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:745)
Caused by: java.io.IOException: Client is busy or timed out
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:129)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:426)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:498)
at com.sun.grizzly.http.SocketChannelOutputBuffer.realWriteBytes0(SocketChannelOutputBuffer.java:382)
at com.sun.grizzly.http.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:364)
at com.sun.grizzly.tcp.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite

(InternalOutputBuffer.java:894)
at com.sun.grizzly.tcp.http11.filters.IdentityOutputFilter.doWrite(IdentityOutputFilter.java:159)
at com.sun.grizzly.tcp.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:661)
at com.sun.grizzly.tcp.Response.doWrite(Response.java:685)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:425)
... 43 more

#]

at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:430)|#]

at com.sun.grizzly.util.buf.ByteChunk.flushBuffer(ByteChunk.java:458)|#]

at com.sun.grizzly.util.buf.ByteChunk.append(ByteChunk.java:380)|#]

at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:455)|#]

at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:442)|#]

at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:160)|#]

at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:2365)|#]

at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:2100)|#]

at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1090)|#]

at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:466)|#]

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.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)|#]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)|#]

at newa.StoreImage.doFilter(StoreImage.java:100)|#]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)|#]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)|#]

at newa.CEFilter.doFilter(CEFilter.java:193)|#]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)|#]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)|#]

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)|#]

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)|#]

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)|#]

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)|#]

at 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:745)|#]

Caused by: java.io.IOException: Client is busy or timed out|#]

at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:129)|#]

at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)|#]

at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:426)|#]

at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:498)|#]

at com.sun.grizzly.http.SocketChannelOutputBuffer.realWriteBytes0(SocketChannelOutputBuffer.java:382)|#]

at com.sun.grizzly.http.SocketChannelOutputBuffer.realWriteBytes(SocketChannelOutputBuffer.java:364)|#]

at com.sun.grizzly.tcp.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite

(InternalOutputBuffer.java:894)|#]

at com.sun.grizzly.tcp.http11.filters.IdentityOutputFilter.doWrite(IdentityOutputFilter.java:159)|#]

at com.sun.grizzly.tcp.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:661)|#]

at com.sun.grizzly.tcp.Response.doWrite(Response.java:685)|#]

at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:425)|#]

... 43 more|#]

Comment by oleksiys [ 15/Oct/14 ]

Can you pls. clarify, after hitting the problem the server is not able to respond to a simple GET from the same browser? What about other browsers/clients are they still ok?
And everything comes to normal after you restart the client/browser, not the server, right?





[GLASSFISH-21178] asadmin start-database does not work with JDK 1.7u67 - AccessControlException: access denied Created: 01/Sep/14  Updated: 12/May/15

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

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

JDK 1.7u67


Tags: javaee_ri_target

 Description   

asadmin start-database fails once JDK updated to latest version (7u67). Was OK with JDK 7u45.

Fails in derby.log:
Fri Aug 29 15:04:21 BST 2014 : Security manager installed using the Basic server
security policy.
Fri Aug 29 15:04:21 BST 2014 : access denied ("java.net.SocketPermission"
"localhost:1527" "listen,resolve")
Fri Aug 29 15:04:21 BST 2014 : access denied ("java.net.SocketPermission"
"localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission"
"localhost:1527" "listen,resolve")

This looks exactly like GLASSFISH-21004 reported against GlassFish 4.

Could a new version of JavaDB be incorporated into the next release of GlassFish 3?



 Comments   
Comment by Arindam Bandyopadhyay [ 12/May/15 ]

It's successfully working on glassfish 4.1





[GLASSFISH-21164] On deploy jpa validation Eclipselink do not recognize entity class if has lambda expressions inside a method Created: 13/Aug/14  Updated: 22/May/15

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

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

java jdk 1.8_05


Tags: eclipselink, jpa

 Description   

During deploy process if a jpa entity (@Entity) in one of his methods has a java 8 lambda expression the entity is not recognized has a jpa entity and skipped. This cause validation error during deployment if the entity is in relation with others.



 Comments   
Comment by Hong Zhang [ 13/Aug/14 ]

assign to persistence team for evaluation

Comment by Lukas Jungmann [ 13/Aug/14 ]

this is fixed in EclipseLink 2.6.0, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=429992 GF currently uses 2.5.2

Comment by fantarama [ 13/Aug/14 ]

Thanks, but is there a future plan to update GF to 2.6.0? Any workaround to be able to deploy the application?

Comment by caricsvk [ 22/May/15 ]

Eclipselink 2.6.0 is already shipped out (March 10, 2015). When do we expect to have it in glassfish nightly?





[GLASSFISH-21073] GlassFish Fails to Deploy WAR With JodaTime Library Dependency Created: 27/May/14  Updated: 23/Apr/15

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

Type: Bug Priority: Blocker
Reporter: peter_pilgrim Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javaee_ri_target

 Description   

I discovered that GlassFish fails to deploy WAR with JodaTime Library Dependency. It results in a ClassNotFoundException. I suspect that this is classloader hierarchy issue.

Here is the stacktrace:

[2014-05-27T10:10:04.696+0100] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=44 _ThreadName=admin-listener(4)] [timeMillis: 1401181804696] [levelValue: 1000] [[
Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton PopulateDataService
javax.ejb.CreateException: Initialization failed for Singleton PopulateDataService
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:476)
at com.sun.ejb.containers.AbstractSingletonContainer.access$000(AbstractSingletonContainer.java:74)
at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:647)
at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:389)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:219)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:180)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:158)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:166)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
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 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:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
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:744)
Caused by: java.lang.Exception: java.lang.NoClassDefFoundError: org/joda/time/DateTime
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:209)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:986)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:412)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:2014)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:468)
... 49 more
Caused by: java.lang.NoClassDefFoundError: org/joda/time/DateTime
at uk.co.xenonique.digital.PopulateDataService.populate(PopulateDataService.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1035)
at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:72)
at com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:205)
... 69 more
Caused by: java.lang.ClassNotFoundException: org.joda.time.DateTime
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1783)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)
... 77 more
]]

This is serious blocker to any application that prefers to use JodaTime.

The Gradle dependency is this:

dependencies {
compile 'org.glassfish.main.extras:glassfish-embedded-all:4.0.1-b01'
providedCompile 'javax:javaee-api:7.0'

// WARNING: Joda time is broken with Glassfish 4
compile 'joda-time:joda-time:2.2'
compile 'org.slf4j:slf4j-simple:1.6.4'
compile 'com.javaeehandbook.book1:glassfish-embedded-runner:1.0'
compile 'org.jboss.shrinkwrap:shrinkwrap-api:1.0.1'
compile 'org.jboss.shrinkwrap:shrinkwrap-impl-base:1.0.1'

testCompile 'junit:junit:4.11'
}

And the test EJB class looks like this:

package uk.co.xenonique.digital;

import org.joda.time.DateTime;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;
import java.util.Calendar;

/**

  • The type PopulateDataService
    *
  • @author Peter Pilgrim
    */
    @Singleton
    @Startup
    public class PopulateDataService {

@Inject
ContactDetailService contactDetailService;

@PostConstruct
public void populate()

{ Calendar cal = Calendar.getInstance(); ContactDetail contact2 = new ContactDetail(); contact2.setAllowEmails(false); contact2.setTitle("Ms"); contact2.setEmail("oprah.winfrey@harpo.com"); contact2.setFirstName("Oprah"); contact2.setMiddleName("Gail"); contact2.setLastName("Winfrey"); cal.set(1954,1,29); contact2.setDob(cal.getTime()); contactDetailService.add(contact2); DateTime dt = new DateTime(); System.out.printf("dt=%s",dt); }

}

The WAR file extracted looks like this:

0 Sun May 25 10:44:46 BST 2014 WEB-INF/lib/
573912 Wed Dec 11 20:13:10 GMT 2013 WEB-INF/lib/joda-time-2.2.jar
7662 Wed Dec 11 20:15:52 GMT 2013 WEB-INF/lib/slf4j-simple-1.6.4.jar
62589 Tue Dec 10 07:59:06 GMT 2013 WEB-INF/lib/shrinkwrap-api-1.0.1.jar
146419 Tue Dec 10 07:59:06 GMT 2013 WEB-INF/lib/shrinkwrap-impl-base-1.0.1.jar
25962 Wed Dec 11 20:15:52 GMT 2013 WEB-INF/lib/slf4j-api-1.6.4.jar
3648 Tue Dec 10 07:59:06 GMT 2013 WEB-INF/lib/shrinkwrap-spi-1.0.1.jar



 Comments   
Comment by Sanjeeb Sahoo [ 11/Aug/14 ]

Assigning to web container team to analyse why webapp class loader is not able to load org.joda.time.DateTime.class. May be this is specific to embedded glassfish in which case web container team can assign to embedded team.

Comment by Shing Wai Chan [ 15/Oct/14 ]

Can you provide a test war for this?





[GLASSFISH-21070] GlassFish Admin Console Never Appears - White Screen Created: 23/May/14  Updated: 19/Sep/14

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

Type: Bug Priority: Blocker
Reporter: peter_pilgrim Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0.1-b05-ml, Ubuntu Linux 12.04 LTS


Tags: Admin, Console, Exception, FacesServlet, JAXRS, UriBuilder

 Description   

Hello

I cannot access the Glassfish admin console remotely, because there is a failure with a web service.

Glassfish 4.0.1-b05-ml,
Ubuntu Linux 12.04 LTS
I cannot access the administration view http://www.xenonique.co.uk:4848/ on my server at all.
I enabled remote DAS.
I managed to see the admin console, then I restarted the server then now there is a blank screen.

Here is what I found inside the log:

[2014-05-23T19:11:45.498+0000] [glassfish 4.0] [WARNING] [] [javax.enterprise.web.core] [tid: _ThreadID=42 _ThreadName=admin-listener(3)] [timeMillis: 1400872305498] [levelValue: 900] [[
Servlet.service() for servlet FacesServlet threw exception
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)
at org.glassfish.jersey.client.JerseyWebTarget.<init>(JerseyWebTarget.java:71)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:177)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:68)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:862)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:209)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:224)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
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.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:254)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:739)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:575)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:546)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:428)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:378)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:224)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1175)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1654)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1521)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:606)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:702)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
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:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
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:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
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:744)
]]



 Comments   
Comment by Anissa Lam [ 23/May/14 ]

Assign to Web Service team for initial investigation as the error is from there.

Comment by jimnicolson [ 08/Jul/14 ]

Getting the java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder; error also.

Glassfish 4.0.1 (b7)
Oracle Linux 6.5
java version 1.7.0_55

I don't get (haven't seen) this error after clean install first boot with the default Domain1 nor on a freshly created domain.

After I deploy (in WAR form) Jenkins and Artifactory, the problem will arise either on next boot or (annoyingly) a few boots later. Even though there have been no other config changes or deployments!

Either the GF Admin Console will return a blank screen or hang on the "GF Admin console starting" page (a refresh will then return a blank page) or Artifactory will fail on startup.

After trying a few combinations, I found that if I deploy Artifactory after bouncing the server, set Artifactory Deployment order to 150 and Uncheck Enable Implicit CDI, then (relatively)consistently Artifactory starts but the GF Console Startup will fail.

Artifactory and Jenkins are running normally but integration/communication between Atrifactory plug-in and Jenkins also fails once the above GF Admin console startup error ccurs.

This combination of Artifactory, Jenkins (using earlier and current versions) is working and stable with GF 4.0.0.

I am caught between a rock and a hard place. After upgrading to OL 6.5 and it's default JDK of 1.7.0_55, I can't use Eclipse Kepler with GF 4.0.0 because of https://java.net/jira/browse/GLASSFISH-21004.

GF 4.0.1 resolves this but introduces build system failures because of the java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder.

I have a log file and added some comments (Search for !!!!). This is a single full boot process with deployment of Jenkins/Artifactory then an attempt to access the GF Console using a browser. If this is useful, how do I attach it?

Comment by Romain Grécourt [ 08/Jul/14 ]

I didn't reproduce using 4.0.1-b08 (using OSX 10.5 / jdk7u9 / jdk7u51 / jdk7u55).

Here is what I did:

unzip glassfish-4.0.1-b08-ml.zip
cd glassfish4/glassfish
bin/asadmin start-domain
bin/asadmin change-admin-password
bin/asadmin login
bin/asadmin enable-secure-admin
bin/asadmin restart-domain

Peter, can you provide an exact set of steps that reproduce this issue ?

Comment by peter_pilgrim [ 08/Jul/14 ]

Those are the steps I did use. The only differences are that I was accessing my server remotely from a different location and I configured Apache HTTPD server to certain server port 80 on set paths to access web context paths

*/artifactory -> web application "artifactory"
*/jenkins -> web application "jenkins"

E.g. I set up the HTTP conf to use the JkMount

<VirualHost> ...

  1. GlassFish 4.0.1 on worker 2
    JkMount /jenkins worker2
    JkMount /jenkins/* worker2
    JkMount /artifactory worker2
    JkMount /artifactory/* worker2
    ...
    </VirtualHost>

The original error, I saw when I tried access on port 4848, I reported the error that saw in the admin console . Since then, I reconfigured the administration port from 4848 to something else that only I know. Actually, I just tried access this URL and the admin login appears and I can login successfully. Here is how I set up the admin port:

$ asadmin set server.http-service.http-listener.admin-listener.port=9876
$ asadmin set configs.config.server-config.network-config.network-listeners.network-listener.admin-listener.port=9876

I thought the blocker was the Linux firewall, so as root user, I double checked that the ports were open.

$ iptables -A INPUT -p tcp --dport 9876 -j ACCEPT
$ iptables -L

Clearly, it is not a networking error, because Jim Nicolson also is seeing the same issue. So I am not sure why the error is no longer reproducible from my end. That's all of the info.

Comment by jimnicolson [ 09/Jul/14 ]

Hi Romain

Thanks for the quick response...

I realise that GLASSFISH-21004 has been resolved. this solved my Eclipse/Dev VM problem. This caused me to go to 4.0.1 but now I'm hitting the current problem with my build environment VM. I'd prefer to be running the same GF version for both.

On the current problem, I have never seen the issue on a clean domain (i.e. no apps deployed).

Although I've deployed both Jenkins and Artifactory, I did each deployment separately and each one was after a reboot of GF. I tested accessing the consoles of GF and the app(s) after each deployment before continuing.

Jenkins never showed a problem - it seems to be being triggered after the Artifactory deployment. But the problem does not always seem to manifest immediately. Usually immediately but sometimes after one or two GF reboots.

Two additional environment facts (seem unlikely to be a factor). OL 6.5 64 bit, and running on a VirtualBox 4.3.10 VM.

Domain Created with: /opt/glassfish4/glassfish/bin/asadmin --user oracle create-domain --savelogin --checkports=true --portbase 9000 nicolson-dev-mgmt-domain

Although I'm testing on the one VM, I do have a very basic Apache proxy setup for Jenkins/Artifactory set up. It makes no difference whether I use the direct or the proxy URL.

Regards





[GLASSFISH-20998] JMS messages lose message properties when sent via JMSContext. Selector's don't work. Created: 01/Mar/14  Updated: 03/Jun/14

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

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

Tags: 4_0_1-reviewed

 Description   

When sending a message via JMSContext, none of the properties sent on the message arrive at the client, making jms message selectors unusable.

You can use the same test case as here, https://java.net/jira/browse/GLASSFISH-20973



 Comments   
Comment by Nigel Deakin [ 03/Mar/14 ]

Seems to work for me. Can you please paste the exact code you used to set the property?

I tried these two variants:

setting it directly on the Message:

try (JMSContext context = connectionFactory.createContext()){
   TextMessage textMessage = context.createTextMessage("Hello world");
   textMessage.setStringProperty("MyProperty", "Koala");
   context.createProducer().send(inboundQueue,m);
}

and setting it via the JMSProducer

try (JMSContext context = connectionFactory.createContext()){
   context.createProducer().setProperty("MyProperty", "Wombat").send(inboundQueue,"Hello world");
}

and checked the property was set on the received message using

String myProp = message.getStringProperty("MyProperty");

and confirmed that the expected property value was set.





[GLASSFISH-20927] java.lang.ArrayIndexOutOfBoundsException on modifucation of the empty HashSet serialized over corba (JDK 1.7.0_u45) Created: 16/Dec/13  Updated: 03/Jun/14

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

Type: Bug Priority: Blocker
Reporter: Peter Butkovic Assignee: russellgold
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fedora 17, Oracle JDK 1.7.0_u45


Tags: 4_0_1-evangelists, 4_0_1-reviewed

 Description   

When modifying empty HashSet that has been previously serialized over Corba, Following exception happens:

...
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1636631191
at java.util.HashMap.put(HashMap.java:498)
at java.util.HashSet.add(HashSet.java:217)
...

The reason seems to be in the one of the latest changes done in the JDK 1.7.0_u45 (I compared only to JDK 1.7.0_u25, where problem doesn't occur) within the internal implementation of the HashMap.

Namely following sections harm it:

In the HashMap:

public V put(K key, V value) {
if (table == EMPTY_TABLE)

{ inflateTable(threshold); }

...
so after the serialization / deserialization table is not equal to EMPTY_TABLE any more => won't ever call
inflateTable(threshold);
=> internal field: table won't be initialized (is empty) => later modifications fail with ArrayIndexOutOfBoundsException.

The source of the trouble seem to be optimization via introducing EMPTY_TABLE variable. However JDK expects to call readObject() on deserialization, where the reference would be fixed, corba seem to ignore it however.

See the attached test program (Arquilian with embedded glassfish 3.1.2) for reproducing the error. Simply run:
mvn test

Please note that failure comes from the:
BBean.wontWork(...)
as corba serialization already happened.

If modification is done prio to that => in:
ABean.worksOK
=> set won't be empty during corba serialization time
(commented out section)
problem won't happen.



 Comments   
Comment by Peter Butkovic [ 16/Dec/13 ]

I guess I'm not allowed to attach anything Well, that's weird.

Anyway, the test case is available on github: https://github.com/typekpb/GLASSFISH-20927

to reproduce, go for the:
git clone https://github.com/typekpb/GLASSFISH-20927 GLASSFISH-20927
cd GLASSFISH-20927
mvn test

Just make sure to test with the Oracle JDK 1.7.0_u45

Comment by mduigou [ 17/Dec/13 ]

See also GLASSFISH-20814 which is related.

Comment by russgold [ 20/Dec/13 ]

I can duplicate it using your test case. What I don't seem to be able to do is attach a debugger to server process in which the failure is happening - that could be related by lack of familiarity with Arquillian.

Comment by Peter Butkovic [ 21/Dec/13 ]

would this work for you? http://arquillian.org/guides/getting_started/#debug_the_test

Comment by russgold [ 24/Dec/13 ]

This is actually the same issue as GLASSFISH-20814; We will fix it in GF 4 and then look into back porting. Further comments will be found on the other bug.





[GLASSFISH-20795] EclipseLink 2.5.0 JPQL Parser breaks column alias handling in ORDER BY clause Created: 04/Sep/13  Updated: 05/Sep/13

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

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

Glassfish 4 (b89), EclipseLink 2.5.0 (included)


Tags: eclipselink, jpa, jpql

 Description   

Column alias (result_variable) handling as defined in JPA Spec 2.1 (JSR-338) "4.9 ORDER BY Clause" is not working with the default EclipseLink 2.5.0 JPQL Parser (Hermes) provided in Glassfish 4.0 (b89). If a basic JPQL query contains two column aliases and there is an ORDER BY clause on the first alias, EclipseLink returns the following exception:

Exception Description: Problem compiling [SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name].
[70, 79] The identification variable 'last_name' is not defined in the FROM clause.

Example:
========
Create an entity 'Customer' similar to:

@Entity
@Access(AccessType.FIELD)
@Table(name = "CUSTOMER")
public class Customer implements Serializable {

...
@Column(name = "CU_NUMBER")
private String cuNumber;
@Column(name = "HY_NAME_LAST")
private String nameLast;
@Column(name = "HY_NAME_FIRST")
private String nameFirst;
...
}

In a SLSB use:

...
@PersistenceContext(unitName = "TEST_PU")
EntityManager em;
...

Query query = em.createQuery("SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name");
...

This fails with:
Exception Description: Problem compiling [SELECT c.cuNumber, c.nameLast AS last_name, c.nameFirst AS first_name FROM Customer c ORDER BY last_name].
[70, 79] The identification variable 'last_name' is not defined in the FROM clause.

If you use the second alias in the order by clause the query is executed successfully.
The same query is running without any error in Glassfish 3.1.2.2 using supplied EclipseLink version.

It seems to be a EclipseLink JPQL Parser Bug.
As a workaround you can switch back to the prior EclipseLink 2.4 JPQL Parser by using the following configuration in your persistence.xml:
<property name="eclipselink.jpql.parser" value="org.eclipse.persistence.queries.ANTLRQueryBuilder"/>
But I don't think the old JPQL parser is JEE 7 compliant.



 Comments   
Comment by dimaki [ 04/Sep/13 ]

See also here: http://www.eclipse.org/forums/index.php/t/489531/

Comment by PascalFilion [ 05/Sep/13 ]

The bug has been fixed and will be part of the next patch release (2.4.3 and 2.5.1). A nightly build can be picked up if required.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410808





[GLASSFISH-20712] Session Replication (Possibly CNF error in web container?) Created: 19/Jul/13  Updated: 23/Apr/15

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

Type: Bug Priority: Blocker
Reporter: alev50 Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1 node, 1 cluster, 2 instances


Attachments: Zip Archive logs_180713_1612.zip    
Tags: javaee_ri_target

 Description   

Here is the scenario I played :

1 - Start cluster
2 - Deploy web app
3 - Connect through load balancer -> instance 2
4 - Log on
5 - Stop instance 2
6 - Refresh browser -> instance 1
7 - Session lost + StreamCorruptedException
8 - Stop cluster

Logs are attached.

Thanks for help.

Regards,

Anthony

-----------------------------------------------------------------------------------------------------------------
Fialli Joe joe.fialli@oracle.com via shoal.java.net

Thanks for providing a full set of server logs just containing the test scenario that is failing for you.

I just want to make an overall statement that we are trying to track down class loading issues in the web container.
So you might want to post this issue to glassfish alias instead of the shoal alias.
So it is overkill to turn on the shoal logging to FINEST since that subsystem could not even be responsible
for corrupted stream (grizzly is the transport for messages between cluster members and the web container passes a
byte of serialized content into Shoal messaging system and when trying to reconstitute replicated session,
the byte array is taken out of shoal messaging subsystem and deserialized should be deserialized using web container class path.
While the failure is stating corrupted stream, the failure is always exactly the same type code of "00". If it truely was a corrupted stream,
we would see different values all the time. The best bet for Type Code 00 in stream is a class not being found.
The ClassNotFoundException is getting consumed and not reported.

Possible reason for the ClassNotFoundException is the following.

My observations when looking at the server log you sent yesterday was that it was incorrect
for there not to be a Web Container classloader context to deserialize the session context
(after all, the class is the app loaded in the container, the default ObjectInputStream is not going
to be able to deserialize that.)

So this failure is significant and needs interpretation by someone who works on web container. It happens quite a bit in the server logs that you sent in.
I am not aware why this would happen. The following might explain trying to deserialize replicated content in web container without using a web container
class path.

[#|2013-07-18T16:00:02.639+0200|FINEST|glassfish3.1.2|org.apache.catalina.loader.WebappLoader|_ThreadID=10;_ThreadName=Thread-2;ClassName=null;MethodName=null;|getClasspath
java.lang.NoSuchMethodException: com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.getClasspath()
at java.lang.Class.getMethod(Class.java:1607)
at org.apache.catalina.loader.WebappLoader.getClasspath(WebappLoader.java:1196)
at org.apache.catalina.loader.WebappLoader.setClassPath(WebappLoader.java:1145)
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:692)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5298)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1518)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1184)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:995)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1518)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1184)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:529)
at org.apache.catalina.startup.Embedded.start(Embedded.java:942)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:604)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.services.impl.WebContainerStarter.startWebContainer(WebContainerStarter.java:202)
at com.sun.enterprise.v3.services.impl.WebContainerStarter.postConstruct(WebContainerStarter.java:134)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

*************

Here is time of first stream corrupted warning log message.
#|2013-07-18T16:06:35.588+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.ha.session.management|_ThreadID=75;_ThreadName=Thread-2;|Exception occurred in getSession

java.io.StreamCorruptedException: invalid type code: 00

Here is ClassNotFoundException that was probably related to that failure. (Note that this is a nested anonymous class. Typically difficult to serialize correctly.)
So the class below is probably one to look at.

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

Here are a large number classes that are being looked for just before this ClassNotFoundException log message.
[#|2013-07-18T16:06:34.749+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

Note that the classes are mostly UI classes related to ajax, java faces.

[#|2013-07-18T16:06:37.493+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages)|#]
[#|2013-07-18T16:06:37.508+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages_fr)|#]
[#|2013-07-18T16:06:37.514+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages_fr_FR)|#]

[#|2013-07-18T16:06:38.123+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities)|#]
[#|2013-07-18T16:06:38.129+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities_fr)|#]

[#|2013-07-18T16:06:38.137+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities_fr_FR)|#]

[#|2013-07-18T16:06:35.921+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.component.AjaxViewRootBeanInfo)|#]

[#|2013-07-18T16:06:35.925+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIViewRootBeanInfo)|#]

[#|2013-07-18T16:06:35.926+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIComponentBaseBeanInfo)|#]

[#|2013-07-18T16:06:36.012+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.messages_fr)|#]

[#|2013-07-18T16:06:36.019+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.messages_fr_FR)|#]

[#|2013-07-18T16:06:37.178+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.sun.facelets.compiler.UIInstructionsBeanInfo)|#]

[#|2013-07-18T16:06:37.183+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.sun.facelets.compiler.UILeafBeanInfo)|#]

[#|2013-07-18T16:06:37.190+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login)|#]
[#|2013-07-18T16:06:37.198+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login_fr_FR)|#]

[#|2013-07-18T16:06:37.205+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlFormBeanInfo)|#]
[#|2013-07-18T16:06:37.207+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIFormBeanInfo)|#]

[#|2013-07-18T16:06:37.253+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlMessagesBeanInfo)|#]
[#|2013-07-18T16:06:37.255+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIMessagesBeanInfo)|#]
[#|2013-07-18T16:06:37.265+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputTextBeanInfo)|#]
[#|2013-07-18T16:06:37.273+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIInputBeanInfo)|#]

[#|2013-07-18T16:06:37.277+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIOutputBeanInfo)|#]
[#|2013-07-18T16:06:37.326+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputSecretBeanInfo)|#]

[#|2013-07-18T16:06:37.328+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputSecretBeanInfo)|#]

[#|2013-07-18T16:06:37.341+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlCommandButtonBeanInfo)|#]
[#|2013-07-18T16:06:37.344+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UICommandBeanInfo)|#]
[#|2013-07-18T16:06:37.392+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlSelectBooleanCheckboxBeanInfo)|#]

[#|2013-07-18T16:06:37.195+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login_fr)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;|loadClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Delegating to classloader1 org.glassfish.internal.api.DelegatingClassLoader@7a8f9805|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Searching local repositories|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;|loadClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Delegating to classloader1 org.glassfish.internal.api.DelegatingClassLoader@7a8f9805|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Searching local repositories|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]



 Comments   
Comment by Ed Bratt [ 19/Jul/13 ]

Posting for Reporter. Clear virus scan.

Comment by Sanjeeb Sahoo [ 22/Jul/13 ]

The following exception happens because WebappLoader is reflectively calling getClasspath method in all class loaders in the class loader chain and APIClassLoader does not have such a method. From what I see WebappLoader does not consider this to be an issue, as it logs the exception in FINEST level. So, I am assigning the issue to web container folks to figure out why session replication does not happen.

"[#|2013-07-18T16:00:02.639+0200|FINEST|glassfish3.1.2|org.apache.catalina.loader.WebappLoader|_ThreadID=10;_ThreadName=Thread-2;ClassName=null;MethodName=null;|getClasspath
java.lang.NoSuchMethodException: com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.getClasspath()

Thanks,
Sahoo

Comment by Shing Wai Chan [ 06/Aug/13 ]

Can you attach a test case for this?

Comment by alev50 [ 12/Aug/13 ]

Not really, I deploy my production web app on a cluster, I stop the current instance and replication fails on a StreamCorruptedException. How could I write a simple test case for this ?

Thanks,

Anthony

Comment by Shing Wai Chan [ 12/Aug/13 ]

We have a unit test for session replication. It is working fine. So, we need more information to debug this. Can you try to construct a unit test case?

Comment by Shing Wai Chan [ 13/Aug/13 ]

Assign to Rajiv for session replication issue.





[GLASSFISH-18953] Unable to start Cluster Instances when using JDK-7 on RHEL 5 Created: 27/Jul/12  Updated: 13/May/13

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

Type: Bug Priority: Blocker
Reporter: jp2011 Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Glassfish 3.1.2.2
RHEL 5
JDK 7u4


Tags: JDK-7, JDK7, RHEL

 Description   

After upgrading from GF 3.1.2 to 3.1.2.2 on DAS, removing cluster instances and recreating them, the instances will not start using JDK 7. The following exception is seen:

<snip>

[#|2012-07-27T09:04:36.428-0400|WARNING|oracle-glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=1570;_ThreadName=Thread-2;|Could not start instance Instance1 on node QA-Node-1 (btsqa01dfw.bot.testnet.rim.net).: Command ' /home/glassfish/glassfish3/glassfish/bin/asadmin --_auxinput - --interactive=false start-local-instance --node QA-Node-1 --sync normal Instance1' failed on node QA-Node-1 (<removed>): Waiting for Instance1 to start ......Error starting instance Instance1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
Completed shutdown of GlassFish runtime
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.RuntimeException: javax.management.MBeanRegistrationException: Exception thrown in preRegister method
at java.lang.management.ManagementFactory.addMXBean(ManagementFactory.java:824)
at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:481)
at org.glassfish.admin.monitor.MonitoringBootstrap.setStatsProviderManagerDelegate(MonitoringBootstrap.java:227)
at org.glassfish.admin.monitor.MonitoringBootstrap.enableMonitoringForProbeProviders(MonitoringBootstrap.java:634)
at org.glassfish.admin.monitor.MonitoringBootstrap.postConstruct(MonitoringBootstrap.java:176)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more
Caused by: javax.management.MBeanRegistrationException: Exception thrown in preRegister method
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.throwMBeanRegistrationException(DefaultMBeanServerInterceptor.java:993)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegister(DefaultMBeanServerInterceptor.java:1009)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:919)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512)
at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:472)
at java.lang.management.ManagementFactory$2.run(ManagementFactory.java:819)
at java.lang.management.ManagementFactory$2.run(ManagementFactory.java:815)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.management.ManagementFactory.addMXBean(ManagementFactory.java:815)
... 23 more
Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=PS Scavenge
at com.sun.jmx.mbeanserver.MXBeanLookup.addReference(MXBeanLookup.java:151)
at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:160)
at javax.management.StandardMBean.preRegister(StandardMBean.java:1075)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegister(DefaultMBeanServerInterceptor.java:1007)
... 32 more

Command start-local-instance failed.: To complete this operation run the following command locally on host <removed> from the GlassFish install location /home/glassfish/glassfish3:

bin/asadmin start-local-instance --node QA-Node-1 --sync normal Instance1|#]

[#|2012-07-27T09:04:36.434-0400|SEVERE|oracle-glassfish3.1.2|org.glassfish.admingui|_ThreadID=1567;_ThreadName=Thread-2;|RestResponse.getResponse() gives FAILURE. endpoint = 'https://localhost:4848/management/domain/servers/server/Instance1/start-instance'; attrs = '{}'|#]

[#|2012-07-27T09:04:36.435-0400|SEVERE|oracle-glassfish3.1.2|org.glassfish.admingui|_ThreadID=1567;_ThreadName=Thread-2;|Error in instanceAction ;
endpoint=https://localhost:4848/management/domain/servers/server/Instance1/start-instance;attrsMap=null|#]

</snip>

After downgrading java to JDK 6, everything works correctly. It should be noted that this behaviour is seen for the following JDK versions: 1.7.0_02, 1.7.0_03, 1.7.0_04, 1.7.0_05



 Comments   
Comment by kneecha [ 09/Aug/12 ]

I am having the same issue using 1.7.0_04-b20. The stack trace is basically the same except the GarbageCollector, name is different:

Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=ParNew

Comment by skgaju [ 24/Aug/12 ]

workaround remove the jvm-option from all server/clusters configs
NOT from DAS config
-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder

Fix for this issue

bash-2.05b# svn diff src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java
Index: src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java
===================================================================
— src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java (revision 5906)
+++ src/main/java/com/sun/enterprise/admin/servermgmt/V2ToV3ConfigUpgrade.java (working copy)
@@ -152,6 +152,7 @@
"-XX:LogFile",
};

+
// these are added to all configs
private static final String[] ADD_LIST = new String[] {
"-XX:+UnlockDiagnosticVMOptions",
@@ -169,14 +170,14 @@
"-Dfelix.fileinstall.bundles.startTransient=true",
"-Dfelix.fileinstall.disableConfigSave=false",
"-Dfelix.fileinstall.log.level=2",

  • "-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder",
    "-Dorg.glassfish.web.rfc2109_cookie_names_enforced=false",
    "-Djava.ext.dirs=$ {com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}

    /jre/lib/ext$

    {path.separator}

    $

    {com.sun.aas.instanceRoot}

    /lib/ext",
    };

// these are added to DAS only
private static final String[] ADD_LIST_DAS = new String[]

{ - "-Dosgi.shell.telnet.port=6666" + "-Dosgi.shell.telnet.port=6666", + "-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder" }

;

Comment by manuel_b [ 13/May/13 ]

I am also encountering this issue after upgrading our cluster nodes from Java 6 to Java 7:

..
Caused by: javax.management.InstanceAlreadyExistsException: MXBean already registered with name java.lang:type=GarbageCollector,name=Copy
at com.sun.jmx.mbeanserver.MXBeanLookup.addReference(MXBeanLookup.java:151)
at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:160)
...

I will remove the mentioned jvm property from the node configuration.

Works! Thanks for the hints here.





[GLASSFISH-18536] GF callback handler blocking a JASPIC provider when Principal is unknown Created: 21/Mar/12  Updated: 16/Apr/14

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

Type: Bug Priority: Blocker
Reporter: bjb Assignee: JeffTancill
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 64bits


Tags: JASPIC, blocking, groups, principal, unknown, users

 Description   

When sending an unknown Principal (principal not valid as per a local JAAS config) but valid on a global perspective (all checks was done in the JASPIC provider), the GF CallerPrincipal handler will throw a blocking exception in the process :

com.sun.enterprise.security.auth.realm.NoSuchUserException: Cet utilisateur [USER@INTRA-DEV01.DOMAIN-DEV01.LOCAL] n'existe pas. at com.sun.enterprise.security.auth.realm.file.FileRealm.getGroupNames(FileRealm.java:329) at com.sun.enterprise.security.auth.login.LoginContextDriver.jmacLogin(LoginContextDriver.java:566) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallerPrincipal(BaseContainerCallbackHandler.java:257) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.processCallback(BaseContainerCallbackHandler.java:197) at com.sun.enterprise.security.jmac.callback.ServerContainerCallbackHandler.handleSupportedCallbacks(ServerContainerCallbackHandler.java:76) at com.sun.enterprise.security.jmac.callback.BaseContainerCallbackHandler.handle(BaseContainerCallbackHandler.java:187) at com.sun.enterprise.security.jmac.callback.ContainerCallbackHandler.handle(ContainerCallbackHandler.java:83) at net.java.spnego.PACSpnegoServerAuthModule.updateCallerPrincipal(PACSpnegoServerAuthModule.java:550) at net.java.spnego.PACSpnegoServerAuthModule.validateRequest(PACSpnegoServerAuthModule.java:354) at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171) at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1445) at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1323) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)

The problem is that groups that were provided before with a call to the GF handler (Group handler) is not used but insteand GF access the default realm (file) to fetch the user's groups.

This is blocking usage of non-JAAS bridge profile JASPIC providers.

To lower the state of this issue, either fix the issue or provide a way to bypass this issue.



 Comments   
Comment by bjb [ 24/Mar/12 ]

Hi Kumar,

Please lower the priority level as it is actually not blocking but only misleading.

It will not block non-JAAS bridge but simply push a wrong track to people debugging.

The core issue has been logged as :
http://java.net/jira/browse/GLASSFISH-18556

When runing in JASPIC mode, such an issue should not be raised.

Rgs,
JB

Comment by kumarjayanti [ 25/Mar/12 ]

This issue does sound like it needs a fix. The caller principal callback is trying to do an identity assertion in this case forcing people to also configure a realm that can be used to fetch the groups of the user. This was done to meet requirements of some other usecases but now i realize this is not appropriate. Instead the Group Principal Callback should be explicitly used in this case.

I will fix this for 3.1.2 Patch releases and glassfish trunk.

Thanks for raising this issue.

Comment by arjan tijms [ 13/Apr/13 ]

Is this still the same issue as reported? I've done a lot of JASPIC testing with GlassFish 3.1.2.2 but never encountered this issue. There is something fishy going on though.

The caller principal callback is trying to do an identity assertion in this case

I think you mean the caller principal callback handler right? Since the caller principal callback is a very simple DTO style class that only stores the Subject and the Principal or Name.

The handler (in BaseContainerCallbackHandler.processCallerPrincipal) does a call to the LoginContextDriver, but it itself does not do any identity assertion:

if (isCertRealm) {
    if (principal  instanceof X500Principal) {
        LoginContextDriver.jmacLogin(fs, (X500Principal)principal);
    }
} else {
    if (!principal.equals(SecurityContext.getDefaultCallerPrincipal())) {
        LoginContextDriver.jmacLogin(fs, principal.getName(), realmName);
    }
}

The LoginContextDriver.jmacLogin however does attempt to do this:

 public static Subject jmacLogin(Subject subject, String identityAssertion, String realm) throws LoginException {

        if (subject == null) {
            subject = new Subject();
        }
        final Subject fs = subject;
        String userName = identityAssertion;

        try {
            if (realm == null || "".equals(realm)) {
                realm = Realm.getDefaultRealm();
            }
            Realm realmInst = Realm.getInstance(realm);
            final Enumeration groups = realmInst.getGroupNames(userName);
            if (groups != null && groups.hasMoreElements()) {
                AppservAccessController.doPrivileged(new PrivilegedAction() {

                    public java.lang.Object run() {
                        while (groups.hasMoreElements()) {
                            String grp = (String) groups.nextElement();
                            fs.getPrincipals().add(new Group(grp));
                        }
                        return fs;
                    }
                });
            }
        } catch (Exception ex) {
            if (_logger.isLoggable(Level.FINE)) {
                _logger.log(Level.FINE, "Exception when trying to populate groups for CallerPrincipal " + identityAssertion, ex);
            }
        }
        return subject;
    }

When using JASPIC, the passed in realm will be "" and when that happens this method obtains the default realm ("file") and tries to get the group names from that (realmInst.getGroupNames(userName);).

If this throws an exception (in my testing a NPE is typically thrown) it is ignored by the catch, so the problem as described for this issue doesn't seem to occur anymore (that is, the exception is still thrown, but it doesn't interrupt the authentication flow).

I'm afraid though that if I happened to have this file realm defined with a user that happened to have the same name as the user I'm trying to authenticate with JASPIC, that this user would suddenly get a set of extra roles. If my application happened to have roles with the same name, then this could be a rather big problem.





[GLASSFISH-18405] ejb lookup failed from netbeans 7.0 based ejb-client with glassfish 3.1.1 Created: 24/Feb/12  Updated: 11/Jul/12

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

Type: Bug Priority: Blocker
Reporter: olafj Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System = Mac OS X version 10.7.3 running on x86_64
Java; VM; Vendor = 1.6.0_29; Java HotSpot(TM) 64-Bit Server VM 20.4-b02-402; Apple Inc.
Runtime = Java(TM) SE Runtime Environment 1.6.0_29-b11-402-11D50b


Attachments: Text File messages.log     Text File messages.log     Zip Archive TestEJB.zip     Zip Archive TestNB.zip    
Tags: ejb, glassfish, glassfish-3-1-1, netbeans

 Description   

An exception occurs at first try to lookup for an remote ejb facade, same client works with same ejb-modules hosted on glassfish 3.0.1:

java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:262)
Caused: java.lang.ClassNotFoundException: com.sun.ejb.codegen.GenericEJBHome_Generated starting from SystemClassLoader[62 modules] with possible defining loaders null and declared parents [ModuleCL@61f52b85[de.crosssoft.usradm.CSBenutzerverwaltung.Data], ModuleCL@1830e4a7[org.netbeans.modules.settings], ModuleCL@7ec78e02[org.netbeans.core.output2], ModuleCL@4f50f0e2[org.openide.explorer], ModuleCL@7595ddb5[org.netbeans.modules.options.keymap], ModuleCL@2e1ed620[org.netbeans.modules.keyring], ModuleCL@7ba76fdd[org.netbeans.core.ui], ModuleCL@3f2620b5[de.crosssoft.CSBaseGuiUtilModule], ModuleCL@75787005[org.netbeans.modules.favorites], ModuleCL@45ed957d[org.netbeans.core.windows], ...47 more]
at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:264)
at org.netbeans.ModuleManager$SystemClassLoader.loadClass(ModuleManager.java:557)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:234)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:73)
Caused: org.omg.CORBA.BAD_OPERATION: FEIN: IOP01210035: ClassNotFoundException while attempting to load interface com.sun.ejb.codegen.GenericEJBHome_Generated vmcid: OMG minor code: 35 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy31.classNotFound3(Unknown Source)
at com.sun.corba.ee.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:76)
at com.sun.corba.ee.impl.util.Utility.loadStub(Utility.java:835)
Caused: org.omg.CORBA.BAD_OPERATION: WARNUNG: IOP01211205: Exception in loadStub vmcid: OMG minor code: 1205 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
[catch] at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy54.exceptionInLoadStub(Unknown Source)
at com.sun.corba.ee.impl.util.Utility.loadStub(Utility.java:842)
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:252)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:406)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
...



 Comments   
Comment by Sanjeeb Sahoo [ 24/Feb/12 ]

transfer to ejb container

Comment by olafj [ 10/Apr/12 ]

Is there any progress on this issue? Can i help with more information? Are there other related issues?

Comment by marina vatkina [ 10/Apr/12 ]

Please attach a test case.

Comment by olafj [ 12/Jun/12 ]

Attached a testcase: EJB-Module, Netbeans Platform Application. Error still occurs with Netbeans Platform 7.0 and Glassfish 3.1.2

Comment by olafj [ 19/Jun/12 ]

Is there any progress on this issue? Do you need more information? Can i help to clearify open questions?

Comment by marina vatkina [ 19/Jun/12 ]

Please provide the exact steps on how to reproduce the error.

Comment by olafj [ 20/Jun/12 ]

Thats very simple.

Build and deploy ejb-project.
Build and run client-project (netbeans platform app).
After app-startup a top component with a "jbutton1" is open. button's click event handler tries to get an initial context and tries call a function of a remote stateless session bean.
Ejb-request fails.

Comment by marina vatkina [ 21/Jun/12 ]

Assigning to ORB module to check why the just loaded class can't be found.

Comment by olafj [ 03/Jul/12 ]

Any new ideas? How can i help?
Without a solution we can not proceed with development. We are going to migrate to Java 7 and Netbeans 7.2, but without an upgrade to Glassfish 3.1.2 that makes no sense for us.

Comment by olafj [ 11/Jul/12 ]

Can you please tell me the status quo of this issue?





[GLASSFISH-17151] EJB remote deployed on GF 3.1 behind a NAT unaccessible via a simple Java app Created: 05/Aug/11  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: Blaise Gosselin Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS Linux Debian 6
JDK 1.6.0.26


Issue Links:
Related
is related to GLASSFISH-17147 App client cannot find EJB behind NAT Open
Tags: 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes, orb-review

 Description   

I have 2 Glassfish servers version 3.1: a FRONT server and a BACK server.
The FRONT server is in a DMZ.
The BACK server is in on a private lan, not accessible directly from the DMZ, but through a firewall that does a NAT on the IP of the BACK server.
-> IP-PU-B = Public IP address of the BACK
-> IP-PR-B = Private IP address of the BACK

Thus, the FRONT server only knows the public IP of the BACK server (the "NATed" IP). The Glassfish on the BACK server knows only its own "private" IP address, not its NATed address (it is only valid for machines on the DMZ).

Here is my client code:
try {
InitialContext context = new InitialContext();
System.out.println("Context initialized!");
HelloService service = (HelloService) context.lookup("HelloEJB");
System.out.println("Service retrieved!");
String name = service.countryCount();
System.out.println("Hello " + name);
} catch (Exception e) {
e.printStackTrace();
}

And here is my jndi.properties content in my client app:
java.naming.factory.initial = com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs = com.sun.enterprise.naming
java.naming.factory.state = com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
org.omg.CORBA.ORBInitialHost = IP-PU-B
org.omg.CORBA.ORBInitialPort = 3700

This code doesn't work if I launch my application from the DMZ trying to access the EJB remote via the IP address IP-PU-B.
This code works if I launch the application from "inside the network" trying to access the EJB remote via the IP address IP-PR-B.

The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall.

We have already tried the following solutions:

  • Connecting to a Remote EJB Module Through a Firewall
    Link: http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesud/index.html
    We have put the IP-PU-B as value for the variable "com.sun.corba.ee.ORBVAAHost".
    In that case, the problem between the FRONT and the BACK still exists, and moreover there is also a problem when I try to access the EJB remote from the Java application run on the BACK to the EJB remote on the BACK.
  • Replace Network address of the orb-listener-1, no better result.
  • Use of variable "java.rmi.server.hostname", no better result.

Is there a specific way to configure Glassfish behind a NAT to make it send the public IP instead of the private one?

Thanks in advance for your help!



 Comments   
Comment by Blaise Gosselin [ 09/Aug/11 ]

Important info: I just tested with the version 3.0.1, and it works correctly when I change the "Network address" of the "orb-listener-1".

It must then be a regression...

Comment by Nicolasdew [ 14/Sep/11 ]

Hello everyone,

we are experiencing the same problem using glassfish 3.1.1
The weirdest thing when setting the parameter com.sun.corba.ee.ORBVAAHost = "our_public_address" is that sometimes i can see that this address is taken into account and sometimes not.
I can see that by analyzing the GIOP packet on wireshark.
Is it confirmed that it is a regression or a misuse ?
Thank you for your reply.

Comment by Blaise Gosselin [ 22/Sep/11 ]

Hi,

Is it possible to have an answer to this problem please?

We are currently facing CDI problems with version 3.0.1, while it is the only one that works through a firewall => WE ARE STUCK for the moment, and we will probably have to use another AS (such as JBoss) if one solution is not proposed/found to our issues! At least maybe you could indicate us the class/lib to change in the GF 3.1 to make it work through a firewall as expected!

Thanks in advance for your help!

KR,

Comment by Blaise Gosselin [ 27/Sep/11 ]

Good news: we have solved this issue by our-self!

A colleague of mine has investigated in the Glassfish source, and here is the result.

Modifications in org.glassfish.enterprise.iiop.impl.GlassFishORBManager:

  1. Change method getClearTextIiopListener to test the “security-enabled” attribute of the iiop-listener (our clear text listener had an SSL element, probably set by the administration console…).
GlassFishORBManager.java
    private IiopListener getClearTextIiopListener() {
        if (iiopListeners != null)  {
            for (IiopListener il : iiopListeners) {
                if (!"true".equals(il.getSecurityEnabled())) {
                    return il ;
                }
            }
        }
		
        return null ;
    }
  1. Change the checkForAddrAny method to set the ORBConstants.SERVER_HOST_PROPERTY property to orbInitialHost. This allows us to send the hostname to the front server, and not the un-NATed IP. This is the same behavior as in Glassfish 3.0, and is needed in our case (natted network between the EJB server and the client).
GlassFishORBManager.java
    private String checkForAddrAny(Properties props, String orbInitialHost) {
        if ((orbInitialHost.equals("0.0.0.0")) || (orbInitialHost.equals("::"))
                || (orbInitialHost.equals("::ffff:0.0.0.0"))) {
            try {
                String localAddress = java.net.InetAddress.getLocalHost().getHostAddress();
                return localAddress;
            } catch (java.net.UnknownHostException uhe) {
                logger.log(Level.WARNING,
                    "Unknown host exception - Setting host to localhost");
				
                return DEFAULT_ORB_INIT_HOST;
            }
        } else {
            props.setProperty(ORBConstants.SERVER_HOST_PROPERTY, orbInitialHost);
            return orbInitialHost;
        }
    }

That's it!

Comment by Harshad Vilekar [ 15/Oct/11 ]

The fix is putback to 3.1.2 workspace. Blaise, could you please confirm if the issue is resolved in (tonight's or later) 3.1.2 build ?

First change was not required - getSsl() correctly returns null for ClearTextIiopListener. Please check you admin settings if there is issue.

Comment by Harshad Vilekar [ 16/Nov/11 ]

The fix is verified by the reporter.

Comment by Harshad Vilekar [ 16/Dec/11 ]

Although the fix works with NAT, it has a side effect - resulting in regression (GLASSFISH-17689). Fix is reverted.

Comment by mone_java [ 24/Jan/12 ]

I have the same problem.... I tried with glassfish 3.1.2-b19-01_23_2012....

this is what my client sends to the server (wireshark):

0000 00 13 49 e2 a3 e9 f4 6d 04 16 75 5e 08 00 45 00 ..I....m ..u^..E.
0010 01 60 ad b9 40 00 40 06 6b 86 c0 a8 01 23 4f 0e .`..@.@. k....#O.
0020 0f 7f c3 9e 0e 75 34 13 d6 8c 7e 5c 1a d8 80 18 .....u4. ..~\....
0030 00 5c 21 ab 00 00 01 01 08 0a 00 37 7b 6c 00 23 .!..... ...7{l.#
0040 e1 d3 47 49 4f 50 01 02 00 00 00 00 01 20 00 00 ..GIOP.. ..... ..
0050 00 05 03 00 00 00 00 00 00 00 00 00 00 0b 4e 61 ........ ......Na
0060 6d 65 53 65 72 76 69 63 65 00 00 00 00 06 5f 69 meServic e....._i
0070 73 5f 61 00 00 00 00 00 00 03 00 00 00 11 00 00 s_a..... ........
0080 00 02 00 02 00 00 4e 45 4f 00 00 00 00 02 00 14 ......NE O.......
0090 00 00 00 00 00 06 00 00 00 a6 00 00 00 00 00 00 ........ ........
00a0 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f 53 65 .(IDL:om g.org/Se
00b0 6e 64 69 6e 67 43 6f 6e 74 65 78 74 2f 43 6f 64 ndingCon text/Cod
00c0 65 42 61 73 65 3a 31 2e 30 00 00 00 00 01 00 00 eBase:1. 0.......
00d0 00 00 00 00 00 6a 00 01 02 00 00 00 00 0a 31 32 .....j.. ......12
00e0 37 2e 30 2e 31 2e 31 00 95 21 00 00 00 19 af ab 7.0.1.1. .!......
00f0 cb 00 00 00 00 02 00 00 00 65 00 00 00 08 00 00 ........ .e......
0100 00 00 00 00 00 00 14 00 00 00 00 00 00 02 00 00 ........ ........
0110 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0120 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0130 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......
0140 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0150 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
0160 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 ngContex t:1.0.

and this what my server sends to my client:

0000 f4 6d 04 16 75 5e 00 13 49 e2 a3 e9 08 00 45 00 .m..u^.. I.....E.
0010 02 72 fb 33 40 00 33 06 29 fa 4f 0e 0f 7f c0 a8 .r.3@.3. ).O.....
0020 01 23 0e 75 c3 9e 7e 5c 1a d8 34 13 d7 b8 80 18 .#.u..~\ ..4.....
0030 00 6c cf 72 00 00 01 01 08 0a 00 23 e2 05 00 37 .l.r.... ...#...7
0040 7b 6c 47 49 4f 50 01 02 00 01 00 00 02 32 00 00 {lGIOP.. .....2..
0050 00 05 00 00 00 03 00 00 00 02 4e 45 4f 00 00 00 ........ ..NEO...
0060 00 02 00 14 00 00 00 00 00 06 00 00 01 30 00 00 ........ .....0..
0070 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e 6f 72 .....(ID L:omg.or
0080 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 78 74 g/Sendin gContext
0090 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 00 00 /CodeBas e:1.0...
00a0 00 01 00 00 00 00 00 00 00 f4 00 01 02 00 00 00 ........ ........
00b0 00 0e 31 39 32 2e 31 36 38 2e 31 2e 32 30 32 00 ..192.16 8.1.202.
00c0 0e 74 00 00 00 19 af ab cb 00 00 00 00 02 00 00 .t...... ........
00d0 00 64 00 00 00 08 00 00 00 00 00 00 00 00 14 00 .d...... ........
00e0 00 00 00 00 00 03 00 00 00 01 00 00 00 20 00 00 ........ ..... ..
00f0 00 00 00 01 00 01 00 00 00 02 05 01 00 01 00 01 ........ ........
0100 00 20 00 01 01 09 00 00 00 01 00 01 01 00 00 00 . ...... ........
0110 00 26 00 00 00 02 00 02 00 00 00 00 00 21 00 00 .&...... .....!..
0120 00 7c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 .|...... ........
0130 00 24 00 00 00 20 00 00 00 66 00 00 00 00 00 00 .$... .. .f......
0140 00 01 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
0150 32 30 32 00 0e ec 00 40 00 00 00 00 00 08 06 06 202....@ ........
0160 67 81 02 01 01 01 00 00 00 17 04 01 00 08 06 06 g....... ........
0170 67 81 02 01 01 01 00 00 00 07 64 65 66 61 75 6c g....... ..defaul
0180 74 00 04 00 00 00 00 00 00 00 00 00 00 01 00 00 t....... ........
0190 00 08 06 06 67 81 02 01 01 01 00 00 00 0f 00 00 ....g... ........
01a0 00 00 00 00 00 2b 49 44 4c 3a 6f 6d 67 2e 6f 72 .....+ID L:omg.or
01b0 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 6d 69 g/CosNam ing/Nami
01c0 6e 67 43 6f 6e 74 65 78 74 45 78 74 3a 31 2e 30 ngContex tExt:1.0
01d0 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 00 01 ........ ........
01e0 02 00 00 00 00 0e 31 39 32 2e 31 36 38 2e 31 2e ......19 2.168.1.
01f0 32 30 32 00 0e 74 00 00 00 4d af ab cb 00 00 00 202..t.. .M......
0200 00 20 00 00 00 64 00 00 00 09 53 31 41 53 2d 4f . ...d.. ..S1AS-O
0210 52 42 00 00 00 00 00 00 00 02 00 00 00 08 52 6f RB...... ......Ro
0220 6f 74 50 4f 41 00 00 00 00 0d 54 4e 61 6d 65 53 otPOA... ..TNameS
0230 65 72 76 69 63 65 00 00 00 00 00 00 00 08 00 00 ervice.. ........
0240 00 01 00 00 00 01 14 00 00 00 00 00 00 02 00 00 ........ ........
0250 00 01 00 00 00 20 00 00 00 00 00 01 00 01 00 00 ..... .. ........
0260 00 02 05 01 00 01 00 01 00 20 00 01 01 09 00 00 ........ . ......
0270 00 01 00 01 01 00 00 00 00 26 00 00 00 02 00 02 ........ .&......

As you can see the server send to my client the private IP and not the public.... I don't understand what i can do for resolve this....
Thank you a lot!

set the public IP as IP for IIOP listener, will that not solve the problem ?

Comment by Rebecca Parks [ 24/Jan/12 ]

This has been flagged for the 3.1.2 Release Notes, but I'm not sure what the Release Notes should say. I think I understand the problem, which is summed up in this paragraph:

"The problem is due to the IIOP protocol as implemented on the Glassfish server. It does a first call on the ORB to locate the EJB (which is deployed on the same server as the ORB). Thus, the ORB sends the private IP to the client, instead of the public IP (which it has no way of knowing, as it is determined by the firewall)... The client then tries to connect on the private IP, which does not go though the firewall."

What I'm not sure I understand is the workaround. Is it the code that Blaise posted?

Comment by Harshad Vilekar [ 25/Jan/12 ]

There is no properly tested workaround available for this issue.

Comment by mone_java [ 25/Jan/12 ]

So for now, it is impossible to communicate with an EJB on a server debian? I have not tried it with windows server ... The code of Blaise Gosselin has been applied, or has been removed? Otherwise for now try with that code, because I need it to work!

ps And another question... Why the client sends to the server 127.0.1.1 ?

Comment by mone_java [ 29/Jan/12 ]

I tried the version 3.1.2_b06 but does not work.... What is your setting of the iiop listener?

Comment by thezebulette [ 16/Apr/12 ]

hello
I think I had the same problem trying to deploy my Eclipse RCP application ( EJB3 inside )

I don't have any problem accesing glassfish server on private adress
I can't ( and I had try all) calling my application on public adress outside the DMZ ..

What are the clue in fine ? any

Comment by ymajoros [ 15/Jan/13 ]

Hi,

Is it possible to have an answer to this problem please?

I work with Blaise Gosselin, who made the patch in #4, and we still have the issue. We have to patch every new version of Glassfish as described.

Thanks in advance for your help!

KR,

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

Comment by hoseka [ 22/Apr/13 ]

Hi all!
Can I solve this problem in version 3.1.2?
Does the correction proposed by Blaise Gosselin work?
Where can I get the source orb-iiop.jar to fix it and replace in my glassfish?

Comment by skgaju [ 05/Sep/13 ]

has anyone tried setting public IP to IIOP listener and Blaise Gosselin patch.





[GLASSFISH-17147] App client cannot find EJB behind NAT Created: 04/Aug/11  Updated: 18/Oct/12

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

Type: Bug Priority: Blocker
Reporter: pablopina Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 11.04,
Sun JDK 6 u26,
GF 3.1, 3.1.1


Issue Links:
Related
is related to GLASSFISH-17151 EJB remote deployed on GF 3.1 behind ... Reopened
is related to GLASSFISH-17153 Appclient launched using JWS from any... Resolved
Tags: orb-review

 Description   

Attempting to launch an app client oever NAT

Public IP: 175.38.163.224
Private IP: 10.1.1.6
NAT on port 3700 of router to port 3700 of 10.1.1.6

In Domain.xml, i added

<jvm-options>-Dcom.sun.corba.ee.ORBVAAHost=175.38.163.224</jvm-options>
<jvm-options>-Dcom.sun.corba.ee.ORBVAAPort=3700</jvm-options>
<jvm-options>-Dcom.sun.corba.ee.ORBUserConfigurators.com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl=x</jvm-options>

Behind NAT I type in the browser

http://175.38.163.224:8080/MockEar/MockEar-app-client

Java Web Start gets launched reports

java.io.FileNotFoundException: http://175.38.163.224:8080/___JWSappclient/___system/___dyn/___system_s1...

http://www.java.net/forum/topic/glassfish/glassfish/gf-311-cant-launch-app-client-behind-nat

I've tried clearing JWS cache, the java web start folder in glassfish/domains/domain1 and redeploying but nothing.

Additionally, when setting ORBVAAHost, etc the app client doesn't launch within the local network where the server is deployed.



 Comments   
Comment by pablopina [ 05/Aug/11 ]

After another night of 'research' I feel i can be a bit more specific:

I went past the JWS error:

java.io.FileNotFoundException: http://175.38.163.224:8080/___JWSappclient/___system/___dyn/___system_s1...

Now it looks like it downloads all the jars, java console starts, the main class gets loaded, I have a
static

{ System.out.println("Class loaded") }

just before
@EJB MyEJMRemote remoteEJB;

In the console, i get to see 'Class loaded'

but then it doesn't go past there.... I've been waiting for over 10 minutes and it doesn't report error message

Comment by pablopina [ 27/Sep/11 ]

Tim,

Will this sove the issue?

http://java.net/jira/browse/GLASSFISH-17151

Comment by Tim Quinn [ 27/Sep/11 ]

It's possible that the changes described in 17151 would resolve your latest problem as well.

Are you able and interested in trying the changes described there in your environment, just as a test, to see if they resolve the problem you are seeing?

I meant to do so earlier, but given that the client is now launching properly this issue is more directly related to the ORB, so I'm going to transfer the issue to that team. It's certainly related to 17151.

I'm also changing the title of the issue to reflect the later problem.

Comment by pablopina [ 27/Sep/11 ]

Tim,

According to Blaise (the reporter of GLASSFISH-17151) they just had to rebuild orb-iiop.jar.

Now that you have reassigned it to the ORB team i'll wait a couple of days to see if they are able to respond (as I am very busy atm) and if they are unable to, yeah, i'll give it a go myself.

Comment by Harshad Vilekar [ 09/Dec/11 ]

Does this work OK with latest 3.1.2 build ? GlASSFISH-17151 is fixed in 3.1.2.





[GLASSFISH-17013] Significant apparent regression in ORB start-up from 2.1 to 3.1.1 Created: 11/Jul/11  Updated: 08/Feb/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16543 Performance regression in JavaEE (ejb... Open
Tags: 3_1_2-exclude

 Description   

Using profiles Scott collected (with JIT turned off) for 2.1.1 and 3.1.1, I found that ORB initialization seems to show a significant regression:

Numbers are CPU seconds:

In 3.1.1:

10.527 GlassFishORBFHelper.getORB

In 2.1 is what I think is the equivalent

4.093 com.sun.enterprise.util.ORBManager.getORB

I do not have access to them right now, but IIRC other profiles with JIT turned on also showed a major regression in ORB start-up.






Generated at Sat May 30 00:50:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.