[GLASSFISH-16525] Add Auto Restarting Capability to Platform Services Created: 02/May/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Tags: ee7ri_cleanup_deferred

 Description   

Automatic restart of crashed GlassFish servers



 Comments   
Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





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

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

Type: Bug Priority: Blocker
Reporter: xj Assignee: Chris Kasso
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-21178] asadmin start-database does not work with JDK 1.7u67 - AccessControlException: access denied Created: 01/Sep/14  Updated: 23/Apr/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?






[GLASSFISH-13460] install-node: perform installs in parallel Created: 15/Sep/10  Updated: 17/Oct/12

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

Type: Improvement Priority: Critical
Reporter: Joe Di Pol Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,460
Tags: 3_1-exclude

 Description   

Currently install-node performs the installs in sequence. To support a large
number of systems it should perform them in parallel.



 Comments   
Comment by Rajiv Mordani [ 28/Sep/10 ]

will look into it for ms6

Comment by Nazrul [ 07/Dec/10 ]

No time to do this in this release. Defer to next release.

Comment by Tom Mueller [ 06/Apr/11 ]

Adjusting priority for 3.2 release.

Comment by Yamini K B [ 17/Oct/12 ]

Not a must have, deferring.





[GLASSFISH-15458] Rewrite asadmin set, get, list subcommands with devtests Created: 06/Jan/11  Updated: 17/Oct/12

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

Type: Improvement Priority: Critical
Reporter: Tom Mueller Assignee: zhouronghui
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File Dotted Names and Object Names.htm    
Issue Links:
Dependency
depends on GLASSFISH-6310 get server.* should return list of im... Open
depends on GLASSFISH-15418 cannot change description of props co... Resolved
depends on GLASSFISH-9489 asadmin get "*level*" produces no result Open
blocks GLASSFISH-15731 properties/attributes changes result ... Open
blocks GLASSFISH-16165 Make the set command faster Open
Tags: ee7ri_cleanup_deferred

 Description   

During the 3.1 release, many bugs have been filed against the set, get, and list asadmin subcommands, especially the set command. There isn't any comprehensive developer test suite that tests the functionality of these commands. The manual page documentation doesn't specify the complete behavior of the commands. For example, for any particular attribute, there are two ways to specify the attribute, e.g.:

configs.config.server-config.java-config.java-home

or

server-config.java-config.java-home

but the dotted-name manual page doesn't mention this.

One problem within the code is that the data structures that are manipulated by the commands are not precisely defined. For example, there is a method called V2DottedNameSupport.getAliasedParent, that returns a TreeNode array with name and relativeName members. However, the meaning of "name" and "relativeName" within that structure are not defined clearly, and depending on different situations, different values are returned.

This enhancement request is meant to be an umbrella feature to request the rewriting of these commands and to identify specific bugs that need to be fixed as part of the rewrite. This work must also include developing a comprehensive developer test suite for list, get and set.



 Comments   
Comment by Tom Mueller [ 10/Jan/11 ]

The DottedNamesObjectNames.htm file contains information from the AS8 release about the definition of dotted names. This should be helpful in reimplementing the set/get/list commands.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16311] Improve operating service (OS) integration Created: 04/Apr/11  Updated: 17/Oct/12

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

Type: Improvement Priority: Critical
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, Linux, Solaris


Issue Links:
Dependency
depends on GLASSFISH-16525 Add Auto Restarting Capability to Pla... Open
depends on GLASSFISH-10266 provide command to delete services Open
depends on GLASSFISH-11692 create-service improvements Open
depends on GLASSFISH-16522 Add Command for list-services Open
depends on GLASSFISH-16523 Platform Services - Add Support for A... Open
depends on GLASSFISH-16526 Add restart-service command Open
depends on GLASSFISH-16140 server running as a service on Window... Reopened
depends on GLASSFISH-5263 Platform Services and the -Xrs option Resolved
depends on GLASSFISH-12363 The error message of "asadmin create-... Closed
Duplicate
is duplicated by GLASSFISH-17126 -Xrs is missing, so on 100% of all Wi... Closed
Tags: ee7ri_cleanup_deferred

 Description   

This RFE is for improving the operating system (OS) service integration for GlassFish. Here are the requirements:

1. Expose the asadmin delete-service interface as a public interface (rather than being hidden as it is currently).

2. Modify the service implementation so that it acts as a monitor on all operating systems. By monitor, this means that if the service is started, then if the GlassFish process exits, it should be restarted automatically. The Windows service currently doesn't work this way - I'm not sure for Linux and Solaris.

3. Modify the service implementation and/or the various start/stop commands so that they interact correctly. This includes:

3a. If the OS service is started, and the user runs stop-local-instance or stop-domain, then the OS service should be stopped too.

3b. If the server is started using start-domain or start-local-instance, and the OS service is not started, the OS service should not be started. However, if the user then later starts the OS service, the OS service must recognize that the server is already running and monitor the already running server (See req. #2).

4. Any sequence of OS service commands and asadmin start/stop-domain or start/stop-local-instance commands must not cause a failure of the command. For example, currently, if you start the Windows OS service for a domain, and then run stop-domain, and then try to stop the Windows OS service, you get an error message from Windows. Also on Windows, if you run start-domain, and then start the OS service, you get an error message saying that "The process terminated unexpectedly." and the service isn't started.

5. The service should be able to be deleted using either the operating system command for deleting services or the asadmin delete-service command. So the following sequences should work:

asadmin create-service
OS delete service command
asadmin create-service
asadmin delete-service

Currently, the 2nd create-service in this sequence may require a --force option. Ideally, it shouldn't.

6. These requirements apply to the officially supported operating systems for GlassFish for Windows, Linux, and Solaris.



 Comments   
Comment by jclingan [ 04/Apr/11 ]

Good RFE write-up. One additional bullet:

6) Currently we have a feature gap on Linux, where no "watchdog" or "monitor" role is offered using our linux service template. Upstart is available on RHEL 6 and OL 6 (timeline for SuSE Enterprise Linux is TBD). We should investigate if an upstart job definition can be created to fulfill the watchdog role on supported OSs. As a heads-up, it looks like Fedora may move to systemd in the future, so watchdog approach may change in the future.

Comment by Byron Nevins [ 04/Apr/11 ]

Problems with #2
=================== problem #1 ================
Mainly the problem of getting into an infinite loop trying to start an unstable server. Windows allows you to set what to do –
You can set any of the allowed 3 occurrences to handle any of the 4 allowed responses.

1. First Failure
2. Second Failure
3. Subsequent Failures

1. restart the service
2. reboot
3. run some other program
4. ignore it

As you can see just figuring out how to allow users to configure these options and then implementing in 3 main platforms that are totally different is quite a task!

Of course – why is the server crashing? I have V2 running at home now for several years. It never crashes. Do we really want to do all of this complicated and expensive work for something that should be exceedingly rare?

======= problem #2 =========== (This caused many support problems with V2)
User kills the server forcefully (e.g. using "kill" or "taskkill.exe")
A moment later it is running again.
He scratches his head kills it again
A moment later it is running again.
"Hello. Customer support? ...."

Comment by Byron Nevins [ 04/Apr/11 ]

Comment from Bill Shannon about #3B

I agree about 3b. If you start the server without using the OS service
mechanism, you're probably not going to be able to get the service mechanism
to monitor that service later. Mostly this should be as expected. The key
is to get stopping and restarting to integrate properly with the service
mechanism. Possibly also start-instance. I'm not sure we want to make
start-local-instance or start-domain just be front-ends to the service
mechanism (if the server is configured to be handled by the service mechanism).

Comment by Bill Shannon [ 04/Apr/11 ]

Ok, apparently we're going to be using Jira as a discussion forum...

For problem #1, we should just pick some particular combination of
options and allow users to customize it using the OS-specific mechanisms.

For problem #2, this is the normal behavior for any service right?
If the user chooses to have the service mechanism manage his server,
this is what he should expect, and what he would get with any other
server managed by the service mechanism, right? For that matter,
this is what he would get with the old node agent - kill the server
instance and the node agent would restart it because it "crashed",
right?

Comment by Tom Mueller [ 05/Apr/11 ]

The changes to OS service integration should also implement those suggested in issue 11692.

Comment by Tom Mueller [ 05/Apr/11 ]

This issue should resolve issue 16140 also.

Comment by Byron Nevins [ 15/Apr/11 ]

One-Pager Added here:
http://wikis.sun.com/display/GlassFish/3.2PlatformServices

Comment by Byron Nevins [ 15/Apr/11 ]

Pasted the description here. Lines that start with **** are my comments.

1. Expose the asadmin delete-service interface as a public interface (rather than being hidden as it is currently).

        • Yes - Also add start|stop|list

2. Modify the service implementation so that it acts as a monitor on all operating systems. By monitor, this means that if the service is started, then if the GlassFish process exits, it should be restarted automatically. The Windows service currently doesn't work this way - I'm not sure for Linux and Solaris.

        • Yes. I will choose reasonable defaults for each platform – as long as the platform supports it.

3. Modify the service implementation and/or the various start/stop commands so that they interact correctly. This includes:

3a. If the OS service is started, and the user runs stop-local-instance or stop-domain, then the OS service should be stopped too.

        • Misunderstanding of what a Service is. GF-instance and the "service" are the same thing, sort of. Once the service has started - when you stop the server you have stopped the "service". Compare to a SMTP server. When you stop the SMTP server process you have also stopped the SMTP "service".

3b. If the server is started using start-domain or start-local-instance, and the OS service is not started, the OS service should not be started.
****It can't be started. GF won't allow the same server to be started twice.

However, if the user then later starts the OS service, the OS service must recognize that the server is already running and monitor the already running server (See req. #2).

        • Impossible - will not do.

4. Any sequence of OS service commands and asadmin start/stop-domain or start/stop-local-instance commands must not cause a failure of the command. For example, currently, if you start the Windows OS service for a domain, and then run stop-domain, and then try to stop the Windows OS service, you get an error message from Windows. Also on Windows, if you run start-domain, and then start the OS service, you get an error message saying that "The process terminated unexpectedly." and the service isn't started.

        • This is all expected and what we want!

5. The service should be able to be deleted using either the operating system command for deleting services or the asadmin delete-service command. So the following sequences should work:

asadmin create-service
OS delete service command
asadmin create-service
asadmin delete-service

Currently, the 2nd create-service in this sequence may require a --force option. Ideally, it shouldn't.

      • will do

6. These requirements apply to the officially supported operating systems for GlassFish for Windows, Linux, and Solaris.

      • indeed.
Comment by Byron Nevins [ 15/Apr/11 ]

Just thinking out loud here.

1) services actually call

asadmin start-XXX --verbose

2) if the server crashes – asadmin knows about it and is capable of restarting it itself without the platform doing anything at all!

3) if the server is stopped in an orderly way, asadmin knows this also and it can tell the difference from a crash.

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

Comment by Byron Nevins [ 27/Apr/11 ]

Please see the One Pager:

http://wikis.sun.com/display/GlassFish/3.2PlatformServices

Note that I have added a feature – we will support services on all GlassFish-supported Platforms.

Comment by Byron Nevins [ 02/May/11 ]

THIS IS THE UMBRELLA ISSUE FOR IMPROVED PLATFORM SERVICES for 3.2

Comment by mkarg [ 28/Jul/11 ]

I want to recommend not having two different JVMs involved or using scripts at all on Windows to implement services.

See, on Windows, a real service is implementing an API defined by Microsoft, which lets Windows monitor the service on its own - there is no need for an additional Watchdog, as Windows is a service watchdog (it even comes with configurable rules what to do when the service fails and can restart it etc)! This is the most clean solution and it could be done very easily by just a few lines of JNA code within the GlassFish kernel.

See http://msdn.microsoft.com/en-us/library/ms685141(v=vs.85).aspx

Comment by mkarg [ 28/Jul/11 ]

I want to suggest that asadmin create-service provides a slightly changes configuration:

  • Since Windows 2008 there are special account types for services due to security reasons. I want to suggest that the service is not created to be run as the local SYSTEM account (= with highest possible access rights) but instead the installer should create a local service type account and register on the most essential access rights with that. In a productive system it is not appropriate to run as local SYSTEM account, and the administrator doesn't know what access rights GF will need, so he cannot change it.
  • Windows has a built-in watchdog facility. The configuration should be made up in a way that automatically restarts after first fail, runs some kind of domain repair at the second fail (if there at all is something that GF can repair), and restarts the host at the third fail. The failure counter should be reset after one week. This stuff already is there, so please use it.

Windows is Windows, not UNIX plus a GUI.

Comment by Byron Nevins [ 28/Jul/11 ]

"it could be done very easily by just a few lines of JNA code"

Please to provide these very easy few lines of code.

Comment by Bill Shannon [ 28/Jul/11 ]

Markus, this seems to be important to you, and you seem to know more about it
than most of us. Perhaps you'd be interested in implementing it and contributing
it to the GlassFish community? While we'd all like to see these sorts of
improvements, I doubt that we would do as good a job as you would.

Comment by mkarg [ 29/Jul/11 ]

Bill,

I would be happy to provide an implementation, but I have no strong GlassFish internals background, so I will need help with that. What I can provide is the complete JNA or C++ code for a "good and complete" "real" Windows service, but what I need it someone that will tell me (a) how to build GlassFish from scratch and (b) the few Java lines needed to issue a GF startup / shutdown / status-query. If we can organize this then I will be glad to provide the complete Windows part.

Regards
Markus

Comment by Bill Shannon [ 29/Jul/11 ]

Ideally you would just issue the "asadmin start-domain" command to
start the app server. Is there some reason you need to start it
"in process"? If so, you'll need to duplicate the environment setup
from asadmin.bat and then start a JVM using the same arguments that
asadmin.bat does.

In any event, Byron is the expert on starting GlassFish.

Also, hopefully, you wouldn't need to build GlassFish in order to do
this, but if you did there's build instructions on the wiki.

Comment by Byron Nevins [ 29/Jul/11 ]

I'm not sure what you mean by "the few Java lines needed to issue a GF startup / shutdown / status-query". Perhaps you mean this?

How to start, stop, check status of domain

java -jar "%GF_HOME%\modules\admin-cli.jar" start-domain
java -jar "%GF_HOME%\modules\admin-cli.jar" stop-domain
java -jar "%GF_HOME%\modules\admin-cli.jar" list-domains

How to start, stop, check status of instance

java -jar "%GF_HOME%\modules\admin-cli.jar" start-local-instance instance1
java -jar "%GF_HOME%\modules\admin-cli.jar" stop-local-instance instance1
java -jar "%GF_HOME%\modules\admin-cli.jar" list-instances --long

------------------
If you mean the source lines that run from the above calls – they are definitely not "few". There are thousands of lines required. They are located in admin/launcher, core/kernel, core/bootstrap, cluster/cli, cluster/admin and common/common-util (off the top of my head)

Comment by mkarg [ 30/Jul/11 ]

My idea is basing on in-process because it is the natural way on Windows to implement services, and it simplifies the complexity by far, as there is no more watchdog asadmin needed. GlassFish will just feel and behave as a native service, so no more scripts are involved. Windows admins don't like scripts, as Windows has a completely different architecture compared to UNIX. UNIX does everything in scripts, Windows does virtually nothin in scripts. So the target is, to get rid of scripts.

Thank you Byron for the hint. Actually I looked for the single entry points in Java source code that make the following happen (in pseudo code):

  • GlassFish.start!
  • GlassFish.stop!
  • (opt.) GlassFish.pause!
  • (opt.) GlassFish.resume!
  • GlassFish.state?

If that is not existing, I will inspect what the scripts do and repeat that in pure Java (hence my question about building from scratch; got that meanwhile using svn and mvn BTW). My target is to provide java source that is using / implementing the native Windows API that directory executes this commands in-process.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16247] Improve support for JVM-specific JVM options Created: 22/Mar/11  Updated: 22/May/13

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

Type: Improvement Priority: Critical
Reporter: Tom Mueller Assignee: kumara
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16348 Support JVM-specific JVM options in c... Open

 Description   

Currently, the domain.xml template that ships with GlassFish is intended to work with any of the supported JVMs. Since the <jvm-option> elements in the <java-config> are all used when the server is run, the domain.xml template can only have options that are common to all supported JVMs. As we move towards supporting JRockit and the IBM JVM on AIX, it may be desirable to ship the domain.xml template with JVM-specific JVM options in the JavaConfig element.

To support this, this RFE requests that the <jvm-option> element support a "usewith" attribute (the name is just a suggestion), that would limit the use of that JVM option to only certain JVM. The value of the usewith attribute could be a comma separated case-insensitive substring of the "java.vm.name" system property ("hotspot" and "jrockit" would match). This would allow the feature to be used with new JVMs without having to modify the GlassFish code. To support this option, the create-jvm-options command would need to have a new option to specify the usewith property for the option.



 Comments   
Comment by Tom Mueller [ 12/Apr/11 ]

Proposed Design

A new attribute will be added to the <jvm-option> element in the domain.xml:

use-with - the value of the use-with attribute is a comma separated list of case-insensitive substrings
of the "java.vm.name" system property. The default value is the empty string, which means
to use the option with all JVMs.

The create-jvm-options command will be modified to include a new --use-with option that can be used to set this. A given JVM option can still only be specified once in a JavaConfig, and all use-with JVM identifiers must be listed with that option, i.e., the following will not be allowed by create-jvm-options:

<jvm-option usewith="hotspot">-Da=b</jvm-option>
<jvm-option usewith="jrockit">-Da=b</jvm-option>

Instead, the following is required:

<jvm-option usewith="hotspot,jrockit">-Da=b</jvm-option>

The "use-with" attribute is valid for both regular and profiler JVM options.

The delete-jvm-options command will not be modified. Thus, when an option is removed, it is removed for all applicable JVMs.

To add an additional JVM type for an option, it will be necessary to delete the option and create it again with all of the desired JVM types. See GLASSFISH-11253 for an RFE to update JVM options.

The list-jvm-options command will be modified so that it only prints out the options for the JVM that is currently running. It will also provide all of the options (both used an unused) as properties, along with the use-with information for use by the admin console.

The JvmOptionBag config bean will be modified so that getJvmOptions will return a List<JvmOption> where JvmOption is a new config bean that has the getUseWith method as well as a getValue method for getting the option value. All users of JvmOptionBag (and JavaConfig) will need to be modified to handle the changed return value from getJvmOptions.

The GenericJavaConfigListener will be modified so that a restart required is triggered only if a JVM option that is used with the current JVM is changed.

Several modifications are needed for GFLauncher:

1. The MiniXmlParser has to handle the use-with option. The parser will save the JVM options with the use-with information internally and add a new method, setJVMType, that will be called with the java.vm.name value once that is determined by GFLauncher (see #2), but before getJvmOptions is called. The setJVMType method will filter the JVM options based on the use-with information.

2. The GFLauncher has to figure out what type of JVM is going to be used to run the server. Typically, the same JVM that is running GFLauncher (asadmin) will be used to run the server that is being started. To optimize this case, GFLauncher will compare its own java.home with the value that is calculated for the server that is being started. If they are the same, then the java.vm.name value from GFLauncher will be used to determine which JVM options to use. If they are not the same, then GFLauncher has to run a small program (a GFLauncher.main method) in the target JVM just to find out the value of java.vm.name for the target JVM. This means that in the rare cases that asadmin is being run with a different JVM than the server, GFLauncher will actually have to start the JVM twice.

As a 2nd optimization, the MiniXmlParser will have a method to tell whether any use-with options have been specified. If not, then GFLauncher doesn't have to determine the JVM type so that step can be skipped.

3. Once the target JVM java.vm.name value is determined, the JVM options are filtered based on this value by calling MiniXmlParser.setJVMType.

Open Issues:

  • Will the console be modified to show the usewith option?
  • Will the console be modified to allow the usewith option to be set?
Comment by Anissa Lam [ 12/Apr/11 ]

Admin Console should add code to show and allow editing of this attribute for jvm-option.
One question though, can this attribute be modified ? If so, how do you expect user to modify it.
Please file an issue against admingui so we have that in our task for 3.2.

Comment by Tom Mueller [ 12/Apr/11 ]

Issue GLASSFISH-16348 has been created to track the console aspect of this.

As stated in the proposed design, the way to modify this attribute is to delete the JVM option and recreate it. This could change if RFE 11253 is implemented, but that is not currently planned.

Comment by Byron Nevins [ 15/Apr/11 ]

1)

I'm not too happy with this logic:

usewith='something' means use only on something
usewith='' means use on EVERYTHING. I.e. nothing means everything.

I'd be happier with usewith being set to a default of "all". It makes the parsing easier too.

2) You need to define precisely what acceptable values are. E.g. there are at least 2 different strings that we'll see with hotspot:

Java HotSpot(TM) Client VM
Java HotSpot(TM) Server VM

We could do something like allow sub-string matching but that can get messy and complicated ( is "H" ok? What about "Spot" or "S"). Or you can demand the full name – that would be handy for doing things like using options that only appply to the server or client JVM.

The one I'd prefer is only allowing values form a list like "hotspot", "hotspotserver", "hotspotclient"
, "jrockit", etc. That of course has the disadvantage of not supporting arbitrary other JVMs.

It seems onerous to force the full name returned by java.vm.name

Also it would be good to get the actual values of java.vm.name for ALL known JVMs – so that we don't get surprises.

– this is something for you to think about.

Comment by Tom Mueller [ 19/Apr/11 ]

Byron and I discussed the previous comment. WRT #1, the way to think about use-with="" is to think "use with not specified" rather than "use with nothing". Then the logic flows fine.
WRT #2, the acceptable values for use-with are any substring of java.vm.name. In the domain.xml template, we'll use terms like "hotspot" and "jrockit". If the user wants to specify "o" and have it match everything, that is up to the user and it would match both HotSpot and JRockit, but it is not recommended.





[GLASSFISH-18486] create-service does not work on 64-bit Windows Created: 08/Mar/12  Updated: 08/Mar/12

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

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


 Description   

winsw.exe doesn't seem to work properly on 64-bit Windows.

Recommended solution - build a 64bit version of winsw.exe






[GLASSFISH-21180] Asadmin remote deploy failing with TimeoutException or hanging Created: 02/Sep/14  Updated: 23/Apr/15

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

Type: Bug Priority: Critical
Reporter: pdudits Assignee: Chris Kasso
Resolution: Unresolved Votes: 33
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

4.1b13 Windows Server 2008 R2, JDK 1.7.0_25, 1.8.0_11


Tags: javaee_ri_target

 Description   

remote deploy over asadmin fails with error

remote failure: Request failed.

Server logs the following (we redirect j.u.l to logback, therefore different formatting):

[2014-09-02 15:02:16,280] [admin-listener(4)] [INFO] [javax.enterprise.admin.rest]: An error occurred while processing the request. Please see the server logs for details.
org.jvnet.mimepull.MIMEParsingException: java.io.IOException: java.util.concurrent.TimeoutException
	at org.jvnet.mimepull.MIMEParser.fillBuf(MIMEParser.java:442) ~[na:na]
	at org.jvnet.mimepull.MIMEParser.skipPreamble(MIMEParser.java:307) ~[na:na]
	at org.jvnet.mimepull.MIMEParser.access$300(MIMEParser.java:68) ~[na:na]
	at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:149) ~[na:na]
	at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:132) ~[na:na]
	at org.jvnet.mimepull.MIMEMessage.makeProgress(MIMEMessage.java:198) ~[na:na]
	at org.jvnet.mimepull.MIMEMessage.parseAll(MIMEMessage.java:181) ~[na:na]
	at org.jvnet.mimepull.MIMEMessage.getAttachments(MIMEMessage.java:106) ~[na:na]
	at com.sun.enterprise.admin.remote.reader.MultipartProprietaryReader.readFrom(MultipartProprietaryReader.java:98) ~[na:na]
	at org.glassfish.admin.rest.readers.MultipartFDPayloadReader.readFrom(MultipartFDPayloadReader.java:72) ~[na:na]
	at org.glassfish.admin.rest.readers.MultipartFDPayloadReader.readFrom(MultipartFDPayloadReader.java:59) ~[na:na]
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.invokeReadFrom(ReaderInterceptorExecutor.java:251) ~[na:na]
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:229) ~[na:na]
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:149) ~[na:na]
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundReadFrom(MappableExceptionWrapperInterceptor.java:73) ~[na:na]
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:149) ~[na:na]
	at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:1124) ~[na:na]
	at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:851) ~[na:na]
	at org.glassfish.jersey.server.ContainerRequest.readEntity(ContainerRequest.java:270) ~[na:na]
	at org.glassfish.jersey.server.internal.inject.EntityParamValueFactoryProvider$EntityValueFactory.provide(EntityParamValueFactoryProvider.java:96) ~[na:na]
	at org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(ParameterValueHelper.java:81) ~[na:na]
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues(JavaResourceMethodDispatcherProvider.java:121) ~[na:na]
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152) ~[na:na]
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104) ~[na:na]
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387) ~[na:na]
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331) ~[na:na]
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103) ~[na:na]
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271) ~[na:na]
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) ~[na:na]
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) ~[na:na]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[na:na]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297) ~[na:na]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267) ~[na:na]
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297) ~[na:na]
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254) ~[na:na]
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028) ~[na:na]
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365) ~[na:na]
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173) ~[na:na]
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179) ~[na:na]
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) ~[kernel.jar:na]
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) ~[kernel.jar:na]
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) ~[nucleus-grizzly-all.jar:na]
	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
Caused by: java.io.IOException: java.util.concurrent.TimeoutException
	at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:90) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.BackChannelFilter.handleRead(BackChannelFilter.java:80) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.read(DefaultFilterChain.java:351) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.FilterChainContext.read(FilterChainContext.java:695) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.io.InputBuffer.blockingRead(InputBuffer.java:1119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.io.ServerInputBuffer.blockingRead(ServerInputBuffer.java:95) ~[na:na]
	at org.glassfish.grizzly.http.io.InputBuffer.fill(InputBuffer.java:1143) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.io.InputBuffer.read(InputBuffer.java:353) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.NIOInputStreamImpl.read(NIOInputStreamImpl.java:83) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.jersey.message.internal.EntityInputStream.read(EntityInputStream.java:101) ~[na:na]
	at org.jvnet.mimepull.MIMEParser.fillBuf(MIMEParser.java:440) ~[na:na]
	... 71 common frames omitted
Caused by: java.util.concurrent.TimeoutException: null
	at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:126) ~[na:na]
	at org.glassfish.grizzly.nio.tmpselectors.TemporarySelectorReader.read(TemporarySelectorReader.java:75) ~[na:na]
	at org.glassfish.grizzly.AbstractReader.read(AbstractReader.java:72) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:77) ~[nucleus-grizzly-all.jar:na]
	... 96 common frames omitted
[2014-09-02 15:02:16,296] [admin-listener(4)] [WARN] [javax.enterprise.system.core]: Internal Server error: /command/deploy
java.lang.RuntimeException: java.lang.IllegalStateException: Illegal attempt to call getOutputStream() after getWriter() has already been called.
	at org.glassfish.admin.rest.adapter.RestAdapter.reportError(RestAdapter.java:346) ~[na:na]
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:209) ~[na:na]
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) ~[kernel.jar:na]
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) ~[kernel.jar:na]
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) ~[na:na]
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) ~[nucleus-grizzly-all.jar:na]
	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
Caused by: java.lang.IllegalStateException: Illegal attempt to call getOutputStream() after getWriter() has already been called.
	at org.glassfish.grizzly.http.server.Response.getNIOOutputStream(Response.java:624) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.grizzly.http.server.Response.getOutputStream(Response.java:649) ~[nucleus-grizzly-all.jar:na]
	at org.glassfish.admin.rest.adapter.RestAdapter.reportError(RestAdapter.java:342) ~[na:na]
	... 34 common frames omitted

There are no issues with deployment over admin gui or via localhost, timeouts are left at default values.

From another client, we see different behaviour when launching deploy - admin thread hangs around this stacktrace.

"admin-listener(4)" daemon prio=6 tid=0x000000000d276000 nid=0x21dc runnable [0x000000001056d000]
   java.lang.Thread.State: RUNNABLE
	at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:571)
	at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeSync(SSLBaseFilter.java:538)
	at org.glassfish.grizzly.ssl.SSLBaseFilter.rehandshake(SSLBaseFilter.java:751)
	at org.glassfish.grizzly.ssl.SSLBaseFilter.renegotiate(SSLBaseFilter.java:736)
	at org.glassfish.grizzly.ssl.SSLBaseFilter.getPeerCertificateChain(SSLBaseFilter.java:793)
	at org.glassfish.grizzly.ssl.SSLBaseFilter.handleEvent(SSLBaseFilter.java:243)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$6.execute(ExecutorResolver.java:94)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.filterchain.FilterChainContext.notifyDownstream(FilterChainContext.java:907)
	at org.glassfish.grizzly.filterchain.FilterChainContext.notifyDownstream(FilterChainContext.java:890)
	at org.glassfish.grizzly.portunif.BackChannelFilter.handleEvent(BackChannelFilter.java:131)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$6.execute(ExecutorResolver.java:94)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.filterchain.FilterChainContext.notifyDownstream(FilterChainContext.java:907)
	at org.glassfish.grizzly.filterchain.FilterChainContext.notifyDownstream(FilterChainContext.java:890)
	at org.glassfish.grizzly.http.server.util.RequestUtils.populateCertificateAttribute(RequestUtils.java:75)
	at org.glassfish.grizzly.http.server.Request.getAttribute(Request.java:873)
	at org.glassfish.grizzly.http.server.Request.getUserPrincipal(Request.java:1859)
	at com.sun.enterprise.admin.util.AdminCallbackHandler.<init>(AdminCallbackHandler.java:110)
	at com.sun.enterprise.admin.util.GenericAdminAuthenticator.authenticate(GenericAdminAuthenticator.java:254)
	at com.sun.enterprise.admin.util.GenericAdminAuthenticator.loginAsAdmin(GenericAdminAuthenticator.java:219)
	at com.sun.enterprise.admin.util.GenericAdminAuthenticator.loginAsAdmin(GenericAdminAuthenticator.java:202)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:168)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)


 Comments   
Comment by bhicks01 [ 17/Sep/14 ]

I am also seeing the MIMEParsingException for the timeout issue on RHEL5.4 (2.6.18-164.11.1.e15), JDK 1.7.0_45 and JDK 1.8.0_20.

Is there a way to specify the timeout or another work around to get the remote deployment working? Manually using the Admin GUI is not feasible and restricting deployment to localhost would require a bit of work.

EDIT: Updated comment to include kernel version as well as different version of java.

Comment by azuchi [ 18/Sep/14 ]

The same behavior occurs on Ubuntu 14.04 LTS, JDK 1.8.0_05-b13.

Comment by pdudits [ 18/Sep/14 ]

I also tried linux now as well to see if can be platform, environment or JDK version issue.

It is not. Timeout occurs on Ubuntu 14.04, Oracle JDK 1.7.0_67-b01.

Comment by pdudits [ 18/Sep/14 ]

An example war file to try: http://dl.bintray.com/pdudits/generic/#applicationPetstore.war, built from https://github.com/pdudits/agoncal-application-petstore-ee7

Comment by David Delabassee [ 19/Sep/14 ]

I was just hit by that same issue too (OS X 10.9 SE8u20).
I'll investigate this in more after J1.

Comment by darkling [ 30/Sep/14 ]

Also, on OS X 10.9 SE7u67.

Comment by gordian74 [ 06/Oct/14 ]

I also receive this
Debian 7 (wheezy)
Glassfish 4.1 build 13
java 1.8.20 (Or 1.7.0_67-b01)

I also notice that this occurs when the war that is beeing deployed has some dependencies included in the war file itself (WEB-INF/lib/)
It doesnt seem to matter how small the included jar file is it still fails as soon as you include it this into the war file.

Comment by khades [ 08/Oct/14 ]

ok, i am affected too, BUT

After some investigation i found out that domains, created in glassfish 4.1 are affected to that but, while glassfish 4.0 upgraded domains works OK.

Comment by gordian74 [ 08/Oct/14 ]

How did you upgrade the domain?

Comment by angelcervera [ 25/Oct/14 ]

With Glassfish 4.0, working.
With Glassfish 4.1:

  • Deploy remotely using asadmin: No way!
  • Using web admin: Working

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.5 LTS
Release: 12.04
Codename: precise

~$ java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

GlassFish Server Open Source Edition 4.1 (build 13)

Comment by pranahata [ 28/Oct/14 ]

Ok,

So

These are my mathematics:

+ 24 votes
+ most voted 4.1 issue
+ issue marked as critical [1]
+ happens on all platforms
+ opened 2 months ago
+ prevents from deploying from a CI server and hence puts people off from upgrading to 4.1
----------------------------------------------------------------------------------------
= no work log + no patch + not a word from the glassfish team

Hellooooooooooooooo

[1] https://java.net/jira/browse/GLASSFISH-21180?jql=project%20%3D%20GLASSFISH%20AND%20affectedVersion%20%3D%204.1%20ORDER%20BY%20votes%20DESC

Comment by philross [ 28/Oct/14 ]

To be fair, Reza Rahman attempted to get the ball rolling with this but I wasn't able to get back to him with enough details.

Comment by bhicks01 [ 28/Oct/14 ]

What additional information do you need? It seems there are enough people interested that some more information could be provided to help get the ball rolling.

This bug should probably be merged with the other I mentioned in first comment.

Thanks.

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

I have tried to reproduce this so that I can fix it in Payara. I followed these steps but failed to reproduce the issue on Ubuntu.

On Ubuntu server 1

unzip glassfish.zip
asadmin start-domain domain1
create a 2 node cluster through the console called test
change administrator password through the console
./asadmin enable-secure-admin
./asadmin start-cluster test
./asadmin restart-domain domain1

On Ubuntu Server 2

unzip glassfish.zip
./asadmin --user admin --host 192.168.79.131 --port 4848 --secure deploy --target test --name test-ejb /home/steve/test-ejb.jar
Application deployed with name test-ejb
Command deploy executed successfully.
./asadmin --user admin --host 192.168.79.131 --port 4848 --secure redeploy --target test --name test-ejb /home/steve/test-ejb.jar
Application deployed with name test-ejb.
Command redeploy executed successfully.
./asadmin --user admin --host 192.168.79.131 --port 4848 --secure undeploy --target test test-ejb
Command undeploy executed successfully.

Can people narrow down under what circumstances this occurs?

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

OK got it the file existed in Ubuntu Server 1 at the path specified so was not uploaded. Looks like it is in the upload of the jar file.

Will investigate

Comment by gcruscoe [ 28/Oct/14 ]

Thank you Payara!

Just to make everyone aware, a simple work around that I did was to use the java/groovy ssh/scp to copy the file and run the command locally on the box rather than using the remote deployment.

import static com.aestasit.ssh.DefaultSsh.*
remoteSession(user:password@host:22) {
scp file, '/tmp/'
exec "/opt/glassfish4/glassfish/bin/asadmin deploy /tmp/$

{baseName}

"
}

or some such...

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

Further narrowing down of the conditions when this occurs.

You can get this to fail deploying to the DAS from the same host if you run;

./asadmin deploy --force --target server --name test-ejb --secure --upload=true /home/steve/test-ejb.jar FAILS

However if you disable secure admin

./asadmin disable-secure-admin
./asadmin restart-domain domain1
./asadmin deploy --force --target server --name test-ejb --upload=true /home/steve/test-ejb.jar SUCCEEDS

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

Another work around (similar to the above) is to scp the jar onto the DAS host and then run the deploy remotely with --upload=false and the path to the jar on the DAS host.
./asadmin --user admin --host 192.168.79.131 --port 4848 --secure deploy --force --target server --name test-ejb --upload=false /home/steve/test-ejb.jar

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

This is a horrible heisenbug. If you run the debugger on GlassFish with a break point in TemporarySelectorReader.read the deploy works every time. Take the debugger off and it fails.

Comment by bornoz [ 03/Nov/14 ]

Same at

Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Linux Srv10 3.10.0-123.9.2.el7.x86_64 #1 SMP Tue Oct 28 18:05:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Glassfish 4.1b13

Comment by smillidge-c2b2 [ 04/Nov/14 ]

I suspect this is a Grizzly issue. After having debugged this extensively on the client and server side the problem appears to be timing related in Grizzly. I am still trying to track down exactly what happens. However I have a hunch this is related to Grizzly commit

https://github.com/GrizzlyNIO/grizzly-mirror/commit/262b9c90c5d9419163e078066ba7421a6d32b959

As this made a large number of changes in exactly the area that is now exhibiting nasty timing problems.

The problem is VERY time sensitive putting in place debugging can disrupt the problem.

Comment by smillidge-c2b2 [ 04/Nov/14 ]

I've raised https://java.net/jira/browse/GRIZZLY-1713 to see if we can get input from the Grizzly team

Comment by pranahata [ 07/Nov/14 ]

Guys,

We've got about 7 v4 domains running and this is stopping us from upgrading.

Can someone just tell us what the plan for these kind of scenarios is? Is it going to be a 4.1.1 any time soon?

Comment by smillidge-c2b2 [ 08/Nov/14 ]

For all watchers oleksiys has kindly attached a Grizzly patch to the Grizzly JIRA https://java.net/jira/browse/GRIZZLY-1713 which fixes it for us in Payara for both the local case with --upload=true and from a host remote to the DAS. Please try the patched grizzly jar and see if it works for you.

Thanks oleksiys

Comment by lukaskuzmiak [ 17/Nov/14 ]

oleksiys' patch works great - https://java.net/jira/browse/GRIZZLY-1713?focusedCommentId=381737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-381737

just replaced the jar in my glassfish remote installation and NetBeans remote deploy works again, yay!

it seems this has been merged to glassfishv41 branch - https://java.net/jira/browse/GRIZZLY-1713?focusedCommentId=381755&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-381755

I hope there's going to be a release soon.

Lukas

Comment by joeydaowang [ 06/Jan/15 ]

Does anyone try to use REST admin interface to deploy applications. It doesn't work in GF 4.1, but works in GF 4.0. I tried the patch above, it doesn't help.
We are using curl for requesting the REST service like:
'curl.exe ^
--user %1:%2 ^
--insecure ^
-H "Accept: application/json" ^
-H "X-Requested-By: dummy" ^
-X POST ^
-F id=@%3 ^
-F contextroot=%4 ^
-F name=%4 ^
-F force=true ^
https://%5/management/domain/applications/application/'





[GLASSFISH-14984] Add a new custom validator to validate port values specified as properties with min and max constraints Created: 03/Dec/10  Updated: 23/Apr/15

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

Type: Improvement Priority: Critical
Reporter: Bhakti Mehta Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred, javaee_ri_target

 Description   

See this bug http://java.net/jira/browse/GLASSFISH-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

This is my prposal for 3.2 timeframe
I was going through the bean validation spec and they have this concept of composing constraints.
As you mentioned above in Grizzly beans @Max and @Min have been removed and replaced with @Pattern
I could have a custom constraint (idea is borrowed from the jsr 303 spec) like this
@Pattern(regexp="*")
@Size
@Constraint(validatedBy = PatternAndSizeValidator.class)
@Documented
@Target(

{ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
public @interface PatternAndSize{
String message() default "Wrong value";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};

@OverridesAttribute.List( { @OverridesAttribute(constraint=Size.class, name="min") } )
int minValue() default 200;
@OverridesAttribute.List( { @OverridesAttribute(constraint=Size.class, name="max") } )
int maxValue() default 66666;

@OverridesAttribute(constraint=Size.class, name="message")
String sizeMessage() default "{com.sun.constraint.size}";


@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER }

)
@Retention(RUNTIME)
@Documented
@interface List

{ PatternAndSize[] value(); }

}
and then we annotate say @PatternAndSize(minValue=9, maxValue=20000, sizeMessage="The value must be within the range") I will customize it so even the pattern can be overriden

This is Tom's input to the thread
Yes, this sounds reasonable. Although in 3.2 I would like to see if the new validator can be not just for an arbitrary pattern but for a system property substitution, with validation that the system property actually has a valid port value.

Can you please file another issue for the RFE for doing this - with your proposal below and mark that for 3.2?
And then the current issue can be used to just change the pattern so that the specific use case will work.

Thanks.
Tom



 Comments   
Comment by Tom Mueller [ 06/Apr/11 ]

Adjusting priority for 3.2 release.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-18320] [Regression] Addition of AdminConsoleStartupService broke EJB embedded Container Created: 03/Feb/12  Updated: 23/Apr/15

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

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

Tags: javaee_ri_target

 Description   

EJB embeddable container suppresses services that won't be necessary for regular testing of local EJBs. One of such services is a Web container. We do it by modifying domain.xml on the fly and using that temporary version during the run.

02/03/2012 hudson build (http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/623/) failed with

java.lang.IllegalStateException: Can't operate without at least one <network-listener>
[java] at com.sun.enterprise.config.util.ServerHelper.getAdminListener(ServerHelper.java:164)
[java] at com.sun.enterprise.config.serverbeans.Config$Duck.getAdminListener(Config.java:460)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:961)
[java] at org.jvnet.hk2.config.Dom.invoke(Dom.java:914)
[java] at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:131)
[java] at $Proxy30.getAdminListener(Unknown Source)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.setValues(AdminEndpointDecider.java:118)
[java] at com.sun.enterprise.v3.admin.adapter.AdminEndpointDecider.<init>(AdminEndpointDecider.java:84)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.init(AdminConsoleAdapter.java:507)
[java] at com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter.postConstruct(AdminConsoleAdapter.java:465)

To reproduce (assuming v2/appserv-tests lib/ and config/ are checked out):
cd v2/appserv-tests/devtests/ejb/ejb31/embedded
ant all-report



 Comments   
Comment by Tom Mueller [ 07/Feb/12 ]

Marina,
Do you know when this broke? The recent changes to AdminConsoleAdapter do not change this code that eventually calls ServerHelper.getAdminListener, and ServerHelper hasn't changed since last July.

Can you provide the details of the changes you make to domain.xml. From the exception, it appears as though the admin-listener network-listener has been removed.

Comment by Tom Mueller [ 07/Feb/12 ]

Masoud, this is actually a zero-config issue. Here, we have a situation where the embedded tests have removed the network listener named "admin-listener" and the server (in AdminConsoleAdapter) throws an exception because of it. I expect AdminAdapter would also have a problem here.

We need a design decision here as to whether some minimal configuration is required to have the admin interface (on port 4848) come up or whether it should come up by default if the config information isn't there. I would think that we would want to be able to configure a server that doesn't have an admin interface but this should be discussed.

Comment by marina vatkina [ 07/Feb/12 ]

Tom,

The test started failing on 02/03/2012 (8am). So the change was made in the 24 hours prior to that.

Embedded EJB container is intended for testing EJBs so should start fast and have the least possible outside containers started (e.g. unless a WAR file is being deployed, the web container should not start). You can find all the transformations that are done in ejb/ejb-container/src/main/java/org/glassfish/ejb/embedded/DomainXmlTransformer.java. They were discussed back then with Jerome and Ken Saks.

Also note that there is no way to get currently to the GlassFish API when using embeddable EJB container (http://docs.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html).

Comment by Tom Mueller [ 08/Feb/12 ]

The root cause of this was the addition of the AdminConsoleStartupService which was added to the trunk on 2/2/12 in revision 52405.

Assigning to Siraj for an immediate fix since this is breaking the embedded EJB tests.

Siraj, the AdminConsoleStartupService must take into account a configuration where no admin-listener is configured. With the current implementation, AdminConsoleStartupService eventually causes a call to ServerHelper.getAdminListener which throws an exception if there is no admin listener configured. AdminConsoleStartupService needs to handle this exception.

This fix is needed on the trunk.

Comment by sirajg [ 09/Feb/12 ]

The test passes in 3.1.2. In the embedded case, the adapter code is not invoked in 3.1.2, but it is invoked on the trunk.

Comment by sirajg [ 13/Feb/12 ]

Handle the case when no network listeners are found. Revision 52563

Comment by marina vatkina [ 15/Mar/12 ]

The latest change to ServerHelper broke it again





[GLASSFISH-7187] use javadb provided by Java SE 6.x (or higher) or GlassFish update tool Created: 17/Feb/09  Updated: 22/May/13

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 7,187

 Description   

CCC Proposal:

  • to use javadb provided by Java SE 6.x or higher or GlassFish update tool.

Rationale:

  • reduce distribution size inline with v3 modular architecture
  • provide for starting/stopping databases on remote instances
  • in future, the database on remote instance can be different from javadb

Impact:

  • in rare circumstances the database may not be installed, for ex. mac
  • impact on CTS, QA and quicklook

Fix:

  • install javadb separately and update the config/asenv.conf with the correct
    location of javadb

Process:

>asadmin start-database

>asadmin start-database --target <target-name>

For remote start/stop of database, the asadmin command will take --target option
with the name of remote instance, for ex. asadmin start-database --target
<target-name>, where the target-name is one of the remote server instances. If
no --target option is specified then the command is assumed to be local which
will try to start the local database similar to v2 in a separate jvm process. In
case of remote instance, the database will be started in embedded mode.

The algorithm for looking up javadb will be as follows:

01 Use the javadb defined by AS_DERBY_INSTALL property of asenv.conf.

02 If javadb is not found based on AS_DERBY_INSTALL property then check if the
corresponding jvm has it. If yes, then use the embedded database.

03 If embedded database is not found, then look for javadb installation based on
the operating system name. Pl. see the following for default locations of javadb
based on the type of installer and operating system.

All Platforms: javadb installer (javadb-10_4_1_3.zip)
expands under javadb, can be installed any where

Windows:
jdk6 installer (jdk-6u12-windows-i586-p.exe):
C:\Program Files\Sun\JavaDB, possible to exclude javadb from installation
ips package thru glassfish update tool:
installed javadb relative to ips image under glassfish
javadb installer (javadb_10_4_1_3.msi)
C:/Program Files/Sun/JavaDB (can be changed)

Solaris (x86/sparc):
jdk6 installer
/opt/SUNWjavadb
jdk-6u12-solaris-i586.sh
$

{JAVA_HOME}/db
ips package thru glassfish update tool:
installed javadb relative to ips image under glassfish
javadb installer (javadb-10_4_1_3-solaris-sparc.sh
installs under javadb wherever the script was run from
javadb pkg installer (javadb-10_4_1_3-solaris-sparc-pkg.sh)
/opt/SUNWjavadb

Linux:
jdk6 installer
/opt/sun/javadb
jdk-6u12-linux-i586.bin
${JAVA_HOME}

/db
ips package thru glassfish update tool:
installed javadb relative to ips image under glassfish

Mac:
ips package thru glassfish update tool:
installed javadb relative to ips image under glassfish

04 If it is still not found based on the above, then display a message for
installing and updating the asenv.conf with javadb location.



 Comments   
Comment by Tom Mueller [ 17/May/10 ]

Lowering priority as this is not expected in 3.1.





[GLASSFISH-5206] Allow commands that take properties to accept properties file as an option Created: 24/Jun/08  Updated: 22/May/13

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

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

Issuezilla Id: 5,206

 Description   

For a project I am working on, we're doing a lot of configuration through system
properties. All of the properties I need to load are already in a properties
file. To load them into Glassfish, I'm using an asant script with separate calls
to "create-system-properties". It would be nice to make one call to
"create-system-properties" that accepts a properties file. Perhaps add a
"--properties-file switch" to specify a file.

Example usage:
asadmin create-system-properties --properties-file deploy.properties



 Comments   
Comment by Tom Mueller [ 10/Jan/11 ]

The --propertiesfile switch could also be added to the copy-config, create-cluster, create-domain, create-instance, create-local-instance, create-service, deploy, deploydir, and redeploy commands. Some of these commands have properties and system properties, so the change would need to deal with that.

Another option might be to overload the properties value specification such that if the value doesn't contain an equals (=), then it is interpreted as a filename that contains the properties.





[GLASSFISH-5876] Rescue console for GlassFish Created: 04/Sep/08  Updated: 22/May/13

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

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

Operating System: All
Platform: Linux


Issuezilla Id: 5,876

 Description   

One of the important themes in v3 is the manageability and making it easier for
people to keep the server up and running.

I recently had a trouble-shooting session with one of the internal GlassFish
customer (JavaFX), which was using v2. This RFE is to make sure we'd have a
better user experience in v3.

One of the features that became invaluable in manageability of Hudson is the
scripting console, where an administrator can execute arbitrary program
fragment. The primary use of this is to poke around the JVM to diagnose the
problem that GlassFish is having.

In Hudson, I have a Groovy runtime and therefore I can let people execute
arbitrary Groovy script. For example, I can send a Groovys script in e-mail and
ask the user to execute it and report back the result.

This can be also used to turn on some debug switches at runtime, etc.

I'd imagine this would be a module on its own, perhaps implemented by the
scripting team. The use of this shall require authentication, and it should be
exposed both through asadmin CLI, admin GUI, and also a separate socket
connector, so that the rescue console can be used even when the HTTP request
processing is down, as in the case of issue #5875.






[GLASSFISH-5744] asadmin list-containers should list the spec version of the container Created: 29/Aug/08  Updated: 28/Jun/13

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

Type: Improvement Priority: Major
Reporter: abien Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Issuezilla Id: 5,744

 Description   

The output of the command asadmin list-containers looks like that in GF 3b20

Container : jpa
properties=(ContractProvider=jpa)
Container : web
properties=(ContractProvider=web)
Container : security
properties=(ContractProvider=security
Container : jruby
properties=(ContractProvider=jruby)

GF 3 is OSGI based, so potentially more than one container could be active at
the same time or activated / deactivated at runtime. There for the spec-version
should be visible in the listing. Otherwise it is hard for real world projects
to rely on certain functionality and e.g. file bugs.

The command should list something like:

Container : jpa [2.0]
properties=(ContractProvider=jpa)



 Comments   
Comment by km [ 08/May/09 ]

Sahoo, the ModuleDefinition currently does not have getSpecVersion and the
MANIFEST.MF does not have Specification-Version attribute. We need to get this
information.

I am assigning this to you so you can decide and update the API so I can call it
from list-containers. Assign it to me when you are done.

Comment by km [ 27/May/09 ]

The right sahoo.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in V3.

Comment by Sanjeeb Sahoo [ 23/Mar/11 ]

It seems like admin folks have to work with build team to have additional metadata in the runtime to provide such information.





[GLASSFISH-12182] Refactor CreateLocalInstanceFilesystemCommand to share with DAS Created: 08/Jun/10  Updated: 05/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 12,182

 Description   

CreateLocalInstanceFilesystemCommand is a local command the creates the
filesystem layout needed for a server instance. In some situations the DAS needs
this capability as well. For example when SSH is configured create-instance
executes _create-instance-filesystem over SSH. But if the server instance is
running local to the DAS we run the command using Runtime.exec(). We'd like to
avoid this and simply reuse the code in CreateLocalInstanceFilesystemCommand.

This is a request to refactor CreateLocalInstanceFilesystemCommand and place the
generic code that does the filesystem creation into a class that can be shared
with the DAS.



 Comments   
Comment by Jennifer Chou [ 04/Aug/10 ]

Defer to 3.2

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-13213] failed commands should not be listed as pending changes. Created: 31/Aug/10  Updated: 22/May/13

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

Type: New Feature Priority: Major
Reporter: easarina Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: Sun


Issuezilla Id: 13,213

 Description   

Build 18 08/31

I've generated two failed deployments: first deployment failed because of JNDI
name conflict. In second case a directory deployment failed for second instance
because this directory was presented on the remote machine. So in both cases
either _deploy or _instanceValidateRemoteDirDeployment commands failed. But then
these commands were listed between pending changes. I don't think that the
failed commands have to be listed as pending changes.
==========================================================
asadmin deploy --target c2 --name stateless-simple:1
archives_nodb/stateless-simple.ear
Application deployed successfully with name stateless-simple:1.
WARNING : Command _deploy did not complete successfully on server instance in3 :
remote failure: Failed to load the application on instance in3. The application
will not run properly. Please fix your application and redeploy.
Exception while loading the app : java.lang.RuntimeException: EJB Container
initialization error. Please see server.log for more details.
EJB Container initialization errorException while invoking class
org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException:
EJB Container initialization error
EJB Container initialization error

WARNING : Command _deploy did not complete successfully on server instance in4 :
remote failure: Failed to load the application on instance in4. The application
will not run properly. Please fix your application and redeploy.
Exception while loading the app : java.lang.RuntimeException: EJB Container
initialization error. Please see server.log for more details.
EJB Container initialization errorException while invoking class
org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException:
EJB Container initialization error
EJB Container initialization error

Command deploy executed successfully.

asadmin deploy --target c1 --name webapp:1 webapps-caching
remote failure: A supplemental command failed; cannot proceed further
Command _instanceValidateRemoteDirDeployment failed on server instance in2 :
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

Command deploy failed.
asadmin list-instances
in1 running
in2 running; requires restart [pending config changes are :
_instanceValidateRemoteDirDeployment
/opt/appserver-sqe/pe/deployment_v3/webapps-caching/; ]
in3 running; requires restart [pending config changes are : _deploy
/opt/glassfishv3/glassfish/domains/domain1/applications/__internal/stateless-simple~1/stateless-simple.ear;
]
in4 running; requires restart [pending config changes are : _deploy
/opt/glassfishv3/glassfish/domains/domain1/applications/__internal/stateless-simple~1/stateless-simple.ear;
]
a1 running
a2 running

Command list-instances executed successfully.



 Comments   
Comment by vijaysr [ 31/Aug/10 ]

"I don't think that the failed commands have to be listed as pending changes." - No, that is the real
intention.

Deployment (which changes the config of the intended target and hence is a config change) is
attempted on an instance. Deployment fails. So that instance is flagged as pending config change - this
is what the restart-required feature with additional info is meant for.

In your scenario, deployment of stateless-simple.ear failed on instances in3, in4 of cluster c2.
Deployment of webapps-caching failed on instance in2 of cluster c2. When you do list-instances, this is
what is exactly displayed and this is the intention.

The whole intention of listing pending config changes is to let the admin know which commands failed
so that the admin can decide when to restart the instance.

As I said, I need to understand what the real issue here is.

Comment by easarina [ 31/Aug/10 ]

The failed comands did not create any changes. So the result of their execution
can not be "pending changes".

Comment by vijaysr [ 31/Aug/10 ]

I am trying to understand which failed command did not make any change ? The second deployment ?

Comment by easarina [ 31/Aug/10 ]

In both cases no changes were made. In first case the deployment totally
failed. In second case the directory deployment did not happen for second
instance, because the directory was not presented on that machine. So again,
no changes.

Comment by vijaysr [ 07/Sep/10 ]

Changing state as per bug scrubbing process
(http://wikis.sun.com/display/GlassFish/Bug+Scrubbing+Process)

Comment by vijaysr [ 21/Oct/10 ]

I tried some different ways of solving this issue but none of them is generic enough to enable all
commands behave the same way.

As of now, any failure in command replication, forces the instance state to be changed along with the
"pending config changes are ..." message. This happens even with commands that do only read
operation like get commands. This is as per the smaller scope impl of instance state :
http://wikis.sun.com/display/GlassFish/Phase+1

Ideal solution will be for the framework to give a way for the command impl to specify that the
command is doing a read only operation (through some annotation like @ReadOnly). We can also
achieve this with some enhancement to the the AdminLock facility that was introduced towards end of
MS5.

Implementing a complete solution at this stage requires introduction of new annotation, change to all
commands to use this new annotation etc. So I am changing this as a feature request for 3.2.

For this release, any failure during command replication will result in the behavior mentioned in this
bug since what has been implemented is http://wikis.sun.com/display/GlassFish/Phase+1

Comment by vijaysr [ 28/Oct/10 ]

Transferring requested / planned enhancements for 3.2 to Tom to be reassigned to appropriate engineers
later

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-13574] asadmin command to tell you where a running Glassfish thinks Java is Created: 22/Sep/10  Updated: 28/Jun/13

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

Type: New Feature Priority: Major
Reporter: ljnelson Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,574

 Description   

It would be nice to type something like

asadmin java

...and have it return the path to the java executable that Glassfish is running
under. Obviously there are many other ways to accomplish this, but for
debugging the (undocumented, required on Windows) manual setting of AS_JAVA in
config\asenv.bat, it would be most helpful. It would also be helpful in blind
installs, i.e. those conducted by a knowledgeable Glassfish person over instant
message with a non-Glassfish-knowledgable operator.



 Comments   
Comment by Tom Mueller [ 22/Sep/10 ]

This doesn't do exactly what is requested, but:

asadmin version --verbose

prints the version of Java that is being used. There is a --local and non-local
version of this so you can get the Java version for both asadmin and for the DAS.

Maybe the path to Java could be added to that if it is available.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-13504] start-cluster should not require an operand if the DAS has only one cluster specified Created: 16/Sep/10  Updated: 22/Mar/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 13,504

 Description   

The operand of start-cluster should default if there is only one cluster defined
in the DAS' configuration.



 Comments   
Comment by Joe Di Pol [ 16/Sep/10 ]

Looks like v2 requires a cluster name:

$ ./asadmin start-cluster
Usage: start-cluster [--terse=false] [--echo=false] [--interactive=true] [--host
localhost] [--port 4848|4849] [--secure|-s=true] [--user admin_user]
[--passwordfile file_name] [--autohadboverride true|false]cluster_name
CLI020 Operand is required.

So this is not required to be compatible with v2.

We would want to be consistent with other commands in v3. For example
start-instance and stop-instance require an instance name even if there is only
one instance in the domain. If we were to make this change to
start-cluster/stop-cluster we would probably want to change those commands as well.

I'm not inclined to implement this in 3.1 unless some larger consensus forms.





[GLASSFISH-13886] backup_domain omits nodes from backups Created: 08/Oct/10  Updated: 08/Oct/10

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 13,886

 Description   

I backed up a domain in which I had created nodes and instances.

After the domain is restored from the backup, the domain fails to start. The log
file suggests the domain failed to start because no instance directories for
instances in the DAS configuration were found.



 Comments   
Comment by Chris Kasso [ 08/Oct/10 ]

As originally designed the backup-domain command only backups up the domain
(e.g. contents of the <install dir>/domains/<domain name>). It does not backup
up any instances or nodes that also happen to be configured on the DAS.

I think in production deployments the DAS would generally not have any local
nodes or instances but I could see how a developer would like to be able to
backup the domain, nodes and instances to migrate to a new version.

I'm going to change this issue to an enhancement where backup-domain offers an
option to also backup up nodes on the DAS.





[GLASSFISH-13874] Calling every default virtual server "server" is confusing Created: 07/Oct/10  Updated: 23/Mar/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 13,874

 Description   

build: glassfish-3.1-b23-10_07_2010.zip

Currently, for every server instance that's created, default virtual server is
called "server". This is confusing when operating on virtual server level
through admin gui, since it's hard to tell what "server" user is operating on.
Of course we could add a top level location information on the Virtual Servers
page, for example, that would specify that this page refers to e.g. standalone
instance in1. However, there are more places where this may be confusing (e.g.
deploying applications). Hence my proposal is to change the default virtual
server name such that it would include the instance name it belongs to. This
could be virtualserver-<instance name> or some such.

I'm logging this under Admin Console, since the confusion is more pronounced
here. Please reassign as needed. In the least we will need to modify pages
that operate/reference virtual servers, so that it is clear which "server" user
operates on.



 Comments   
Comment by Anissa Lam [ 07/Oct/10 ]

The out of box default configuration has a default virtual server named
"server", and thats why every config has a VS named "server".

admin team needs to fix this, not gui.

Comment by Tom Mueller [ 08/Oct/10 ]

The virtual server name cannot be different on every instance within a cluster,
because the name is determined by the config, which is shared by all instances.

Theoretically, when a config is created or copied, the virtual server name could
be modified. Or in the default-config, the virtual server could be called
"instance" rather than "server" (or something else different from "server"). Not
sure if this would resolve the confusion.

It's also conceivable that this really is a presentation problem in the console.

Comment by Tom Mueller [ 23/Mar/11 ]

This is not planned for the 3.2 release so moving it to future-release.
I'm tempted to resolve this as "won't fix" because the suggested solution of having the instance name in the VS name would not work for a cluster.





[GLASSFISH-13769] Support nested token substitution Created: 02/Oct/10  Updated: 05/Oct/10

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

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

Operating System: Linux
Platform: All


Issuezilla Id: 13,769

 Description   

1. Login to admin console, create cluster's instance (I used server
configuration copy).
2. Ensure that admin listener has assigned port as reference
$

{ASADMIN_LISTENER_PORT}

3. Go to Configurations-> (instance config) -> System Properties.
4. Add property INSTANCE_PORT_BASE and set default value, then save.
5. Edit ASADMIN_LISTENER_PORT property, and set default value to eg.
$

{INSTANCE_PORT_BASE}

4848.
6. Start choosed cluster's instance with this config.

Instance is starting correctly, and listens on desired port (above e.g. 14848),
but console hangs up, and in log I got:
[#|2010-10-02T19:25:51.676+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=15;_ThreadName=Thread-1;|Cannot
read logging.properties file.
Waiting for the server to start ............
Successfully started the instance: cluster2-instance1
instance Location:
/home/radek/opt/glassfishv3.1/glassfish/nodes/localhost/cluster2-instance1
Log File:
/home/radek/opt/glassfishv3.1/glassfish/nodes/localhost/cluster2-instance1/logs/server.log
Admin Port: -1
Command start-local-instance executed successfully.|#]

Kind regards,
Radosław Smogura
http://www.softperience.eu



 Comments   
Comment by Anissa Lam [ 02/Oct/10 ]

I think the problem is with the fact for using 'server-config' to create the
cluster's instance.
Any change you enter for this also affects the DAS.
In fact, I believe the config should not allow 'server-config' to be one of the
choice, this is also causing issue# 13534.

Can you try choosing the 'default-config' instead ?

Comment by Tom Mueller [ 02/Oct/10 ]

Are you trying to access the admin console on an instance? That isn't allowed.

Comment by rsmogura [ 04/Oct/10 ]

The problems with creating an instance with server "server-config" are different
kind of problems...

Backing to topic.
I don't access cluster instances' admin console (but this could be funny), I
wanted to create general configuration based on properties that adds port prefix
to all system properties stored in configuration (eg. when you create new
configuration you have $

{ASADMIN_LISTENER_PORT} to be setted for e.g. 25678, i
setted ${ASADMIN_LISTENER_PORT}

variable to "$

{INSTANCE_PORT_BASE}4848", so I
don't change admin listener configuration and I leave there
${ASADMIN_LISTENER_PORT}, which is properly expanded on instance start to 14848
(prefix = 1).

I suspect problem is in DAS (or node agent) because it doesn't correctly expand
nested properties, probably when it creates instance it reads admin listener as
${admin_port}, and expands it to "${prefix}4848", which can't be converted to
integer (Admin port: -1 in log). When I will remove ${INSTANCE_PORT_BASE}

from
$

{ASADMIN_LISTENER_PORT}

and set there explicitly 14848 log says Admin Port: 14848.

Bear in mind that instance starts correctly, netstat shows port binds, but just
DAS says instance isn't running (because it can't connect with "-1" admin port).

Comment by rsmogura [ 04/Oct/10 ]

Few word more to clarify, when I wrote "console hangs up" I was thinking about
never ending busy cursor, on DAS admin console, after clicking start instance

Comment by Anissa Lam [ 04/Oct/10 ]

Thanks for the clarification and details.
This sounds like a backend issue, I am going to transfer to 'admin' for further
evaluation.

Comment by Tom Mueller [ 04/Oct/10 ]

It is true that there is no double (or recursive) property substitution. So
currently you cannot do:

<network-listener port="$

{ASADMIN_LISTENER_PORT}

" protocol=...
<system-property name="ASADMIN_LISTENER_PORT" value="$

{index}

4848" />
<system-property name="index" value="2"/>

If that is what is desired here, please refile this as an RFE.

Comment by rsmogura [ 05/Oct/10 ]

I wanted to do exactly what You wrote. I change this to RFE, but I'm not sure
it's good idea, as the instance starts as I want, but DAS doesn't sees it.





[GLASSFISH-13711] Injection of state from main to supplemental commands Created: 29/Sep/10  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: future release

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,711
Tags: ee7ri_cleanup_deferred

 Description   

The main says it all :

Vijay Ramachandran wrote on 09/29/10 10:16 AM:
> Bill,
>
> thanks for your comments : response in line.
>
> On 9/28/10 11:57 PM, Bill Shannon wrote:
>> Vijay Ramachandran wrote on 09/28/2010 03:08 PM:
>>>
>>>>> I'm going to look into your #1 suggestion. Vijay has given me some pointers:
>>>>> * _register-instance comes to DAS. Mark it for DAS only
>>>>> * have a supplemental, _register-instance-at-instance (annotated with
>>>>> RuntimeType.Instance), to _register-instance
>>>>> * set required info in some object and set this object in ActionReport in
>>>>> _register-instance
>>>>> * _register-instance-at-instance will get the above object to get to know the
>>>>> params; it will know the targets; it can use the ClusterOperationUtil to
>>>>> replicate the command
>>>>> * Look at PaameterMapExtractor to convert injected params in an pbject back
>>>>> into
>>>>> a Map
>>>> I don't understand this need to add an object to ActionReport.
>>>> Why can't you pass the required information as parameters to
>>>> the _register-instance-at-instance command in the normal way?
>>>
>>> Here is the flow of the replication framework :
>>>
>>> * Command comes in; all checks are done
>>> * CommandRunner does param injection
>>> * Main command impl is called
>>> * If completed successfully, all supplementals called
>>>
>>> The Main command impl does not get the parameter map at all. Everything is
>>> injected. And the framework gets back control after main command exec is over
>>> and before it starts supplementals. There is no way for the main command to
>>> pass new info / modify existing info for the sake of its supplementals. So
>>> Jerome and I decided to use ActionReport as the channel through which a main
>>> command can pass info (any kind of info) to its supplementals.
>>
>> Maybe doing this with a supplemental command isn't the right approach?
>> Maybe the main command should explicitly invoke the replication command?
>>
>> Using ActionReport to pass this state from one command to another seems
>> like a bit of a kludge.
>
> This new "facility" in ActionReport is to enable main command pass any
> information to its dependents. When an instance is added to a cluster, JMS
> broker and load balancer supplementals get info on what has been done by the
> main command. Here in this scenatio, an instance registers itself with DAS and
> as a result, the register-instance command passes on info to be given to its
> supplementals who may or may not use it. I am not sure if this info can be
> termed strictly as state of that command, can we ? It is more like the result of
> execution of the main command, isn't it ? There may be a thin line that
> differentiates a state from other info but I am not sure if we are really
> crossing the line here.

I'm assuming it's state that the supplemental command could not simply
discover itself by looking at the global state of the server and config.

>> If the commands aren't really independent (as
>> these aren't), why not couple them explicitly instead of implicitly?
>
> Going back to my previous example, a JMS broker / load balancer have to be
> updated when a new instance is added to a cluster. Are these dependent or
> independent ? The whole premise behind supplemental command is to give a way for
> dependent commands to be executed upon completion of main command but still keep
> the code separate, isn't it ? Instead of looking them as dependent / independent
> commands, the thumb rule I have been applying all along is "cause-effect" kind
> of relationship. Main command does "something" and as a result we have to do
> "other things". These "other things" are put as supplementals. So tomorrow, if
> we don't want one of the "other things" to happen, just take that supplemental
> out - no need to change code of main command.
>
> Deployment is the only case where we have taken lot of liberties but impl was
> easier that way. But anyways, deployment is a special case and we have been
> giving it some (actually lots of) flexibility.
>
> Does this address your concern ?

It seems that there's a contract between the main command and the supplemental
commands in these cases, but that contract is hidden in the implementation of
the commands. Shouldn't there at least be a way to declare these dependencies?
Couldn't we do something like what CDI does and have the main command have
an @Provides annotation on a method that returns the required state, and have
the supplemental commands @Inject that state?

Something like that would work fine in the case where a supplemental command
just wants to know that a new instance was added to a cluster, so it can
update it's corresponding state. But in the case we were talking about the
supplemental command was performing part of the required operation of creating
a new instance. In that case a tighter coupling seems appropriate.



 Comments   
Comment by vijaysr [ 29/Sep/10 ]

Got to look into this suggestion post 3.1; adding Bill to the CC list

Comment by vijaysr [ 21/Oct/10 ]

scrubbing the target release

Comment by vijaysr [ 28/Oct/10 ]

Transferring requested / planned enhancements for 3.2 to Tom to be reassigned to appropriate engineers
later

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-12586] Consolidate "Pinging" Backend Created: 08/Jul/10  Updated: 25/Jan/11

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

Type: Task Priority: Major
Reporter: Byron Nevins Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,586

 Description   

How do we find out if a server is running? A mess of calls to:

1) simple java.net socket calls
2) version command
3) uptime command
4) _directories commands

Perhaps we should go through and consolidate?

Assigning to Bill simply so that he can provide opinions/advice. Maybe make
this 3.2/4.0 ????



 Comments   
Comment by Bill Shannon [ 09/Jul/10 ]

Right now we have these:

LocalServerCommand.isRunning - simply tries to connect to the admin port
DASUtils.pingDAS* - executes the version command on the server
LocalServerCommand.isThisServer - uses __locations to make sure it's talking to
the correct server
LocalDomainCommand.isThisDAS - uses isThisServer
LocalServerCommand.getUptime - used when restarting

A bunch of stuff uses isRunning. A few things use pingDAS*.

The problem with isRunning is that it doesn't tell you if the server you're
asking about is the server that's actually running.

I suspect what we really need is a new method that uses __locations and also
returns detailed failure status like pingDASWithAuth, at least for the cases
where we're asking about the DAS. When asking about an instance, we may have
to settle for isRunning.

Comment by Tom Mueller [ 25/Jan/11 ]

Clear the Fix version since this issue isn't going to be fixed for 3.1.





[GLASSFISH-8521] stop-domain should stop OSGi framework if start-domain has started it Created: 14/Jun/09  Updated: 05/Apr/11

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 8,521

 Description   

Currenty, stop-domain command does not stop OSGi framework. It only stops the
primordial bundle, but that can't stop bundles started outside the knowledge of
GF management agent. e.g., bundles in autodeploy-bundles/ which are managed by
fileinstall. SO, we must stop framework when we own it. Stopping framework will
ensure stopping of all bundles.



 Comments   
Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

It's an RFE.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in V3.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-8455] Need to detect wrong user is at the controls Created: 27/May/09  Updated: 22/May/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 8,455
Tags: 3_1-exclude

 Description   

This is a Felix Issue – but there is no Subcomponent for core or startup or
OSGi so I just set it to Admin for now.

==================================
Scenario:

Normal GF installation.
logged in as non-root user
start the domain
stop the domain
login as root
start the domain
stop the domain
login as normal user again.

That's all folks – you can never start the server again. Only root can.

No messages appear in server.log.

But ALL the messages appear in the window when starting this way:
asadmin start-domain --verbose

There are hundreds of the following errors (I just have a few here because they
are all very similar)

Auto-properties install: org.osgi.framework.BundleException: Unable to cache
bundle: file:/export/home/bnlocal/glassfishv3/glassfish/modules/osgi-main.jar
Auto-properties start: org.osgi.framework.BundleException: Unable to cache
bundle: file:/export/home/bnlocal/glassfishv3/glassfish/modules/osgi-main.jar
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
(java.io.FileNotFoundException:
/export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle140/version0.0/revision.location
(Permission denied))
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
(java.io.FileNotFoundException:
/export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle141/version0.0/revision.location
(Permission denied))
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
(java.io.FileNotFoundException:
/export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle142/version0.0/revision.location
(Permission denied))



 Comments   
Comment by Byron Nevins [ 27/May/09 ]

I did not set this Issue to P1 only because there is an easy work-around:

          • WORK-AROUND *****
            1) login as root
            2) rm -rf install-dir/domains/domain1/felix-cache
            3) Now you can start the domain from non-root account
Comment by Richard S. Hall [ 27/May/09 ]

Isn't this normal? Felix can only write to where it has permission to write. If
you create a cache with root ownership, then it makes sense that you cannot use
a non-root user to access it.

Comment by km [ 27/May/09 ]

I agree with Richard. You should only get to run the domains that you own. In
this case, since the root has a permission to do anything on local file system,
it is actually able start your domain in first place. If you manage the
permissions properly, the root a/c on this machine probably will not even be
able to start domain owned by you.

AFAIK, felix cache not being readable by another user is one of the defenses we
have for the server startup to fail if started by that user. To be better,
Byron, you should try to do the same experiment with two normal non-super-user
accounts, say "joe" and "blo". Neither of them should be able to start the
domain who is owned (on the file system) by the other. This is also the reason
why the doman's config folder has 0600 permissions. Alas, it does not work with
super-user ...

Comment by Byron Nevins [ 27/May/09 ]

Below is what you get when you try to start a domain with Joe trying to start
Blow's domain:

-bash-3.00$ asadmin start-domain
java.io.IOException: Couldn't get lock for
/export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log
at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
at java.util.logging.FileHandler.<init>(FileHandler.java:270)
at
com.sun.enterprise.admin.launcher.GFLauncherLogger.addLogFileHandler(GFLauncherLogger.java:98)
at com.sun.enterprise.admin.launcher.GFLauncher.setup(GFLauncher.java:150)
at
com.sun.enterprise.admin.cli.StartDomainCommand.runCommandNotEmbedded(StartDomainCommand.java:82)
at
com.sun.enterprise.admin.cli.StartDomainCommand.runCommand(StartDomainCommand.java:47)
at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:171)
at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:105)
at com.sun.enterprise.admin.cli.AsadminMain.local(AsadminMain.java:126)
at com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:77)

Comment by Byron Nevins [ 27/May/09 ]

Lowering priority.

I think it is important for GF to be more self-aware. These messages
indirectly say what the problem is but you have to figure them out. GF will
look smarter if it does this interpretation itself. Also not starting a domain
is catastrophic and worth a few cycles developing extra code.

Recommended Fix:
In ASMAin do the checks and spit out an appropriate message if the permissions
are not correct.

checks:
a) File.canWrite() on the felix cache dir if it exists
b) File.canWrite() on domain.xml

                          • BEFORE **************
                            (1)
                            ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
                            (java.io.FileNotFoundException:
                            /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle141/version0.0/revision.location
                            (Permission denied))

or

(2)
java.io.IOException: Couldn't get lock for
/export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log

                          • AFTER **********************

You do not own this domain and/or have the correct OS privileges. You are not
allowed to start this domain. Blah blah blah...

Comment by Byron Nevins [ 27/May/09 ]

One more thing.

If you get into this situation – you will not see any error messages at all
from asadmin – unless you run with --verbose. Here is what start-domain says:

Domain (domain1) did not respond in 90 seconds. It means it is still coming up
or it has failed to come up. Check server.log for details.

Of course there is nothing in server.log because you did not have permission to
write to it!

But you can read it and see nothing:

rw-rr- 1 bnlocal other 0 May 27 10:10 server.log

Comment by km [ 27/May/09 ]

I personally think we should rather check for the permissions on domain.xml than
depending on Felix Cache or Log File. But since it's Felix that starts way too
early in the startup, it may be appropriate to do these checks there.

Sahoo – do you mind taking a look into ASMain and fixing it like Byron suggests?
If you think it should instead be fixed elsewhere, let me know or assign it to me.

Comment by km [ 27/May/09 ]

Now the right Sahoo ...

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

There are other code which gets executed during server startup before Felix is
started. So, I suggest we do this security check early in the startup process.
Any way, I don't have time to do this now. So, feel free to fix or attach a patch.

Comment by km [ 18/Sep/09 ]

Sahoo, I understand that you don't have time to look into this now, but
assigning this to me is something of a surprise. I thought you owned ASMain.

Comment by Tom Mueller [ 14/Feb/11 ]

This issue still exists in GlassFish 3.1 and the trunk. However, to see the behavior, it is necessary to remove the domain1/osgi-cache directory before starting the domain as root so that the entire osgi-cache is created by root.

Bumping up the priority based on the age of the issue and targeting for 3.2.

Comment by Tom Mueller [ 28/Feb/11 ]

Marking this as an RFE.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-12778] DAS should have a hostname in d.x Created: 23/Jul/10  Updated: 03/Apr/12

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

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

Operating System: All
Platform: All


Issue Links:
Related
is related to GLASSFISH-17421 DAS sometimes uses wrong DAS hostname... Open
Issuezilla Id: 12,778
Tags: 3_1-exclude

 Description   

While implementing the configbean ducktyped method:

getHost()

I realized that it is impossible to figure out the hostname for DAS from looking
in domain.xml

We should consider adding a node element for DAS so we can specify the node.

Instances can then easily find the DAS hostname w/o messing with das.properties
file.

Currently if an instance calls getHost() on DAS's Server instance – null is
returned.



 Comments   
Comment by Tom Mueller [ 23/Jul/10 ]

Not sure who should do this. Trying Joe first...

Comment by Joe Di Pol [ 23/Jul/10 ]

I suppose the DAS could auto-create (and auto-update if anything changes) a node
like:

<node name="DAS" node-host="das.host.name.com"
install-dir="/gf/install/location/of/das"/>

Problems with this:

1) No admin port number like in das.properties – but I suppose that is
available elsewhere in domain.xml

2) We have duplication of state (violates DRY/DIE principle). What is the truth?
The hostname in das.properties or the one in domain.xml? How are they kept in sync?

Comment by Joe Di Pol [ 28/Sep/10 ]

Deferring to a future release since I think we can get by for now without this.

Comment by gfuser9999 [ 03/Apr/12 ]

Actually the admin-listener is the one that determines
the contact name of the DAS. So all the
information is there since the admin-listener
permit one to set the "server-name"
Unfortunately even if this is set, the code
does not take/make use of this.

In the same token, when accessing the say
http://das.foo.com:4848 it will issue a redirect
and this does a redirect without FQDN
and goes to "https://das:4848" IF HTTP/1.0
protocol is forces. (same issue here
server-name not made use of)





[GLASSFISH-9489] asadmin get "*level*" produces no result Created: 11/Sep/09  Updated: 22/May/13

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

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

Operating System: All
Platform: Sun


Issue Links:
Dependency
blocks GLASSFISH-15458 Rewrite asadmin set, get, list subcom... Open
Issuezilla Id: 9,489
Tags: ee7ri_cleanup_deferred

 Description   

bin/asadmin get "level"

Command get executed successfully.

vs.
bin/asadmin get "*" |grep level
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jersey=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jpa=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.orb=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.security=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=OFF
configs.config.server-config.monitoring-service.module-monitoring-levels.web-services-container=OFF
resources.jdbc-connection-pool.DerbyPool.is-isolation-level-guaranteed=false
resources.jdbc-connection-pool.__TimerPool.is-isolation-level-guaranteed=true



 Comments   
Comment by marina vatkina [ 11/Sep/09 ]

...

Comment by km [ 22/Sep/09 ]

Sreeni, is that you?

Comment by msreddy [ 24/Sep/09 ]

This does not work in v2 also.

jyothi[150]: ./asadmin version
Version = Sun Java System Application Server 9.1.1
Command version executed successfully.

jyothi[151]: ./asadmin get "level"
No value name specified = level
CLI137 Command get failed.
jyothi[152]:

Marking as RFE.

Comment by sankarpn [ 24/Sep/09 ]

Byron made a fix for this, but with flag --monitor. May be we can port that to
the config tree as well.

asadmin get -m "jspsloaded"

server.applications.standalonewebmod1.server.activejspsloadedcount-current = 0
server.applications.standalonewebmod1.server.activejspsloadedcount-description =
Number of active JSP pages
server.applications.standalonewebmod1.server.activejspsloadedcount-highwatermark = 0
server.applications.standalonewebmod1.server.activejspsloadedcount-lastsampletime =
1253829363800
server.applications.standalonewebmod1.server.activejspsloadedcount-lowwatermark = 0

Comment by Byron Nevins [ 08/Nov/10 ]

.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-11253] possibility to update jvm-options Created: 04/Dec/09  Updated: 22/May/13

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

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

Operating System: FreeBSD
Platform: All


Issuezilla Id: 11,253

 Description   

In current situation to change value of JVM option we have to delete the option
first and then create it again.
I suggest to introduce new parameter "--replace" to command "create-jvm-options"
that will force to update value of the same parameter in case it already exists.
Without this parameter the same option appears twice if it was already exists
before the command "create-jvm-options" started.



 Comments   
Comment by Hong Zhang [ 04/Dec/09 ]

assign to admin team for evaluation

Comment by Tom Mueller [ 06/Jan/11 ]

There are several flavors of JVM options that can be set:

1. "plain" options, such as -client, -server, -esa, etc. Some of these are related to one another. For example, if setting -d32, then if there is a -d64 option, it should be replaced.

2. value options without an equals, such as -Xmx512m. If setting -Xmx256m, then -Xmx512m should be replaced.

3. value options with an equals, such as -Da=b or -XX:MaxPermSize=192m. If setting -Da=c, then -Da=b should be replaced.

Since options in flavor 3 are not cumulative, the create-jvm-options command could just automatically provide the replacement behavior without a --replace option. Maybe a warning could be printed to say that replacement is happening. Is there any situation where adding multiple options with the same value before the "=" is desired?

For options in flavors 1 and 2, the create-jvm-options command would need to have knowledge about the options and how they are related, which increases the coupling between the create-jvm-options command and a particular JVM.

For -Xmx and -Xms, the create-jvm-options already has this coupling, but rather than replacing and existing value for one of those options, it adds the additional option and warns that there was already an option for that value (which doesn't seem to be the right behavior).

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-10340] delete-system-property should include the element name as well while printing the error Created: 16/Oct/09  Updated: 22/May/13

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

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

Operating System: All
Platform: PC


Issuezilla Id: 10,340
Tags: 3_1-exclude

 Description   

When you try to delete the system property which is in use it fails with the
message that the property is in use. But it doesn't print the config element in
which the property is referenced.

In the following case the listener httpls1 is referencing the property, the
error message should say the property is in use by the element httpls1.

aroot@easqeopt19:~# asadmin delete-system-property port
com.sun.enterprise.admin.cli.CommandException: remote failure: System Property
port is referenced by [network-listener:port] in the configuration. Please
remove the references first.

Command delete-system-property failed.

aroot@easqeopt19:~# asadmin get "*" | grep httpls1
configs.config.server-config.network-config.network-listeners.network-listener.httpls1.port=$

{port}

 Comments   
Comment by km [ 16/Oct/09 ]

Sure, later.

Comment by Tom Mueller [ 15/Feb/11 ]

Upping the priority based on the age of the issue. Changing this to an RFE.

This is a change to the DeleteSystemProperty.listRefs method, to add the value of a "name" attribute, if it exists.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-10266] provide command to delete services Created: 14/Oct/09  Updated: 17/Oct/12

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

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

Operating System: Solaris
Platform: PC


Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Issuezilla Id: 10,266
Tags: ee7ri_cleanup_deferred

 Description   

currently there is command to create the service but there is no commands to
delete/list the service entries without the user interacting with the OS. Would
be nice to have this feature.



 Comments   
Comment by Bill Shannon [ 14/Oct/09 ]

I think I made the same comment some time ago...

Comment by Byron Nevins [ 14/Oct/09 ]

Let's see if a day frees up before nov 9 to do this. It is probably worthwhile.
I forget the intricate OS commands almost instantly after running create-service.

It would add much value...

bumping to P3/defect for now.

Comment by Byron Nevins [ 26/Oct/09 ]

Changed to RFE

Probably won't be time to implement and document for 3.0

Comment by Byron Nevins [ 25/Jan/10 ]

Increased priority etc.

Comment by kumara [ 04/Feb/10 ]

Not required for v3.0.1 and therefore being retargeted to v3.1

Comment by Byron Nevins [ 06/Jul/10 ]

ms4

Comment by Byron Nevins [ 18/Aug/10 ]

No time for ms4.
I'm setting to 3.1 in case time is available post ms5

Comment by Nazrul [ 28/Oct/10 ]

Will consider in 3.2

Comment by Byron Nevins [ 01/Apr/11 ]

feature not bug..

Comment by Byron Nevins [ 15/Apr/11 ]

also stop and start

Comment by Byron Nevins [ 02/May/11 ]

Changed this issue to be just for delete-service

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-10200] create-network-listener: validate that transport and thread pool exist if specified in options Created: 12/Oct/09  Updated: 25/Jan/11

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

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

Operating System: All
Platform: PC


Issuezilla Id: 10,200
Status Whiteboard:

v3_exclude


 Description   

When the network listener is created with --transport mytcp and --threadpool
mypool it is simply referenced when the network listener is created. The user
has to create the transport and threadpool separately before he uses the listener .

Why not create the transport and threadpool if it doesn't exist in the
domain.xml and reference it, which will make the life easier for a developer who
wish to create a listener without bothering about so many other commands.

Ideally we should be doing this.

1. If the option is not specified use the default values
2. if the option is specified and and elements already exists in domain.xml
reference it
3. If the option is specified and the elements doesnot exists in domain.xml
create new transport/threadpool's elements and reference it.



 Comments   
Comment by Justin Lee [ 12/Oct/09 ]

create-http-listener does, in fact, do this to maintain funcationality of v2.
create-network-listener does not as this is consistent with other creates in
that it creates only the one element. I'm not opposed to doing this but if we
go this route, we might as well have create-network-listener just be an alias
for create-http-listener. And that's ok with me, too.

I'm not sure who should make that decision, though. In short, though, this
command works as intended and there is no bug here, per se.

Comment by sankarpn [ 12/Oct/09 ]

I agree that the command is working as intended and there is no bug, but If I
file it as a RFE its not going to be done for V3. This is a good time to
implement it right and make it more developer friendly.

cc'ing Jerome and Bill for their comments.

Comment by Justin Lee [ 12/Oct/09 ]
      • Issue 10193 has been marked as a duplicate of this issue. ***
Comment by Justin Lee [ 13/Oct/09 ]

this isn't a defect

Comment by Bill Shannon [ 13/Oct/09 ]

I haven't spent a lot of time looking at this, but...

If --transport or --threadpool aren't specified, and the create-network-listener
command can create or use default transports or thread pools, I agree that that
would be a good thing to do.

But if --transport or --threadpool are specified, I would expect them to
reference existing elements, which would need to be created separately.

Comment by sankarpn [ 13/Oct/09 ]

>If -transport or --threadpool aren't specified, and the create-network
>listener command can create or use default transports or thread pools, I
>agree that that would be a good thing to do.

In this case referencing the defaults will be good, since the developer didn't
specify threadpool/transport it might mean that he doesn't bother to tinker
those entities and defaults are good enough for him.

>But if --transport or --threadpool are specified, I would expect them to
>reference existing elements, which would need to be created separately

Good too, but if the elements doesn't exist and it is specified we should fail
the command to let the user know that he should create those elements first.

I just want to make sure that there is a trail for the developer to tell what
needs to be done instead of letting him dig through the documents to make things
work.

Comment by Justin Lee [ 14/Oct/09 ]

Using the deafult transport/threadpools would work. create-http-listener
already tries to grab those and creates new ones if they can't be found. Now,
this creates an implicit requirement that those names don't change (e.g., the
default transport is named "tcp" and the default threadpool is
"http-threadpool-1") but that's ok most of the time.

Requiring that any explicitly named threadpools/transports already exists is the
right way, imo. It reduces the number of unintended silent modifications that
might not be what the user wanted. create-http-listener creates these
structures on the fly but that's more to preserve compatibility with v2 behavior
than anything else.

If this is what we want then this one should get reassigned to nandini as this
is her area. If you can confirm, bill, that this is what you'd like to see then
I'll reassign this one.

Comment by Bill Shannon [ 14/Oct/09 ]

I'm not sure whether it's better to use the existing (default?) transport
or thread pool, or whether it's better to create new ones just for use by
this listener (as create-http-listener does, apparently), at least in the
case where none was specified on the command. You'll have to assess which
approach would be more useful and least surprising to the user.

But if one is specified on the command, I think it's fair to say that it
must already exist.

Comment by Justin Lee [ 28/Oct/09 ]

excluding from the v3 release schedule

Comment by Tom Mueller [ 25/Jan/11 ]

Updated summary to reflect what this RFE is about.





[GLASSFISH-10076] start-domain: support reactive timeout Created: 07/Oct/09  Updated: 05/Apr/11

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

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,076

 Description   

We currently arbitrarily set a "one-size fits all" timeout in start-domain.

I suggest we cool-ify it like so:

1) Start with the usual timeout – 600 seconds or whatever.
2) For each of the very first 10 or 20 starts just note the actual start time in
a special file in the config directory or log directory.

    • 10-20 allows them some time to make their system more complicated.
    • Or we wait to see a pattern where the start times start to be +- 20% of each
      other
      3) Double that amount of time and make that the timeout
      4) If it times out we say something smart like:
      "Based on your domain's history it takes an average of 17 seconds to start. The
      domain failed to start in 34 seconds. Check the server log for problems.
    • we now reset to (1) and start collecting history again...

As a bonus this would be very useful for QE/Performance. We produce a file
automatically with startup times.



 Comments   
Comment by km [ 01/Nov/09 ]

bn

Comment by Paul Davies [ 18/Feb/11 ]

Consider also adding an option like --timeout to start-domain to give users some control over this behavior.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-10393] Add MacOS X service support Created: 19/Oct/09  Updated: 05/Apr/11

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

Type: New Feature Priority: Major
Reporter: ralphrmartin Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 10,393

 Description   

There needs to be some way to install glassfish so that

(a) it runs automatically at boot time, via Apple's /Library/LaunchDaemon mechanism

(b) it installs and runs as some user like _www rather than as a logged in user.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 19/Oct/09 ]

This really translates into adding MacOS support for 'asadmin create-service'
command. Adjusting the summary and moving to "admin" subcategory.

Comment by km [ 01/Nov/09 ]

bn

Comment by Byron Nevins [ 08/Mar/10 ]

I need access to a Macintosh

Comment by Byron Nevins [ 08/Mar/10 ]

I need access to a Macintosh

Comment by Byron Nevins [ 11/Mar/10 ]

No response – assuming not approved for 3.0.1

Comment by Byron Nevins [ 28/Sep/10 ]

3.2

Comment by ralphrmartin [ 28/Sep/10 ]

This is just receding into the distance. Why?

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-11692] create-service improvements Created: 17/Mar/10  Updated: 17/Oct/12

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

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

Operating System: Solaris
Platform: All


Attachments: Text File solaris_issues.txt    
Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Issuezilla Id: 11,692
Tags: ee7ri_cleanup_deferred

 Description   

Excellent comments from Jens Elkner.
See attached file for his entire email

Excerpts about SMF in particular:

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

(5.0) Create the SMF service as root or privileged user (RBAC SW admin)
using the command line (i.e. no GUI!!!)
Command:
+ $INSTALL_HOME/bin/asadmin create-service \
--domaindir $DATA_DIR $DOMAIN
Result:
a) if /var/svc/manifest/application/GlassFish does not yet
exist, create it with ownership root:sys and 0755
permissions.
b) MANIFEST=/var/svc/manifest/application/GlassFish/$DOMAIN.xml
with ownership root:sys and 0644 permissions. If that file
already exists, bail out with an appropriate error message
(e.g. $MANIFEST already exists. Please remove that service
first or choose another name ...)
c) $MANIFEST's start and stop method context should have
appropriate values, which reflect this instance. I.e.

  • working_directory = $DATA_DIR/$DOMAIN
  • method_credential user="$AS_USER"
    NOTE: since the instance must be able to write to its log
    directory, $AS_USER can be deduced from the ownership of
    $DATA_DIR/$DOMAIN/logs, i.e. there is not really a need
    for an --asuser switch wrt. create-service cmd (but might
    be beneficial for other use cases).
  • set privileges unconditionally to:
    "basic,!proc_session,!proc_info,!file_link_any"
  • if $AS_USER != "root" && $privatePortsInUse add
    'net_privaddr' to the privileges unconditionally
    NOTE: even if $AS_USER == "root" GF should never run with
    all available OS/role/user privileges. For the rare
    cases, where add. privileges are really required,
    they should be explicitly added by editing $MANIFEST
    or passing them via a TBD switch (e.g.
    --addprivs=proc_info[:...])
    d) add an appropriate property group to the $MANIFEST's instance.
    E.g.
    <property_group name='general' type='framework'>
    <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.glassfish' />
    <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.glassfish' />
    </property_group>
    For more fine grained permissions,
    solaris.smf.manage.glassfish.$DOMAIN might be also an option
    e) Optional: document the new auths if not already done. E.g.:
    echo 'solaris.smf.manage.glassfish.:::GF Management' \
    >>/etc/security/auth_attr,
    emit a message, that the new auths (which) have been created
    f) import the $MANIFEST
    g) emit svcadm|svccfg hints

(5.1) As an alternative to (5.0) - Create an appropriate Manifest ready
for SMF import as unprivileged user (e.g. $AS_USER) using the
command line (i.e. no GUI!!!)
Command:
$INSTALL_HOME/bin/asadmin create-service \
[--out $file] \
--domaindir $DATA_DIR $DOMAIN
Result:
a) if --out is given, set MANIFEST=$file
otherwise use MANIFEST=$DATA_DIR/$DOMAIN/manifest.xml
b) same as (5.0) c)
c) same as (5.0) d)
d) emit a hint, where one should put the manifest and how to
import it. E.g.:
'Please ask your system administrator to import the SMF
manifest "$MANIFEST", so that this instance gets
automatically stopped/started on system shutdown/boot
respectively using the following commands:

cp $MANIFEST /var/svc/manifest/application/GlassFish/$DOMAIN.xml
svccfg import /var/svc/manifest/application/GlassFish/$DOMAIN.xml
svcadm enable glassfish/$DOMAIN

Also you may ask your Admin to allow you to manage glassfish
instances by adding solaris.smf.manage.glassfish.* to your
auths. E.g.:
usermod -A 'solaris.smf.manage.glassfish.*,'`auths $USER` $USER
'
e) same as (5.0) g)

========================
c) Assuming the unprivileged user got its domain created (e.g. by
using the checkports option, asking the admin, etc.)
the next illness gets uncovered: E.g:

/opt/glassfish/v3/bin/asadmin create-service \
--domaindir /data/sites/glassfish/v3 jforum

The user [webservd] does not have permission to create the service
manifest related files and directories at
[/var/svc/manifest/application/GlassFish/]. This structure is required
per SMF guidelines. Either become super-user to do this operation or
contact the System Administrator to explicitly get the relevant
permissions and try again.
Usage: asadmin [asadmin-utility-options] create-service [--name <name>]
[--serviceproperties <serviceproperties>]
[--dry-run[=<dry-run(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Command create-service failed.

First hmm: Why is this message spoiled with the usage info?
2nd hmmm: A more or less relaxed admin might say - oh know,
don't bother me all the time with your crap:
mkdir -p /var/svc/manifest/application/GlassFish/
chown student:sgid /var/svc/manifest/application/GlassFish
and tell him 'send me an email, when you changed something'.

Student tries it again:

The user [student] does not seem to have adequate authorizations
[solaris.smf.*] on this System to create and configure an SMF service.
The authorizations available are
[solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq,solaris.admin.usermgr.read,solaris.admin.logsvc.read,solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,solaris.admin.diskmgr.read,solaris.admin.procmgr.user,solaris.compsys.read,solaris.admin.printer.read,solaris.admin.prodreg.read,solaris.admin.dcmgr.read,solaris.snmp.read,solaris.project.read,solaris.admin.patchmgr.read,solaris.network.hosts.read,solaris.admin.volmgr.read
].
See smf_security(5), rbac(5).

Usage: asadmin [asadmin-utility-options] create-service [--name <name>]
[--serviceproperties <serviceproperties>]
[--dry-run[=<dry-run(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Command create-service failed.

First hmmm: Why gets the message spoiled with the usage info?
2nd hmmm: Oh my goodness! I need to bother the admin again.
3rd hmm: the admin starts asking itself, what kind of strange
software is it, which requires solaris.smf.* just to be able to
create a manifest ...

So the SW designer made another fault: He tries to solve
two different problems at once (create the manifest, import it).

IMHO the correct and less annoying way is:
1) create the manifest as described in (5.0) c) and d)
2) try to copy it to /var/svc/manifest/application/GlassFish/$DOMAIN.xml
if that fails
a) store it as $DATA_DIR/$DOMAIN.xml
b) emit a warning 'Unable to save manifest as ....'
and a message as suggested in (5.1) d) and exit
3) try to import the manifest
if that fails, emit a warning like
'Unable to import manifest $MANIFEST (insufficient auths).' and
add a message similar to (5.1) d) but without the copy instruction
and exit

The hint wrt. /var/svc/manifest/application/GlassFish/ permission
is IMHO completely misleading and dangerous as well - so vaporize
it completely!

Furthermore the error message wrt. to solaris.smf.* auths required
is also misleading. The unexperienced user/admin @home interpretes
this actually as an instruction to assign those auths to the given
user, which is plain wrong (analog to the net_privaddr problem).



 Comments   
Comment by Byron Nevins [ 17/Mar/10 ]

Created an attachment (id=4272)
Email Comments

Comment by Byron Nevins [ 06/Jul/10 ]

ms4

Comment by Byron Nevins [ 17/Aug/10 ]

Not enough time to do this for MS4.

Set to MS5 for now...

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-9956] When asadmin is slow to start a domain, show useful information Created: 02/Oct/09  Updated: 17/Oct/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 9,956
Tags: ee7ri_cleanup_deferred

 Description   

Right now (b66), asadmin start-domain shows a sequence of dots ......... as the
server starts up. That is fine when the startup is reasonably quick, but it is
very annoying when, for some reason, the server doesn't start at all.

Suggestion #1. Do the Microsoft progress bar thing and have the rate of dots
decrease, so that they don't stupidly fill up the whole screen
Suggestion #2. Show a tip after a minute or so of waiting to run with --verbose.

But that's not enough. As Bill Shannon puts it, "if your domain configuration is
broken in certain ways, you can be left in a situation where it won't fully
start, won't die, and the start-domain command is left waiting for a very long
time".

I understand that the ... are generated by a client that is waiting for the DAS
server to start. Well, then the the server needs to describe the breakage in a
way that allows for troubleshooting.



 Comments   
Comment by Alexis MP [ 03/Oct/09 ]

Adding myself to CC list

Comment by Tom Mueller [ 10/Jan/11 ]

One suggestion for providing the illusion of progress without filling up the whole screen with dots is to use the rotating icon with backspaces. ^H^H|^H/^H^H^H|^H/^H

If issue 12033 is implemented, then the start-domain command might be able to get some sort of progress information from the server that would indicate whether progress is being achieved. Or, the start command could monitor the server.log file and indicate progress whenever a message is written to the log file.

Comment by Nazrul [ 02/May/11 ]

Chris is working on progress status. Assigning to him.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-12046] Add option to stop-domain that would stop clusters/instance Created: 25/May/10  Updated: 05/Apr/11

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

Type: Improvement Priority: Major
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,046

 Description   

This is an enhancement request for adding an option to stop-domain that would
automatically run stop-cluster for every cluster (which would stop the instances
in any cluster) and run stop-instance for every stand-alone instance that is not
in a cluster. With this option, a user would be able to bring down every
instance that is associated with a domain using a single command.

Several possible options for the option might be: --stop-instances or
--include-all-instances



 Comments   
Comment by Byron Nevins [ 28/Sep/10 ]

3.2

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-14649] RFE: Allow service to be scoped to DAS only Created: 12/Nov/10  Updated: 22/May/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,649

 Description   

Provide an interface similar to @ExecuteOn(RuntimeType.DAS) that could be used
to limit a PostStartup service to only being instantiated on the DAS or the
instances but not both.

Currently services are started on the DAS as a well as the instances
irregardless of whether they provide any service in that context.






[GLASSFISH-14426] RestartRequired: support undo functionality Created: 04/Nov/10  Updated: 22/May/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,426

 Description   

When changing certain configuration entries that cause Restart Required prompt,
it would be nice to have an "Undo" button for a given change. When viewing
Restart Required page the only possible action right now is to restart the server.

Also, currently, even if user changes values back to what they were, once
Restart Required shows up, it does not go away till server is actually restarted
(and it takes a while from Admin Console). It would be great if admin could
detect that a certain change became "undone", or reverted to previous state, and
no longer require a server restart. I'm logging this as an enhancement,
hopefully for the next release.



 Comments   
Comment by Anissa Lam [ 04/Nov/10 ]

This is good suggestion.
To be able to un-do previous config changes since server restart, and be able to 'revert' the restart-
required state when you un-do the config changes is something beyond gui.

Once backend put in this enhancement, GUI can put in necessary UI to support this.
So, transfer to 'admin'.

Comment by Tom Mueller [ 04/Nov/10 ]

Later...





[GLASSFISH-14113] The output of list-backups should be sorted by back up date. Created: 20/Oct/10  Updated: 05/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,113

 Description   

The output of list-backups does not appear to be sorted:

ouch: ./asadmin list-backups domain1
CONFIG USER BACKUP DATE FILENAME
mydaily kasso Wed Oct 20 10:22:46 PDT 2010 domain1_2010_10_20_v00008.zip
mydaily kasso Wed Oct 20 10:21:13 PDT 2010 domain1_2010_10_20_v00001.zip
mydaily kasso Wed Oct 20 10:22:31 PDT 2010 domain1_2010_10_20_v00006.zip
mydaily kasso Wed Oct 20 10:23:20 PDT 2010 domain1_2010_10_20_v00010.zip
mydaily kasso Wed Oct 20 10:22:40 PDT 2010 domain1_2010_10_20_v00007.zip
mydaily kasso Wed Oct 20 10:23:00 PDT 2010 domain1_2010_10_20_v00009.zip
mydaily kasso Wed Oct 20 10:23:40 PDT 2010 domain1_2010_10_20_v00011.zip
mydaily kasso Wed Oct 20 14:09:00 PDT 2010 domain1_2010_10_20_v00016.zip
mydaily kasso Wed Oct 20 14:08:40 PDT 2010 domain1_2010_10_20_v00015.zip
mydaily kasso Wed Oct 20 13:58:54 PDT 2010 domain1_2010_10_20_v00012.zip
mydaily kasso Wed Oct 20 10:21:40 PDT 2010 domain1_2010_10_20_v00003.zip
mydaily kasso Wed Oct 20 10:22:00 PDT 2010 domain1_2010_10_20_v00004.zip
mydaily kasso Wed Oct 20 14:08:00 PDT 2010 domain1_2010_10_20_v00013.zip
mydaily kasso Wed Oct 20 14:08:20 PDT 2010 domain1_2010_10_20_v00014.zip
mydaily kasso Wed Oct 20 10:22:20 PDT 2010 domain1_2010_10_20_v00005.zip
mydaily kasso Wed Oct 20 10:21:20 PDT 2010 domain1_2010_10_20_v00002.zip
Command list-backups executed successfully.

It should be sorted by date.



 Comments   
Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-15537] restart-instance takes a long time on Solaris 11 (sun.security.pkcs11.SunPKCS11) Created: 11/Jan/11  Updated: 18/Feb/13  Due: 18/Apr/11

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

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

Oracle Solaris 11 Express snv_151a X86
java version "1.6.0_23"
Private build based on r44408


Attachments: File rpc.c    
Tags: 3_1-exclude, 3_1-next_release-note-added, 3_1-next_release-notes, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

restart-instance often takes minutes to execute on Solaris 11. To reproduce:

  1. Start the DAS. On the DAS machine:
    asadmin create-local-instance i1
    asadmin start-local-instance i1
    asadmin stop-local-instance i1
    asadmin start-local-instance i1
  1. So far, so good. This all works great. I can stop/start
  2. many times and I don't see the problem. Then do:

asadmin restart-instance i1

Sometimes this returns promptly. But if I run restart repeatedly
often it takes a while to return (one time 9 minutes).
The instance does start eventually. If I do a jstack of
the instance process while it is "hung" I see consistently this
thread which appears to be blocked in a pkcs11 call (see stack
trace below).

I have not been able to reproduce this on Linux.

"FelixStartLevel" daemon prio=3 tid=0x089a5400 nid=0xe runnable [0xcd17e000]
java.lang.Thread.State: RUNNABLE
at sun.security.pkcs11.wrapper.PKCS11.C_Initialize(Native Method)
at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:160)

  • locked <0xcebc0c58> (a java.lang.Class for sun.security.pkcs11.wrapper.PKCS11)
    at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:281)
    at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
    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 sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:243)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:225)
    at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:205)
  • locked <0xf1e8f838> (a sun.misc.Launcher$AppClassLoader)
    at sun.security.jca.ProviderList.getProvider(ProviderList.java:215)
    at sun.security.jca.ProviderList.getService(ProviderList.java:313)
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:140)
    at java.security.Security.getImpl(Security.java:659)
    at java.security.MessageDigest.getInstance(MessageDigest.java:129)
    at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1759)
    at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:52)
    at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:205)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:202)
    at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:558)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at java.util.HashMap.readObject(HashMap.java:1030)
    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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at org.jvnet.hk2.osgiadapter.OSGiModulesRegistryImpl.loadCachedData(OSGiModulesRegistryImpl.java:195)
    at org.jvnet.hk2.osgiadapter.OSGiModulesRegistryImpl.<init>(OSGiModulesRegistryImpl.java:91)
    at org.jvnet.hk2.osgiadapter.OSGiFactoryImpl.createModulesRegistry(OSGiFactoryImpl.java:70)
    at org.jvnet.hk2.osgiadapter.OSGiFactoryImpl.createModulesRegistry(OSGiFactoryImpl.java:52)
    at org.jvnet.hk2.osgiadapter.HK2Main.createModulesRegistry(HK2Main.java:185)
    at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:142)
    at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1827)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1744)
    at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
    at org.glassfish.kernel.GlassFishActivator.startBundle(GlassFishActivator.java:239)
    at org.glassfish.kernel.GlassFishActivator.startBundles(GlassFishActivator.java:194)
    at org.glassfish.kernel.GlassFishActivator.start(GlassFishActivator.java:80)
    at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1827)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1744)
    at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
    at org.jvnet.hk2.osgimain.Main.start(Main.java:154)
    at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1827)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1744)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1148)
    at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
    at java.lang.Thread.run(Thread.java:619)

The instance log file has nothing of interest. The message before the "hang" is:

Jan 11, 2011 5:21:30 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 39 msec.

and the first message after the "hang" is:

Jan 11, 2011 5:25:02 PM null
INFO: Running GlassFish Version: GlassFish Server Open Source Edition 3.1-SNAPSHOT (build dipol-private)
[#|2011-01-11T17:25:02.483-0800|INFO|glassfish3.1|null|_ThreadID=12;_ThreadName=Thread-1;|Grizzly Framework 1.9.28 started in: 89ms - bound to [0.0.0.0:28080]|#]



 Comments   
Comment by Chris Kasso [ 12/Jan/11 ]

I'm able to reproduce this as well on S11. It occurred once in seven restarts (it took six minutes to restart):

ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m19.39s
user 0m16.59s
sys 0m0.83s
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m32.63s
user 0m19.04s
sys 0m0.83s
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 6m41.79s
user 0m21.63s
sys 0m1.22s
ouch: cd v3
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m32.51s
user 0m19.70s
sys 0m1.26s
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m31.14s
user 0m18.31s
sys 0m0.99s
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m22.61s
user 0m20.44s
sys 0m0.85s
ouch: time ./asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.

real 0m56.26s
user 0m19.77s
sys 0m0.81s

Comment by Byron Nevins [ 12/Jan/11 ]

Solaris 11 machine I don't have.

Also – the hung thread is in Felix. Hint.

Joe/Chris - Please try again using no OSGi and then Equinox.

Comment by Joe Di Pol [ 12/Jan/11 ]

I set

GlassFish_Platform=Static

and could still reproduce the problem. The thread trace is now different. It looks like the first call that causes the PKCS11 security provider to be initialized triggers the problem. The weird thing is that this only seems to happen on re-start. I haven't seen this when starting an instance.

The stack trace for when Felix is out of the loop:

"main" prio=3 tid=0x08072c00 nid=0x2 runnable [0xfe2fd000]
java.lang.Thread.State: RUNNABLE
at sun.security.pkcs11.wrapper.PKCS11.C_Initialize(Native Method)
at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:160)

  • locked <0xcef09e80> (a java.lang.Class for sun.security.pkcs11.wrapper.PKCS11)
    at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:281)
    at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
    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 sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:243)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:225)
    at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:205)
  • locked <0xda6007f8> (a sun.misc.Launcher$AppClassLoader)
    at sun.security.jca.ProviderList.getProvider(ProviderList.java:215)
    at sun.security.jca.ProviderList$3.get(ProviderList.java:130)
    at sun.security.jca.ProviderList$3.get(ProviderList.java:125)
    at java.util.AbstractList$Itr.next(AbstractList.java:345)
    at java.security.SecureRandom.getPrngAlgorithm(SecureRandom.java:522)
    at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:165)
    at java.security.SecureRandom.<init>(SecureRandom.java:133)
    at

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
com.sun.enterprise.v3.admin.LocalPasswordImpl.postConstruct(LocalPasswordImpl.java:87)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:128)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:88)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)

  • locked <0xf6fe29b8> (a com.sun.hk2.component.SingletonInhabitant)
    at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
    at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
    at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:219)
    at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
  • locked <0xfa648f10> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
  • locked <0xfa648ef0> (a com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime$1)
    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)
Comment by Byron Nevins [ 12/Jan/11 ]

From the internet:

No it hasn't anything to do with the classpath I've used...

I've investigated the problem a little bit further by profiling my
simple jdbc test class and found out that most of the time is spent in
this class:

sun.security.pkcs11.wrapper.PKCS11.C_Initialize

98% of the time is spent in that function with 3694 calls (well it
will last forever if I don't kill the process)!

So I guess it's a problem with Sun/Solaris security mixed with nfs issue...

Christian

On Feb 16, 2008 4:09 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
> On 16-Feb-08, at 2:45 PM, Christian Bourque wrote:
>
> > Hi Tom,
> >
> > I think you were right, there is something in the home directory that
> > is conflicting!
> >
> > I don't understand why jdbc would use something in the user's home
> > directory though...
> >
> > Anyway the workaround I found was to not map the share directly under
> > the user's home account and now it works!
> >
> My guess is your classpath ?
>
> Dave
> > Thanks for your help!
> >
> > Christian
> >
> > On Feb 16, 2008 1:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> "Christian Bourque" <christian(dot)bourque(at)gmail(dot)com> writes:
> >>> The pg server is running on server B (openSUSE) and I'm connecting
> >>> to
> >>> it from server C (Solaris 10) using a user account with an nfs
> >>> mounted
> >>> directory from server A (openSUSE).
> >>
> >>> If I unmount the nfs share it works! But with the share it doesn't,
> >>> the connection seems to reach the server but it gets stuck there, no
> >>> error and it doesn't timeout either...
> >>
> >> It's way too hard to believe that NFS per se is interfering.
> >>
> >> What I could believe is that there is some configuration-type file in
> >> your home directory that is causing a problem, and after the unmount
> >> it's not visible so no problem. There are obvious possibilities for
> >> this such as ~/.psqlrc if you're using psql/libpq, but I dunno enough
> >> about the JDBC environment to guess whether it has equivalents.
> >>
> >> If all else fails, you could try strace'ing the application (or
> >> whatever
> >> Solaris' equivalent to strace is) in both cases and comparing
> >> results.
> >> That would at least make it clearer where it's hanging up ...
> >>
> >> regards, tom lane
> >>
> >

Comment by Byron Nevins [ 12/Jan/11 ]

My Analysis:

Facts:

  • PKCS native code has an issue in Solaris 11
  • The problem never happens Solaris < 11 or any other OS
  • The problem never happens with start-domain – only with restart
  • It is intermittent
  • It has nothing to do with LocalPasswordImpl – it hangs with the first of many calls from GF
    to PKCS code. LocalPasswordImpl happens to be the first when running w/o OSGi

Conclusions:

  • It's a race condition inside the native code. The restarting server is coming up too fast for the native code to completely finish. Sometimes.

Fix:
restart-server should wait a bit longer before starting – at least in this one platform.

Comment by Byron Nevins [ 13/Jan/11 ]

======== Here is how restart works in this bug's case

1) Inside the server a new JVM process is spawned to run start-domain
2) The server continues dying
3) Meantime the new JVM is running start-domain from AsadminMain
4) The new JVM waits for its parent process to die
5) start-domain then proceeds as normal

step (4) is difficult. Impossible without using native calls. Here is how it does it now:

(1) It waits for a read call on System.in to return -1.
(2) It positively checks all the ports the server was using

When all the ports are free – we define the server as dead.
==================================================================

THe next step would be to absolutely positively verify that the process itself is gone. Luckily we have ProcessUtils available!

Comment by Byron Nevins [ 13/Jan/11 ]

PROBLEM:

In Solaris 11 restart-domain intermittently hangs. This is caused by Security SPI native code from sun that is included in the JDK.

It has only been observed on Solaris 11 systems at a ~~ 10-15% frequency

How bad is its impact? (Severity)
When it hits – the server hangs and now you can never restart it again. I assume it requires a forcedful kill.

How often does it happen?
10-15% on Sol 11

Will many users see this problem? (Frequency)
The propertion of users using any kind of Solaris is small, I assume. The proportion of them that are using Sol 11 will be small but growing over time.

How much effort is required to fix it? (Cost)
2-3 days. A lot of time-consuming testing, getting remote machines configured, etc. It's intermittent so tests have to be run over and over and over...

What is the risk of fixing it and how will the risk be mitigated? (Risk)
The risk is that restart-server stops working on other platforms
Mitigated by being very careful & conservative. I will probably end up with special
code that only runs on Sol 11 machines.

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

Here is some output from pstack on a "hung" instance. I also ran pfiles, but that didn't show much. I'm not sure what is going on, but some observations:

  • The trace has sendTCSDPacket() on it
  • tcsd(8) is a daemon that acts as the portal to the TPM (Trusted Platform Module) device driver.
  • I think the TPM device driver is how hardware crypto devices are accessed.
  • tcsd(8) is not running on my system because there is no /dev/tpm (maybe because I have no crypto chip on my system?).

Since start-instance works OK the problem is not just that tcsd(8) is not running, but it would be interesting to know if the problem happens on an S11 system where tcsd(8) is running.

----------------- lwp# 2 / thread# 2 --------------------
fee91b55 connect (100, fe2ed1c0, 10, 1)
fed9ca03 connect (100, fe2ed1c0, 10, ccfaf417) + 23
ccfaf480 send_init (9c81718, 0, 9b5e1a0, ccfaf16a) + b8
ccfaf22d sendTCSDPacket (9c81718, 0, cd170a40, ccfaafb2) + d1
ccfaafe0 RPC_OpenContext_TP (9c81718, fe2ed278, fe2ed27c, fe2ed274) + 3c
ccfab12d RPC_OpenContext (c0000004, 81bf330, 1, ccfaa93e) + 4d
ccfaa9d1 Tspi_Context_Connect (c0000004, 0, fe2ed31c, cd01de0a) + a1
cd01de34 open_tss_context (fe2ed35c, fee920f5, cd033978, cd01deae) + 38
cd01dec0 token_specific_init (0, 0, fe2ed35c, cd014267) + 20
cd0144b9 ST_Initialize (cd036748) + 33d
cd0093dc C_Initialize (927a610, cd1d8968, fe2ed3e8, cd1d6615) + 158
cd1d6830 pkcs11_slot_mapping (9c32008, 927a610, fe2ed498, cd1d1587) + 22c
cd1d15b3 C_Initialize (927a610) + fb
cd21629a Java_sun_security_pkcs11_wrapper_PKCS11_C_1Initialize (8072d18, fe2ed518, fe2ed514, 100, f7214d18, fe2ed4e4) + 4e
faa0a152 ???????? (0, faa080f9, f71d0ab0, f7214d18, 1, cef09e88)
faa0308d ???????? (0, f7214d18, 0, f71d0ab0, ceef2570, f714c578)
faa02f27 ???????? (0, 0, 0, 0, 0, 0)
faa0308d ???????? (da9e03d8, f70f4640, 8073438, 1fa0, febc8000, 2)
faa00348 ???????? (fe2ed650, fe2ed95c, a, ceee1e98, faa090e0, fe2ed8d0)
fe50fe95 _1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv (fe2ed958, fe2ed728, fe2ed8cc, 8072c00) + 1c9
fe510137 _1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv2468_v (fe50fccc, fe2ed958, fe2ed728, fe2ed8cc, 8072c00) + 27
fe51016f _1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThreadv (fe2ed958, 8073438, fe2ed8cc, 8072c00) + 2f
fe9b776a _1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_bnOobjArrayHandle_nJBasicType_4bpnGThreadpnHoopDesc_ (8073434, 8073438, 8073440, 0, 8073430, e) + c3e
fe562060 _1cKReflectionSinvoke_constructor6FpnHoopDesc_nOobjArrayHandle_pnGThread2 (f70e29f8, 807342c, 8072c00) + 200
fe561c50 JVM_NewInstanceFromConstructor (8072d18, fe2edbac, fe2edba8) + 118
fe21ccbf Java_sun_reflect_NativeConstructorAccessorImpl_newInstance0 (8072d18, fe2edba0, fe2edbac, fe2edba8, f70e2a60, f70e2a48) + 23
faa0a152 ???????? (ce6d1280, faa08116, f70e2a38, f70e29f8, fe2edbb0, ce6d0f88)
faa02f27 ???????? (0, f70e2a38, f70e2a48, fe2edbe4, ce6d167d, fe2edc10)
faa02f27 ???????? (f70e2a38, f70e2a60, fe2edc14, ce646024, fe2edc44, ce6cfaf0)
faa03403 ???????? (0, f70e2a38, f70e29f8, fe2edc48, ce90c3b7, fe2edc80)
faa02f27 ???????? (f70e29f8, 0, ceee5210, da6007f8, f70338b8, 8072c00)
faa00348 ???????? (fe2edcd0, fe2eded0, a, ce90c490, faa090e0, fe2ededc)
fe50fe95 _1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv (fe2edecc, fe2edda8, fe2eded8, 8072c00) + 1c9
fe510137 _1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThreadv2468_v (fe50fccc, fe2edecc, fe2edda8, fe2eded8, 8072c00) + 27
fe51016f _1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThreadv (fe2edecc, 8073428, fe2eded8, 8072c00) + 2f
fe54eaca JVM_DoPrivileged (8072d18, fe2ee0b8, fe2ee0c0, 0, 0) + 34a
fe219f98 Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2 (8072d18, fe2ee0b8, fe2ee0c0, f70338b8, fe2ee090, 0) + 28
faa0a152 ???????? (ce685ce8, faa08116, f70338b8, fe2ee0c4, ce8cde48, fe2ee0f0)
faa02f27 ???????? (0, da9e03a0, 6fb666b1, da6007f8, fe2ee0f4, ce8cdd75)
faa02f27 ???????? (0, 0, 0, da6007f8, 0, da9e03a0)
faa02f27 ???????? (0, 0, da9d1170, fe2ee170, ce8d382d, fe2ee19c)
faa02f27 ???????? (0, da9e0478, fe2ee1a0, ce8d38ba, fe2ee1cc, ce8d3c08)
faa02f27 ???????? (0, da9e0478, f70338a0, 807344c, ce8c9000, fe2ee1fc)
faa9bcb8 ???????? (fec0fd68, 10, 28, ce689750, ce68e148, ce6064d8)
ce600150 ???????? ()

Comment by Byron Nevins [ 14/Jan/11 ]

Nothing has yet worked.

Comment by Byron Nevins [ 14/Jan/11 ]

This fixes the problem

-Dsun.security.pkcs11.enable-solaris=false

maybe not. Look into it further...

Comment by Byron Nevins [ 18/Jan/11 ]

The bug is caused by native code, Security SPI, provided by the JDK. It is too risky to resolve for 3.1

Game Plan:
We need to resolve this within 12 weeks of Solaris 11 introduction.
For initial 3.1 release we document it.

Comment by Joe Di Pol [ 18/Jan/11 ]

More data:

I ran "truss -f -t connect -v connect -p 13064", where 13064 was the pid of the instance I was going to restart. Here is the interesting part:

When things work fine I see:

13076/2: connect(50, 0xFE12D2A0, 16, SOV_DEFAULT) Err#146 ECONNREFUSED
13076/2: AF_INET name = 127.0.0.1 port = 30003
13076/2: connect(50, 0xFE12D220, 16, SOV_DEFAULT) Err#146 ECONNREFUSED
13076/2: AF_INET name = 127.0.0.1 port = 30003
13076/2: connect(50, 0xFE12D2C0, 16, SOV_DEFAULT) Err#146 ECONNREFUSED
13076/2: AF_INET name = 127.0.0.1 port = 30003

When I get the hang I see:

13078/14: connect(280, 0xCD1906A0, 16, SOV_DEFAULT) (sleeping...)
13078/14: AF_INET name = 127.0.0.1 port = 30003
13076/2: Received signal #13, SIGPIPE [caught]
. . .
13076/2: Received signal #13, SIGPIPE [caught]
13078/14: connect(280, 0xCD1906A0, 16, SOV_DEFAULT) Err#145 ETIMEDOUT
13078/14: AF_INET name = 127.0.0.1 port = 30003
13076/2: Received signal #13, SIGPIPE [caught]
13078/14: connect(280, 0xCD190620, 16, SOV_DEFAULT) (sleeping...)
13078/14: AF_INET name = 127.0.0.1 port = 30003
13076/2: Received signal #13, SIGPIPE [caught]
13076/2: Received signal #13, SIGPIPE [caught]
13078/14: connect(280, 0xCD190620, 16, SOV_DEFAULT) Err#145 ETIMEDOUT
13078/14: AF_INET name = 127.0.0.1 port = 30003
13078/14: connect(280, 0xCD1906C0, 16, SOV_DEFAULT) Err#146 ECONNREFUSED
13078/14: AF_INET name = 127.0.0.1 port = 30003

Observations:

  • The connect is trying to connect to port 30003. That's the default tcsd(8) port.
  • When connect is hanging it fails with ETIMEDOUT instead of failing immediately with ECONNREFUSED.
  • It looks like the connect in question is called 3 times.
  • During a "hang" netstat -a shows:
    localhost.59145 localhost.30003 0 0 131072 0 SYN_SENT
  • Netstat shows nothing listening on port 30003
Comment by Joe Di Pol [ 18/Jan/11 ]

sendTCSDPacket() and send_init() are in the Trouser 0.3.4 client code (0.3.4 looks to be the version on my Solaris 11 box). The Trouser 0.3.4 source can be found at: http://sourceforge.net/projects/trousers/files/trousers/0.3.4/. I've attached rpc.c that contains sendTCSDPacket() and send_init(). Nothing seems obviously wrong. Note in particular that send_init() does close the socket on an error.

Comment by Byron Nevins [ 24/Jan/11 ]

In 3.1 this will be documented.
It should be fixed for 3.2

Comment by Paul Davies [ 16/May/11 ]

The Release Notes should just mention the problem of intermittent slow start on Solaris 11. There is no workaround (except, perhaps, to wait).

Comment by Scott Fordin [ 16/May/11 ]

Added issue to 3.1.1 Release Notes.





[GLASSFISH-3598] Replace calls to System.setProperty with GFSystem.setProperty Created: 11/Sep/07  Updated: 05/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 3,598
Tags: 3_1-exclude

 Description   

Replace every call to System.setPropert[y|ies]() with GFSystem.setPropert[y|ies]()

See http://blogs.sun.com/foo/entry/monitored_system_setproperty
for details on why.

I set the subcomponent to "Admin". It should be set to ALL subcomponents, but
Issue tracker won't allow that.



 Comments   
Comment by km [ 22/Sep/07 ]

BN.

Comment by km [ 22/Sep/07 ]

BN.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in 9.1peur1.

Comment by Byron Nevins [ 07/Feb/11 ]

Not difficult but messy – need to change dozens or hundreds of files...

The hard part is GFSystem implementation which is all done long ago.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-3589] jmx mbean deployment needs to be streamlined Created: 07/Sep/07  Updated: 05/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 3,589
Tags: 3_1-exclude

 Description   

The current process of deploying mbeans is cumbersome. At present you have to
put the jar under the lib folder in the glassfish install directory and then
call asadmin create-mbean for each mbean in the jar that you want to deploy.
This is a tedious process if there are a large number of mbeans and you have to
deploy them to a number of servers that are not clustered.

The deployment process should be simplified possibly by using a xml based
configuration file in which you define the mbean class and values for the
attributes.
The xml file should probably be independent of the jar file as this would
provide the flexibility of modifying the configuration at any point and have the
appserver load the new configuration.

The communication with kedar is in this thread.
http://forums.java.net/jive/thread.jspa?messageID=234484&#234484



 Comments   
Comment by Hong Zhang [ 10/Sep/07 ]

-> admin

Comment by km [ 10/Sep/07 ]

A brand new RFE that will almost certainly require "new" code!

Thanks for filing it. Assigning it to Byron.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in 9.1peur1.

Comment by Byron Nevins [ 07/Feb/11 ]

I don't know if this is still applicable. Leaving it alive until I get time to investigate

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-4365] Provide configuration support for other config files, most notably default-web.xml Created: 02/Mar/08  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: v2.1
Fix Version/s: future release

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

Operating System: All
Platform: All


Issuezilla Id: 4,365
Status Whiteboard:

v3-prd-item


 Description   

See: http://wiki.glassfish.java.net/Wiki.jsp?page=V3CoreInfrastructureImprovements

CoreInfra-006.



 Comments   
Comment by km [ 02/Mar/08 ]

...

Comment by kumara [ 01/Sep/09 ]

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

Comment by Tom Mueller [ 17/May/10 ]

Lowering priority as this is not expected for 3.1.





[GLASSFISH-4362] Ease deployment on a multi-homed system Created: 02/Mar/08  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: v2.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: km Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
depends on GLASSFISH-12666 Support for multi-address servers Resolved
Issuezilla Id: 4,362
Status Whiteboard:

v3-prd-item


 Description   

See: http://wiki.glassfish.java.net/Wiki.jsp?page=V3CoreInfrastructureImprovements

CoreInfra-005



 Comments   
Comment by km [ 02/Mar/08 ]

...

Comment by km [ 02/Mar/08 ]

...

Comment by ijuma [ 17/Oct/08 ]

Adding myself to cc list.

Comment by kumara [ 01/Sep/09 ]

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

Comment by Tom Mueller [ 17/May/10 ]

Lowering priority as this is not expected for 3.1.





[GLASSFISH-4810] Passing Java options to v3 thru startserv Created: 17/Apr/08  Updated: 05/Apr/11

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

Type: New Feature Priority: Major
Reporter: vivekp Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6720


Issuezilla Id: 4,810

 Description   

I was looking at easy way to pass system properties or java options while using
v3 startup script 'startserv'.

Can we not have JAVA_OPTS env variable to pass such values:

11c11
< exec java $JAVA_OPTS -jar "$AS_INSTALL_LIB/admin-cli-10.0-SNAPSHOT.jar"
start-domain --verbose "$@"

> exec java -jar "$AS_INSTALL_LIB/admin-cli-10.0-SNAPSHOT.jar" start-domain
--verbose "$@"

I tried and it does not seem to work. Although if I start using
glassfish-10.0-SNAPSHOT.jar instaed of admin-cli-10.0-SNAPSHOT.jar then the
system properties passed to java works! I could have made it work using java
-jar from command line but it is hard to automate or document as the jar file
name will keep changing across different v3 milestones and providing options to
the startup script to pass such otions to java is available in most of the web
servers such as tomcat (catalina.sh).



 Comments   
Comment by Byron Nevins [ 17/Apr/08 ]

.

Comment by km [ 17/Apr/08 ]

Can we talk about this before you implement?

Thanks.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-4659] provide domain specific asadmin script Created: 08/Apr/08  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: v2.1
Fix Version/s: future release

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

Operating System: All
Platform: All


Issuezilla Id: 4,659

 Description   

It would be very convenient if during the process of creating a domain also
domain specific scripts like an asadmin wrapper would be generated. This would
be helpfull in shared installations where you have eg. up to 50 domains being
served from the same glassfish installation. Currently you always have to use
$GLASSFISH_HOME/bin/asadmin --domaindir <x> <domainname-y>

It would be nice if the domain creation could generate a local asadmin wrapper
script could be recreated just like startserv/stopserv. Also being able to
specify domaindir/domainname as ENV variables would be a nice addon.

This applies to a developer profile install as well as for cluster/ee (DAS only).



 Comments   
Comment by schaarsc [ 21/Oct/08 ]

add \me to cc

Comment by kumara [ 01/Sep/09 ]

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





[GLASSFISH-4312] provide role-based access control (RBAC) for admin Created: 28/Feb/08  Updated: 22/May/13

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4311 provide role based access control Open
Issuezilla Id: 4,312
Status Whiteboard:

v3-prd-item


 Description   

This is coreInfro-004 in
http://wiki.glassfish.java.net/Wiki.jsp?page=V3CoreInfrastructureImprovements

and issue#4311 created for adminConsole-025 in
http://wiki.glassfish.java.net/Wiki.jsp?page=V3AdminConsoleImprovements
is depending on this.



 Comments   
Comment by Anissa Lam [ 28/Feb/08 ]

add keyword

Comment by km [ 08/May/09 ]

kumara is the rightful owner to begin with.

Comment by Tom Mueller [ 14/May/10 ]

Lowering priority as this is not essential for 3.1. Moving to the admin_gui
subcomponent.

Comment by Anissa Lam [ 14/May/10 ]

For new features like this, it is beyond GUI to support and get it working.
The protocol we normally follow is, the enhancement belongs to backend. When backend has
implemented such a feature, and needs GUI support to expose it , then assign to admin-gui.
Besides, issue# 4311 is created for GUI already, and it depends on this enhancement to be implemented
first.
I am assigning this back to 'admin'. When it is ready for GUI to work on this, then I will start working on
#4311.

thanks

Comment by Tom Mueller [ 18/Jul/11 ]

The new URL for coreInfra-004 is:
http://wikis.sun.com/display/glassfish/V3CoreInfrastructureImprovements





[GLASSFISH-4191] gfv3:Plugin/Module Manager:CoreInfra-018: Ability to to add a container at the cluster level Created: 15/Feb/08  Updated: 22/May/13

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

Type: New Feature Priority: Major
Reporter: msreddy Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 4,191
Status Whiteboard:

v3-prd-item


 Description   

Provide for adding container at the cluster level.



 Comments   
Comment by msreddy [ 26/Feb/08 ]

v3-prd-item

Comment by ijuma [ 17/Oct/08 ]

Adding myself to cc list.

Comment by msreddy [ 04/May/09 ]

lowered to P3 as it is needed for a later release

Comment by Tom Mueller [ 11/May/10 ]

This should be part of the synchronization and dynamic reconfiguration
sub-projects for 3.1.

Comment by Tom Mueller [ 14/May/10 ]

Assigning to Tom for now.

Comment by Tom Mueller [ 17/May/10 ]

Marking as referenced by the clustering admin one-pager.

Comment by Tom Mueller [ 02/Jul/10 ]

Nice to have for 3.1.

Comment by Tom Mueller [ 28/Jul/10 ]

See http://wikis.sun.com/display/GlassFish/V3CoreInfrastructureImprovements

Comment by Tom Mueller [ 03/Aug/10 ]

Deferring to a future release.





[GLASSFISH-4176] Support OEM pluggability Created: 15/Feb/08  Updated: 22/May/13

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

Type: New Feature Priority: Major
Reporter: msreddy Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 4,176
Status Whiteboard:

v3-prd-item


 Description   

This is the umbrella feature for providing OEM Pluggability in V3. Separate
issues will be cretaed for the following dependencies.

Configuration? Lloyd
Application Server Management Extension API? Lloyd
Runtime Management Sreeni
Command Line Interface SPI (Service ProviderInterface) Jennifer
Deployment Hong
GUI Pluggability? Ken/Anissa
GUI Look and Feel? Anissa/Ken
Skins? Sreeni/Jerome/Anissa
Container Support Sreeni/Jerome
Monitoring API? Prashanth
Embeddable Application Server? Byron
Launch CLI in embedded environment? Jennifer



 Comments   
Comment by msreddy [ 26/Feb/08 ]

v3-prd-item

Comment by msreddy [ 26/Feb/08 ]

v3-prd-item

Comment by msreddy [ 04/May/09 ]

lowered to P3 as it is needed for a later release

Comment by Tom Mueller [ 14/May/10 ]

Reassign to Tom.

Comment by Tom Mueller [ 20/Jan/11 ]

The modular architecture of GlassFish 3 already supports many of the requirements for OEM pluggability. However, an analysis is required to see if it really meets everything that is needed. Targeting this issue for a future release.

The issues that were created for the various aspects of OEM pluggability listed in the description are being marked as "won't fix" until an analysis is completed to determine what still need to be designed and implemented.





[GLASSFISH-3927] MBean ClassLoader Enhancements Created: 17/Dec/07  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: v2.1
Fix Version/s: future release

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

Operating System: All
Platform: Sun


Issuezilla Id: 3,927
Tags: 3_1-exclude

 Description   

Currently jars containing the custom mbeans need to be dropped in the
AS_HOME/lib directory. Normally we expect the users to drop the libraries to
domains/domain1/lib directory.

It will be good, if MBeanClassLoader is enhanced to look at domains/domain1/lib
directory also.

Additionally, it will also be good, if the custom mbeans can be in the
application classloader.



 Comments   
Comment by kumara [ 01/Sep/09 ]

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

Comment by Tom Mueller [ 27/Jul/10 ]

This appears to be a monitoring issue.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version since this issue isn't going to be fixed in 9.1.1.

Comment by Byron Nevins [ 07/Feb/11 ]

Custom Mbeans is Admin – not monitoring.

I don't know if we still support them. Keeping this issue alive uintil I have time to investigate.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-17426] enhance the per instance/cluster library support Created: 14/Oct/11  Updated: 22/May/13

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

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

Issue Links:
Related
is related to GLASSFISH-17409 Per instance/cluster libraries are no... Resolved
Tags: 3_1_x-exclude

 Description   

Today we have limited support for per instance/cluster library. There are some of the things we could possibly enhance in the next version:

1. Libraries to be picked up at runtime automatically instead of having to specify libraries option.

2. Support config/named-config/lib/ext.

3. Overcome the limitation that the same deployed application cannot be used with multiple different named-configs.



 Comments   
Comment by Tom Mueller [ 18/Oct/11 ]

Hong, can you explain what about #2 that we currently do not support? AFAIK, one just needs to install the config-specific library into config/named-config/lib/ext and then refer to it when deploying the application with

--libraries ../../config/named-config/lib/ext/whatever.jar

Comment by Hong Zhang [ 18/Oct/11 ]

Sahoo mentioned there is some additional work associated with extension libraries (validates the extension-list of the application against correct extensions?). I am not familiar with how our extension classloader is working today, we probably need to ask Sahoo to clarify with more details here.





[GLASSFISH-16586] sync-instance leaves garbage in the file system Created: 09/May/11  Updated: 05/Nov/12

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

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

Attachments: Text File GLASSFISH-16586.patch    
Tags: 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Easy to reproduce.

asadmin _synchronize-instance garbage

(i.e. any instance name that does not exist)

======================
d:\gf\v2\appserv-tests\devtests\admin\cli\src\admin>asadmin _synchronize-instance garbage
CLI802 Synchronization failed for directory config, caused by:
remote failure: Unknown server instance: garbage

d:\gf\v2\appserv-tests\devtests\admin\cli\src\admin>dir /s/b D:\glassfish3\glassfish\nodes\localhost-domain1\garbage
D:\glassfish3\glassfish\nodes\localhost-domain1\garbage\.syncstate

===============================
We definitely don't want junk directories in a node directory. Many commands will be examining that directory wasting time again and again (or worse - I'm not sure).

A simple typo is how I noticed this...



 Comments   
Comment by Chris Kasso [ 23/May/11 ]

The failed synchronization command results in the creation of a new directory under the localhost-domainname node directory. This directory contains a zero length .syncstate file.

The failed command should not create the directory or leave any new files on the system.

To reflect the minimum impact of the issue the priority is being changed from P2 -> P3.

Comment by Byron Nevins [ 23/May/11 ]

Try this:

(fresh install, no instances)
I.
asadmin create-local-instance i1
asadmin delete-local-instance i1
dir D:\glassfish3\glassfish\nodes (empty)

05/23/2011 11:12 AM <DIR> .
05/23/2011 11:12 AM <DIR> ..

=====================================================
II.
asadmin create-local-instance i1
asadmin asadmin _synchronize-instance garbage
asadmin delete-local-instance i1
dir D:\glassfish3\glassfish\nodes

Directory of D:\glassfish3\glassfish\nodes

05/23/2011 11:11 AM <DIR> .
05/23/2011 11:11 AM <DIR> ..
05/23/2011 11:12 AM <DIR> localhost-domain1

Comment by Chris Kasso [ 24/May/11 ]

Got it. It also leaves the node and agent directories.

Comment by zhouronghui [ 05/Nov/12 ]

Dear Chris Kasso:

I have looked into this issue and found the reason of it.
I refered to the DeleteLocalInstanceCommand.java and
made a patch for this ISSUE.
The patch called "GLASSFISH-16586.patch" has been attached.
Would you please check it?

Thank you.





[GLASSFISH-15942] Improve messages when instance startup fails Created: 10/Feb/11  Updated: 22/May/13

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

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

ogs-3.1-web-b41.zip


Attachments: JPEG File instance-startup-warning.JPG     Text File server.log    
Tags: 3_1-exclude

 Description   

Steps to reproduce (performed in Admin Console):

1. Go to default config, and create a new http listener, e.g. http-goofy, on port 8585 (or other port that's not in use) using an existing http-listener-1 protocol.
2. Create a new virtual server, e.g. goofy, using http-goofy listener.
3. Create a standalone instance, in1 on remote host and start it.
4. Create a cluster with two instances: one local, c1in1, and one remote, c1in2.
5. Start cluster - the following warning is displayed:

Command succeeded with Warning
c1in2: Could not start instance c1in2 on node bif (biffy.us.oracle.com). Command failed on node bif (biffy.us.oracle.com): Waiting for c1in2 to start ..........................Command start-local-instance failed. Error starting instance c1in2. The server exited prematurely with exit code 0. Before it died, it produced the following output: Launching GlassFish on Felix platform [#|2011-02-10T10:56:32.709-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=36;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.31 started in: 315ms - bound to [0.0.0.0:27677]|#] [#|2011-02-10T10:56:32.722-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=34;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.31 started in: 464ms - bound to [0.0.0.0:28182]|#] [#|2011-02-10T10:56:32.722-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_T .... msg.seeServerLog

The above message does not reveal much. The instance's server.log contains two severe messages:

[#|2011-02-10T10:56:34.651-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.syst
em.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB031
5: The host name biffy is shared by virtual servers server and goofy, which are
both associated with the same HTTP listener (http-goofy)|#]

...

[#|2011-02-10T10:56:39.355-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.syst
em.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Shutting
down v3 due to startup exception : No free port within range: 8585=com.sun.enter
prise.v3.services.impl.monitor.MonitorableSelectorHandler@cc258a|#]

The second message, "No free port", should be the one displayed in Admin Console. Also, please note the following above: "Shutting down v3". We should replace v3 with Glassfish or some other name that does not contain version.

Attaching server.log from the remote, clustered instance, c1in2.



 Comments   
Comment by lidiam [ 10/Feb/11 ]

It is not necessary to create the virtual server as mentioned above in step 2. Also, new listener can be created with default values, as long as there is one, fixed port number.

Comment by Tom Mueller [ 28/Feb/11 ]

Changing this to be an RFE.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-15900] Improve error message if listen port is in use Created: 08/Feb/11  Updated: 22/May/13

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

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

Tags: ee7ri_cleanup_deferred

 Description   

When the listen port is already in use Glassfish outputs this error message:

SEVERE: Shutting down v3 due to startup exception : No free port within range: 8080=com.sun.enterprise.v3.services.impl.
monitor.MonitorableSelectorHandler@1ec58a

Please replace this with something along the lines of: "SEVERE: Shutting down v3 due to startup exception : The listen port (8080) is in use"



 Comments   
Comment by Bhavanishankar [ 08/Feb/11 ]

This is not an embedded issue.

When 8080 port is not free, even if you do 'asadmin start-domain', you will see the same error in server.log

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-15870] start-database should have a "verbose" option Created: 06/Feb/11  Updated: 05/Apr/11

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

Type: New Feature Priority: Major
Reporter: Byron Nevins Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1) Essential ==> The "--verbose" option should be added to "start-database". The idea is that the asadmin process sits there, blocked, until killed or until the DB is stopped externally.
Why? This makes it smooth and easy to add a Platform Service that will automatically restart the database when necessary (if setup that way). It is precisely analogous with start-domain and the verbose option.

2) As a bonus – have the console window display all DB log messages. That would be very useful.

================
How did I come up with this? On my home website I re-used winsw.exe (in our installation) to run derby as a service via 'asadmin start-domain'. Winsw sees that asadmin exits immediately so Windows reports it as "stopped" even though it is really running.

There are probably other ways of doing this – perhaps JavaDB has its own tools for running as a service?



 Comments   
Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-15856] Report server instance and application startup warnings to user Created: 04/Feb/11  Updated: 22/May/13

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

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

Attachments: XML File instance-restarted-domain.xml     Text File instance-server.log     File scrumtoys.war     Text File server.log    
Tags: 3_1-exclude

 Description   

Steps to reproduce (performed these on a fresh install):

1. Create a standalone instance and start it.
2. Stop the instance.
3. Deploy an application (e.g. the attached scrumtoys application). A warning is displayed that deployment was not replicated to the instance, which is expected.
4. Start instance.
5. Go to the deployed application page and click Launch button - issue: 404 error is displayed. There are no errors in the server.log (see attached). I'm also attaching domain.xml at this point (named instance-restarted-domain.xml). When you view the targets, in Admin GUI, for this application the instance is listed as enabled.

I tried the same scenario with clusterjsp.ear application and it worked fine, so not sure why scrumtoys does not work. Please note, that this is the first time deployment, so no errors are expected for this application during deployment - it should work just fine. Also, scrumtoys is one of the sample applications shipped with SDK.



 Comments   
Comment by Anissa Lam [ 04/Feb/11 ]

I am not familiar with this application, and as you stated, other application 'clusterjsp' works fine.
The bug doesn't seem to be in GUI when the application doesn't run.
Transfer to Hong for her evaluation.

Comment by Hong Zhang [ 04/Feb/11 ]

lidia: I was able to reproduce the problem with the steps you described. When I looked at the server.log, I noticed the application failed to load during the instance restart (your server.log has the same exception):

[#|2011-02-04T11:36:31.970-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|ThreadID=1;_ThreadName=Thread-1;|javax.naming.NamingException: Lookup failed for 'jdbc/_default' in SerialContext[myEnv=

{com.sun.enterprise.connectors.jndisuffix=__pm, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: jdbc]
java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'jdbc/__default' in SerialContext[myEnv={com.sun.enterprise.connectors.jndisuffix=__pm, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: jdbc]
at org.glassfish.persistence.jpa.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:111)
...

So seems the resource jdbc/__default need to be available on the instance for the application to successfully load during server restart. I have tried to create the necessary resource before deployment, and things worked as expected afterwards (the application loaded successfully as part of the instance restart, and I can launch application successfully afterwards without any problem).

Comment by lidiam [ 04/Feb/11 ]

Thank you Hong, I missed this part! However, this failure should be reported to the user in Admin Console. It is discovered during instance startup and a warning message should be displayed to the user if there is any problem with application deployment/replication.

I think this should be addressed for v3.2.

Comment by Anissa Lam [ 04/Feb/11 ]

"It is discovered during instance startup and a warning message should be displayed to the user if there is any problem with application deployment/replication. "

Transfer to 'admin' since you are requesting instance startup to detect if there is any problem and provide warning to user.
If the warning is in action report, GUI should be able to show that to user already.

Comment by Tom Mueller [ 07/Feb/11 ]

Changing the summary to reflect the intent of this issue.

The root cause of this issue is that there were four SEVERE log messages output to the log file during instance startup, but the start-instance command did not report this information to the user, and therefore the information wasn't available in the console either.

Marking this as an improvement because there isn't anything in the system that is supposed to be doing this at this point, i.e., this would be a new feature.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-15815] Include a version in the domain.xml Created: 03/Feb/11  Updated: 22/May/13

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

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

Generic


Tags: 3_1-exclude

 Description   

During upgrades and updates from prior releases it has been necessary
for the server to (1) determine the version of GF the domain.xml file is
supporting (e.g. v2.1, 3.0.1, etc) and (2) make adjustments to the contents
of the file in preparation to support the current version of GF.

We have employed various methods to determine the current version of
the domain.xml file such as looking for the absence of certain
required elements.

By adding a new "version" element or attribute which represents the
version of the file this could assist future versions of GF during
update and upgrade procedures. It would provide a reliable way to detect
the version of the file.



 Comments   
Comment by Tom Mueller [ 03/Feb/11 ]

Note that the <domain> element in the domain.xml today has a "version" attribute. It is set to "10.0" in the domain.xml template, and any domains created with the asadmin create-domain command will have that value for the version.

However, private and release engineering builds of the software insert different values, such as "re-continuous", into this attribute for the "domain1" that is created at build time. It is not clear what this version value is supposed to represent. It appears to be the version of the software that was initially there when the domain was created, since the value is never updated once it is written to the domain, even if the software is updated using the package system.

A version identification for the purposes of upgrade will need to use a different version field.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-16280] Killing DAS started with -v kills locally started instances Created: 29/Mar/11  Updated: 17/Oct/12

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

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

Tags: ee7ri_cleanup_deferred

 Description   

Anissa found this catastrophic bug. Easy to reproduce:

1) Environment: DAS, 1 cluster with 2 instances

2) start DAS in verbose mode
asadmin start-domain -v

3) start the cluster:
asadmin start-cluster c1

4) Verify all 3 servers are running

5) Hit ^C in the DAS console

6) See that ALL GlassFish servers are stopped.



 Comments   
Comment by Byron Nevins [ 29/Mar/11 ]

I tried removing the ^C handling behavior in non-Windows platforms (see the diffs below). I.e. after doing this, when you hit ^C, my code does NOT kill the spawned DAS process.

Result: No change was noted. It did not solve the problem. All instances are killed.

Comment by Tom Mueller [ 29/Mar/11 ]

On Unix (or Linux), a ctrl-C at the terminal sends the signal to every process that has the terminal as the controlling terminal. This includes all processes that are forked by processes running on that terminal. So this is a natural function of Unix-like systems.

To get the instance to not exit, they have to be disconnected from the controlling terminal.

Comment by Byron Nevins [ 30/Mar/11 ]

^C maps to SIGINT. When I send a such a signal to DAS – the instances are NOT affected:

kill -2 das-pid

Comment by Bill Shannon [ 30/Mar/11 ]

I'm assuming in this scenario all the instances are running
on the same machine.

Note that the kill command sends the signal to the process,
but ^C on the console sends the signal to the process group.

I'm pretty sure there's another bug about this same general issue.
Without native code, there's no good way to cause the sub-processes
to run in a different process group. I think that makes this a
"will not fix".

The workaround is to not start the domain with -v.

Comment by Byron Nevins [ 31/Mar/11 ]

Here is the best solution IMHO.

In the start-instance command:

PSEUDO-CODE:

if( (OS != Windows) AND (A console is attached))
then refuse to start the instance. Emit a message about the reasons why.

Then it is impossible to get into this bug condition!

How to find out if a console is attached – the verbose flag is set. If it's set then there is a console. Period.

Comment by Nazrul [ 02/May/11 ]

This looks like an improvement

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16278] GF admin needs a way to configure role -> user/group mappings Created: 29/Mar/11  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin, admin_gui
Affects Version/s: 3.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: ringerc Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-951 Need a way to edit / create atleast s... Resolved

 Description   

Currently, role to user/group mappings can only be configured using glassfish-web.xml, which is maintained by the app author and is shipped inside the application's war.

The whole concept of separating "role" and "group" is to make it possible to map application role names (provided by app author) to locally meaningful user and group identities. The application author doesn't know anything about them, and isn't in a position to put anything useful in glassfish-web.xml .

No mechanism is provided by "asadmin deploy" or the web console to override the bundled "glassfish-web.xml" and use a site-customized one with useful role mappings. More importantly, there is no UI in asadmin or the web console to create such mappings. All you can really do is enable the glassfish default role to group mapping then assign users to appropriate groups, essentially destroying the utility of the concept of roles as distinct from groups.

What's needed is:

  • An override mechanism for glassfish-web.xml ; and
  • asadmin and gui commands to display roles in a war and to map those roles to users/groups.





[GLASSFISH-16065] Resolve port conflict automatically during domain creation Created: 21/Feb/11  Updated: 22/May/13

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

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


 Description   

I have the default domain, domain1, running on a machine. I'm creating another domain, e.g. foo, and am getting the following error:

tuppy(j2eetest):/export/home/j2eetest/v3.1# a create-domain foo
Enter admin user name [Enter to accept default "admin" / no password]> admin
Enter the admin password [Enter to accept default of no password]>
Enter the admin password again>
Port for foo (4848) is in use. Try a different port number.
CLI130 Could not create domain, foo
Command create-domain failed.

We resolve instance port conflicts automatically during instance creation, we should do the same for admin port during domain creation. I never specified port 4848, so it would be good if another, free port was picked for me automatically. The port used should be displayed to the user.






[GLASSFISH-16042] Need to expose the value of ${com.sun.aas.hostName} from administration. Created: 17/Feb/11  Updated: 22/May/13

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File jvm-report.jpg    

 Description   

The value of $

{com.sun.aas.hostName}

is used in backend for various purposes.
In the case of multiple host names for a given ip address, one need to know the above value in order to create other virtual servers correctly.
See http://java.net/jira/browse/GLASSFISH-15797 for more details



 Comments   
Comment by Anissa Lam [ 17/Feb/11 ]

I don't see $

{com.sun.aas.hostName}

in any of the elements in domain.xml, so i don't know how GUI will be able to find out such 'key' exist and how to resolve it.
Is this the only key that GUI should display to user ? will there ever be more such case later on ?

I request that admin team provides a command that will return a list of such 'keys' and the corresponding value, then GUI will see where such a page fits in and display that key/value pair to user.
It also depends if the key and value pair is different for each instance. If so, maybe a target option is needed too.

I am transferring this to 'admin'. When such command is available, please transfer to REST so that it can be exposed through REST and then GUI can start implementing such enhancement.

Comment by Anissa Lam [ 17/Feb/11 ]

Sorry, I was just looking at domain.xml and didn't realize that the default value for hostName of Virtual Server is "$

{com.sun.aas.hostName}

" and thus won't get written out to domain.xml.

But this is not the only variable that is used in Virtual Server. $

{com.sun.aas.instanceRoot}

is also used for docroot attribute.
And there maybe other variable used in other config element as well.
So, my request for a command to get the key/value pair is still valid. Please provide such a command, and user can go to one single page to look at all this variables.

Comment by Tom Mueller [ 18/Feb/11 ]

Issue 15797 does not describe the use case for using this information in sufficient detail. Please provide a description of the use case here. When creating a virtual server, what information does the user need to look at, and what situation needs to be avoided in order to have a correct configuration? For example, is it necessary to look at the list of host names for all other virtual servers, on each target and make sure that there are no duplicates?

(If yes, then the virtual server logic could validate this at virtual server creation time, and print out the duplicate names in the error message.)

If the names do need to be unique, and one or more of them uses a system property, such as com.sun.aas.hostName or any other system property, what happens if the value for that property is changed later such that the hosts for the virtual servers are no longer unique? Does the virtual server implementation handle that properly with a suitable error message? If it does, why isn't that message sufficient for catching the configuration error that we are trying to prevent?

Note: the asadmin generate-jvm-report command outputs the values of all of the properties that are defined within the JVM, including com.sun.aas.hostName. So this command already exists. However, the variable values are just in the message and are not returned as properties within the response.

Please reopen the bug when the additional use case details are provided.

Comment by Shing Wai Chan [ 18/Feb/11 ]

When creating virtual servers, one need to specify the list of hosts and listeners. If the host is not specifiedd, it will take a default host value, $

{com.sun.aas.hostName}

.

It is a good idea to let user have the correct the information at the time of creation of the virtual server rather than waiting for information from configuration error.

Checking host names is not sufficient.
See the examples in http://blogs.sun.com/jluehe/entry/virtual_hosting_features_in_glassfish

Comment by Tom Mueller [ 21/Feb/11 ]

The first step in implementing this is to make the output of generate-jvm-report available as properties, so that the REST interface can pick it up.

Then the issue needs to be reassigned to the REST category to get the rest interface to generate-jvm-options.

Then it needs to be reassigned to admingui to design an interface in the console where there information can be made available.

Comment by Anissa Lam [ 21/Feb/11 ]

generate-jvm-report is available through GUI in 3.1. Please see attached.
For DAS and any instance, user can look at the jvm report, with the 4 different type like CLI.





[GLASSFISH-16024] Remove requirement to restart DAS and instances when enabling/disabling secure admin Created: 16/Feb/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16036 enable-secure-admin, disable-secure-a... Resolved
Tags: ee7ri_cleanup_deferred

 Description   

Currently we instruct users to stop non-DAS instances, leaving only the DAS running, when running enable/disable-secure-admin.

Ideally, users could enable and disable secure admin without having to stop remote instances and then restarting the DAS and the remote instances.



 Comments   
Comment by oleksiys [ 12/Jun/12 ]

hi Tim,

is it still the case?

thx.

Comment by Tim Quinn [ 12/Jun/12 ]

I will need to check into it. Please stay tuned!

Comment by Tim Quinn [ 12/Jun/12 ]

(I sent essentially the same information to Alexey separately.)

It seems that a restart is still required.

I'm using a build from a fairly current workspace (from the last few days). This sequence shows that a restart is required.

Edit pw.txt so it contains:

AS_ADMIN_PASSWORD=some-non-empty-password
AS_ADMIN_NEWPASSWORD=the-same-pw-as-above

asadmin stop-domain domain1
asadmin delete-domain domain1
export AS_ADMIN_PASSWORDFILE=pw.txt
asadmin create-domain --user admin domain1

asadmin enable-secure-admin

#(do not restart the DAS)

export AS_TRACE=true

asadmin uptime

#You'll see a dump of some useful information. Notice that the debugging output does not say it is following any redirection.

asadmin restart-domain domain1

# The "stop-domain" part of the output shows no redirection. Then you'll see asadmin wait for the restart to complete
# and then, when asadmin sends an "uptime" command to ping the newly-restarted server, you see the redirection.

The redirection does not occur until after the restart.

Comment by oleksiys [ 13/Jun/12 ]

hi Tim,

i revisited the code, looks like in our DynamicConfigListener we explicitly disallow dynamic admin-listener reconfiguration (I'm pretty sure there was/is a reason why we do this, but at the moment I don't remember details), which requires restart of admin-listener's server socket. And enable-/disable-secure-admin requires server socket reinitialization.

What we can do is implement specific GrizzlyService.restartAdminListener(listenerName) method, which you can call to restart admin-listener explicitly from your code.

Will it work for you?

Comment by Tim Quinn [ 13/Jun/12 ]

I think that sounds workable...although would it be GrizzlyService.restartListener(listenerName) (instead of the method name being restartAdminListener)?

Comment by oleksiys [ 27/Jun/12 ]

hi Tim,

I've just commited the change [1].
You can use GrizzlyService.restartNeworkListener(...) method to restart specific listener.
Let me know if it works for you.

[1]
54826 Wed Jun 27 15:59:59 CEST 2012 oleksiys
+ update required to fix
http://java.net/jira/browse/GLASSFISH-16024
"Remove requirement to restart DAS and instances when enabling/disabling secure admin"

Comment by oleksiys [ 04/Jul/12 ]

reassigning to Tim.

Comment by Ryan Lubke [ 16/Oct/12 ]

Setting the component to admin as the issue has been reassigned to Tim (Grizzly side of this issue is in place for Tim's use).

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16012] RestartRequired: display reason for instances other than DAS Created: 16/Feb/11  Updated: 05/Apr/11

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

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

Tags: 3_1-exclude

 Description   

I cannot find an issue logged for this already, so here it goes. When DAS requires a restart, user can find out what configuration or other changes triggered restart required in Admin Console. However, it is not so for standalone and clustered instances. We should provide this information for all server instances to the users.



 Comments   
Comment by Anissa Lam [ 16/Feb/11 ]

_get-restart-required which provide the reason doesn't support target.

Usage: asadmin [asadmin-utility-options] _get-restart-required
[-why[=<why(default:false)>]] [?|--help[=<help(default:false)>]]

This needs to be supported before GUI can work on this.
Transfer to 'admin'. Please transfer back to GUI when this is ready so that we can display this to user.

Comment by Tom Mueller [ 18/Feb/11 ]

list-instances is the command for getting the status of an instances, and it includes the reasons that a restart is required. It takes a target option so that it is possible to get the status of just one instance.

However, it doesn't put the status information into properties in the report. The REST interface would need this so that the console can use the information.

Please evaluate this for possible inclusion in 3.2.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-16009] Improve error message: cannot start instance with added remote JMS Host (embedded type) Created: 16/Feb/11  Updated: 22/May/13

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

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

build promoted b43


Attachments: Text File instance.server.log     JPEG File jmshost-startup-error.JPG    
Tags: 3_1-exclude

 Description   

In the following scenario, standalone instance fails to start after adding a "remote" JMS Host:

1. In Admin Console create a standalone instance and start it, e.g. in1.
2. Go to instance's config, Java Message Service, JMS Hosts.
3. Create a new JMS Host specifying a remote machine for "Host" field, leave rest default (e.g. port 7676). Save changes.
4. Go to instance's page and stop instance. Now start instance and the following error is displayed:

An error has occurred
Could not start instance in1 on node localhost-domain1 (localhost). Command failed on node localhost-domain1 (localhost): Waiting for in1 to start ..................Command start-local-instance failed. Error starting instance in1. The server exited prematurely with exit code 0. Before it died, it produced the following output: Launching GlassFish on Felix platform [#|2011-02-16T11:22:57.990-0800|INFO|oracle-glassfish3.1|org.glassfish.ha.store.spi.BackingStoreFactoryRegistry|_ThreadID=10;_ThreadName=main;|Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry|#] [#|2011-02-16T11:22:58.972-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=27;_ThreadName=Grizzly-kernel-thread(1);|Grizzly Framework 1.9.31 started in: 192ms - bound to [0.0.0.0:24848]|#] [#|2011-02-16T11:22:59.482-0800|SEVERE|oracle-glassfish3.1|grizzly|_ThreadID=15;_ThreadName=Grizzly- .... msg.seeServerLog

The instance's server.log contains:

[#|2011-02-16T11:22:59.482-0800|SEVERE|oracle-glassfish3.1|grizzly|_ThreadID=15;
_ThreadName=Thread-1;|doSelect IOException
java.net.BindException: No free port within range: 7676=com.sun.enterprise.v3.se
rvices.impl.ServiceInitializerHandler@1fcb845

It looks like glassfish is trying to start a service on 7676 on localhost (that's in use by DAS), while the user will think that it should be connecting to an existing broker running on the remote system, as specified in JMS Host screen.

The issue here is that JMS broker is running in embedded mode by default and users may not be aware of that. Thus user needs to change the Type in Java Message Service screen to Remote, in addition to specifying the remote JMS Host. This is not intuitive and may be hard to debug, making users believe it's a Glassfish bug. We should improve the message displayed in Admin Console (printing the actual cause of the error, that's plainly evident in server.log) but we also need to suggest to users to check Java Message Service type in the error message, if a JMS port conflict occurs. It may be prudent to display a warning on the JMS Host screen, when user creates a new JMS Host and the Host value entered does not resolve to localhost AND the type for JMS, in this configuration, is embedded. Warning could say that Java Message Service type is EMBEDDED and therefore all JMS brokers will be started on localhost. Change the JMS type if you want to connect to a broker on a remote system.



 Comments   
Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-16165] Make the set command faster Created: 06/Mar/11  Updated: 22/May/13

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

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

Issue Links:
Dependency
depends on GLASSFISH-15458 Rewrite asadmin set, get, list subcom... Open
Tags: ee7ri_cleanup_deferred

 Description   

I've been writing a lot of devtests that use the set command. It dawned on me that the set command is super-slow for what it does.
I think it might be low-hanging fruit to speed it up. If that were successful many tests (dev/QL/QE) would speed up significantly.

Warning – the method of interest is over 250 lines long.

I may be wrong – I haven't thoroughly tested – this is mostly a hunch...



 Comments   
Comment by Tom Mueller [ 07/Mar/11 ]

The slowness in set is most likely because it generates all possible dotted names that start with the given prefix, and then looks for one that matches what the user entered. So it is doing much more work than it has to do.

There is already an issue filed (15458) for rewriting the set command. Marking this one as dependent on that.

Comment by Tom Mueller [ 18/Mar/11 ]

Making this an RFE.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16147] Domain was created with master password. start-instance failed Created: 03/Mar/11  Updated: 02/May/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-16146 Umbrella bug. Created a domain with ... Open
blocks GLASSFISH-16149 Created a domain with a master passwo... Open

 Description   

Executed steps that were described in the umbrella bug 16146.

Then executed start-instance:
=======================================================
asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin start-instance in9
remote failure: Could not start instance in9 on node localhost-domain12 (localhost).

Command failed on node localhost-domain12 (localhost): CLI801 Instance is already synchronized
Command start-local-instance failed.

The Master Password is required to start the domain. No console, no prompting possible. You should either create the domain with --savemasterpassword=true or provide a password file with the --passwordfile option.

To complete this operation run the following command locally on host localhost from the GlassFish install location /opt/glassfish3:

asadmin start-local-instance --node localhost-domain12 --sync normal in9
Command start-instance failed.
====================================================

The password.txt file had such content:

AS_ADMIN_PASSWORD=adminadmin
AS_ADMIN_MASTERPASSWORD=admin123



 Comments   
Comment by Tom Mueller [ 03/Mar/11 ]

It looks as though the password file is not passed through the SSH invocation of start-local-instances. Is that expected?

Comment by Joe Di Pol [ 03/Mar/11 ]

Correct. The current implementation never copies the master password over the network. So if you change the master password on the domain to something other than the default you must use a master password file on the instances in order for start-instance (and therefore start-cluster) to work.

Comment by Bhakti Mehta [ 04/Mar/11 ]

I dont think this is a bug but expected behaviour . Since there is no savemasterpassword=true when the create-local-instance is called. There is no master password file. You can either create the local instance using savemasterpassword=true or run the change-master-password command for the instances with savemasterpassword=true. For more info see this blog from Carla http://weblogs.java.net/blog/carlavmott/archive/2011/03/02/glassfish-31-using-master-password-and-managing-instances too

Comment by easarina [ 04/Mar/11 ]

I don't agree. First create-instance doesn't have savemasterpassword option. I.e if a user created an instance using create-instance command he can not start it using start-instance command. (The blog is not available now). But I believe that if master password was passed in passwordfile, it has to be taken from there without any other preconditions.

Comment by Nazrul [ 02/May/11 ]

GlassFish 3.1 is behaving as expected. We never send master password over the wire. If user sets a master password, then 3.1 offer the following options:

1) Use create-local-instance --savemasterpassword option to save the master password locally
2) Use change-master-password --savemasterpassword option to save the master password locally

Converting these 3 issues to Improvement to investigate if we can make life any easier without compromising security.





[GLASSFISH-16146] Umbrella bug. Created a domain with master password. Several start commands failed. Created: 03/Mar/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
depends on GLASSFISH-16150 Created a domain with master password... Resolved
depends on GLASSFISH-16147 Domain was created with master passwo... Open
depends on GLASSFISH-16149 Created a domain with a master passwo... Open
Tags: ee7ri_cleanup_deferred

 Description   

Build 43. Sparc machine.
1) Created a new domain with master password. I.e. was used such command:

asadmin --passwordfile ./password.txt --user admin create-domain --domaindir /opt/glassfish3/glassfish/domains --adminport 9999 --instanceport 4444 --savemasterpassword=true --usemasterpassword=true --savelogin=false --checkports=true --nopassword=false domain12

2) Started domain
3) Created a cluster: asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-cluster c1
Command create-cluster executed successfully.
4) Created a local instance: asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-local-instance --cluster c1 --node localhost-domain12 in9
Rendezvoused with DAS on localhost:9999.
Port Assignments for server instance in9:
JMX_SYSTEM_CONNECTOR_PORT=28689
JMS_PROVIDER_PORT=27679
HTTP_LISTENER_PORT=28083
ASADMIN_LISTENER_PORT=24851
JAVA_DEBUGGER_PORT=29009
IIOP_SSL_LISTENER_PORT=23820
IIOP_LISTENER_PORT=23700
OSGI_SHELL_TELNET_PORT=26666
HTTP_SSL_LISTENER_PORT=28184
IIOP_SSL_MUTUALAUTH_PORT=23920
Command create-local-instance executed successfully.

5) Started a local instance: asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin start-local-instance --node localhost-domain12 in9
Waiting for in9 to start .................................
Successfully started the instance: in9
instance Location: /opt/glassfish3/glassfish/nodes/localhost-domain12/in9
Log File: /opt/glassfish3/glassfish/nodes/localhost-domain12/in9/logs/server.log
Admin Port: 24851
Command start-local-instance executed successfully.
6) Stopped a local instance: asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin stop-local-instance --node localhost-domain12 in9
Waiting for the instance to stop ...
Command stop-local-instance executed successfully.

Then tried to execute start-instance, restart-instance, start-cluster, all these commands failed. This is an umbrella bug for start with master password issues. For domains without master password, all these commnds worked fine.



 Comments   
Comment by Nazrul [ 03/Mar/11 ]

Requesting Bhakti to investigate if these are real issues.

Comment by Byron Nevins [ 08/Mar/11 ]

Bhakti - take a look at 16150 comments from me.

Try replacing the relative path of the password file to an absolute path (in the asadmin commands). Should only take a couple minutes to try...

Comment by Nazrul [ 20/Apr/11 ]

We should look in this issue during 3.1.1

Comment by Nazrul [ 02/May/11 ]

GlassFish 3.1 is behaving as expected. We never send master password over the wire. If user sets a master password, then 3.1 offer the following options:

1) Use create-local-instance --savemasterpassword option to save the master password locally
2) Use change-master-password --savemasterpassword option to save the master password locally

Converting these 3 issues to Improvement to investigate if we can make life any easier without compromising security.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16140] server running as a service on Windows exits when user logs out (need -Xrs JVM option) Created: 03/Mar/11  Updated: 17/Oct/12

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Duplicate
duplicates GLASSFISH-5263 Platform Services and the -Xrs option Resolved
Tags: ee7ri_cleanup_deferred

 Description   

From the GlassFish forum:
http://www.java.net/forum/topic/glassfish/glassfish/glassfish-v31-rc-and-asadminbat-oracle?force=200

If Oracle would like the asadmin create-service feature to be useful on Windows, then two things should be done to the default installation of GlassFish 3.1 to prevent the GlassFish Windows service from being shut down when the user logs out:
1) asadmin.bat's call to the java.exe needs -Xrs JVM option.
2) domain.xml needs a new <jvm-options>-Xrs</jvm-options>

Ryan



 Comments   
Comment by Tom Mueller [ 03/Mar/11 ]

Updated summary to read like a bug.

Comment by Byron Nevins [ 03/Mar/11 ]

I've blogged about this well-known issue:

http://blogs.sun.com/foo/entry/how_to_make_v3_platform

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

We decided to keep this step for the user to do in 3.1. The main problem was that if I just plopped it in there you would not get stack traces with a KILL signal. Then users would be confused about that. Of course all known Java SE 6 implementations now have a jstack command [1] so that problem has mostly gone away.

Another problem is that there is no official delete-service command. So – if we added -Xrs to the server config as part of create-service, there would be no corresponding way to undo that.

Yet another problem is adding -Xrs to asadmin.bat The proper solution here, is to have a clone of asadmin.bat "start-service.bat" or something like that. Adding a new bat file to the installation is also a BIG deal.

So that left the only clean solution to be adding -Xrs to ALL server configs. This was decided to be unacceptable.

In 3.2 we will revisit this issue. I think we will probably add -Xrs to the config for all servers. After all it *is* an application server!

[1] it took FOREVER for Apple to implement it.

Comment by Byron Nevins [ 03/Mar/11 ]

D:\gf\v3\packager\nucleus-base>svn commit -F ..\svn-commit.tmp
Sending nucleus-base\bin\asadmin
Sending nucleus-base\bin\asadmin.bat
Sending nucleus-base\lib\templates\domain.xml
Transmitting file data ...
Committed revision 45384.

Comment by Byron Nevins [ 03/Mar/11 ]

Note that this does not just affect GF as a service. On the contrary! It is much much more likely to occur when running GF not-as-service!

I.e. most users will have GF-as-a-service run as system account – which never logs out. A non-service GF server, on the other hand, is almost always running as a user account and will immediately exit if the user logs out.

As of today – all GF servers will, by default, ignore all signals.

I added "-Xrs" to asadmin, asadmin.bat and to the 2 config elements in the default domain.xml

Comment by Byron Nevins [ 11/Mar/11 ]

I have heard negative feedback. I'll restore the code to the way it was, and keep this bug alive so it can be dealt with permanently for the next release.

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

Hi, bnevins.

Adding -Xrs, kill -QUIT for getting threads dump must be ignored onUNIX
Systems.

So, Can you add the option just only Windows System?

How about adding it as variable on asenv.bat?

Thanks,

Comment by Byron Nevins [ 11/Mar/11 ]

http://blogs.sun.com/foo/entry/how_to_make_v3_platform

Comment by Byron Nevins [ 11/Mar/11 ]

Documentation:
http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gglqp.html#giurf

Comment by Byron Nevins [ 22/Mar/11 ]

It's not feasible to put -Xrs oly for Windows. In order to do that I'd have to hide it in code and the user could not get rid of it. We can't have different default domain.xml files either.

One option is to add it as a jvm-option when the service is created on Windows but that's also a huge deal (requires the server(s) to be running. Yet more code for delete-service)

Comment by Byron Nevins [ 22/Mar/11 ]

reopen as RFE

Comment by Tom Mueller [ 22/Mar/11 ]

How about adding $

{Xrs} to the JVM options, and then in asenv.bat, add set Xrs=-Xrs, but don't add it to asenv.conf so that the ${Xrs}

doesn't expand to anything?

One problem with this is that the $

{Xrs}

could not be removed using delete-jvm-options because it wants every option to start with a dash.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-15971] start-local-instance should defer clean up until das could be contacted Created: 14/Feb/11  Updated: 22/May/13

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

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


 Description   

if start-local-instance is used with --sync full the local configuration is deleted before DAS is contacted. If DAS is down user cannot retry with --sync none because everything has been deleted by previous command.

Expected: do not delete config until it is clear that das is reachable and --sync full will work

how to reproduce
1. create cluster and remote instances
2. stop das
3. start-local-instance --sync full -> fails because das is down
4. start-local-instance --sync none -> fails because 3. has deleted config

This will only happen with --sync full, if --sync is omitted the command reports "Warning: Synchronization with DAS failed, continuing startup..." which is the behavior I would expect.



 Comments   
Comment by Tom Mueller [ 14/Feb/11 ]

This is a good idea. One way to implement this would be to rename the various instance directories to a backup name rather than deleting them at the beginning of the process. Then, at the end, either the directories can be actually deleted (if the sync was successful) or restored to the original names (if the sync failed).

Comment by Tim Quinn [ 14/Feb/11 ]

Just be careful to test carefully on Windows platforms. On Windows open files cannot be renamed and will prevent containing directories from being renamed as well.

Comment by schaarsc [ 14/Feb/11 ]

as an intermediate step to the solution suggested by Tom Mueller, I'd like to suggest to first try to contact DAS before doing anything on local disk. If DAS is not reachable sync will fail for sure. Maybe this check could be squeezed into a version before 3.2 ...

Comment by Tom Mueller [ 14/Feb/11 ]

The window for getting this type of change into 3.1 has closed. Will consider this for the next release.

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-16258] Provide metrics about feature usage Created: 24/Mar/11  Updated: 17/Oct/12

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

Type: New Feature Priority: Major
Reporter: Tom Mueller Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

From the admin infrastructure planning discussions. This is an "extra credit" for 3.2.

Collect data on features being used by users (usage statistics)



 Comments   
Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-17025] Optimize startup by avoiding modules change detection logic Created: 13/Jul/11  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1
Fix Version/s: future release

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


 Description   

Currently we spend anywhere between 100 to 150 ms (3-4%) to detect if any module in modules/ has changed or not. In a real(production) environment, this may not be necessary, since in such an environment, a change in the installation is done via an admin tool like pkg or admin console. If admin module can enhance their tool to notify glassfish launcher about any change made in the system, then we should be able to avoid this logic in production environment. Prioritize as you see fit. Close if this can't be done.



 Comments   
Comment by Tom Mueller [ 29/Sep/11 ]

Whenever IPS updates a file in GlassFish, the "modules" directory itself is modified. So one possible optimization might be to check the modification time of the "modules" directory, and if it isn't newer than the cache (which is the typical case) then skip checking the individual files.

The problem with this is that this doesn't work for the typical developer case in which a developer just use "cp" to copy in a new version of the JAR file. If the developer would remove the old version and then copy in the new version it would work.

Maybe there could be a "production" configuration option which would only work when IPS is being used to update the files.





[GLASSFISH-17234] generate-domain-schema --showsubclasses fails with stack overflow Created: 24/Aug/11  Updated: 14/Jan/12

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

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Justin Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

at com.sun.enterprise.admin.cli.schemadoc.HtmlFormat.buildToc(HtmlFormat.java:174)
is repeated on the stack due to what appears to be infinite recursion.

This appears to be due to a circular reference in the virtualization config beans.

ServerPoolConfig has:

@Element(reference = true)
List<VirtualMachineConfig> getVirtualMachineRefs();

While VirtualMachineConfig has:

@Attribute(reference = true)
ServerPoolConfig getServerPool();

is the problem that generate-domain-schema isn't dealing with the "reference=true" properly?






[GLASSFISH-16709] install-node in Oracle GlassFish Server complains about unknown backup-configs elements in domain.xml Created: 23/May/11  Updated: 01/Nov/11

Status: In Progress
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: None

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-17189 Parser Dumping a LOT of Noise in inst... Resolved
Tags: 3_1_2-exclude

 Description   

When I ran install-node from the Oracle GlassFish Server download it complained with the following:

$ ./asadmin install-node --installdir /var/tmp/glassfish3 localhost
Ignoring unrecognized element schedules at Line number = 31
Column number = 18
System Id = file:/Users/demo/glassfish3/glassfish/domains/domain1/config/domain.xml
Public Id = null
Location Uri= file:/Users/demo/glassfish3/glassfish/domains/domain1/config/domain.xml
CharacterOffset = 1793

Ignoring unrecognized element backup-configs at Line number = 36
Column number = 23
System Id = file:/Users/demo/glassfish3/glassfish/domains/domain1/config/domain.xml
Public Id = null
Location Uri= file:/Users/demo/glassfish3/glassfish/domains/domain1/config/domain.xml
CharacterOffset = 2002

It seemed to function correctly. It looks like install-node does not like the das backup elements that only appear in the OGS domain.xml.



 Comments   
Comment by Yamini K B [ 01/Jun/11 ]

install-node parses static domain.xml for reading in node entries. The issue seems to be with parsing the domain.xml, parsing succeeds but with some messages for undefined elements.

To reproduce the issue, add <schedules/> under <config> element and run install-node or even verify-domain-xml

Re-assigning to Jerome since its a ConfigParser issue.

Comment by dochez [ 27/Jun/11 ]

It seems to me the issue as a packaging issue where modules (containing the config XML binding elements) are missing.

Comment by Joe Di Pol [ 06/Jul/11 ]

This can be reproduced using verify-domain-xml. Since this doesn't appear to be specific to install-node I'm assigning to Chris. Note that the warning won't appear until after the domain has been started at least once. I'm dropping the priority since everything does function correctly despite the warnings.

Here are the steps to reproduce:

Install ogs-3.1.zip. Note that the first verify-domain-xml does not report the warnings. But if you start the domain and then run verify-domain-xml you get the warnings.

$ asadmin verify-domain-xml
All tests passed; domain.xml is valid.
Command verify-domain-xml executed successfully.

$ asadmin start-domain
Waiting for domain1 to start ...
Successfully started the domain : domain1
domain Location: /export/tmp/glassfish3/glassfish/domains/domain1
Log File: /export/tmp/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

$ asadmin verify-domain-xml
Ignoring unrecognized element schedules at Line number = 31
Column number = 18
System Id = file:/export/tmp/glassfish3/glassfish/domains/domain1/config/domain.xml
Public Id = null
Location Uri= file:/export/tmp/glassfish3/glassfish/domains/domain1/config/domain.xml
CharacterOffset = 1793

Ignoring unrecognized element backup-configs at Line number = 36
Column number = 23
System Id = file:/export/tmp/glassfish3/glassfish/domains/domain1/config/domain.xml
Public Id = null
Location Uri= file:/export/tmp/glassfish3/glassfish/domains/domain1/config/domain.xml
CharacterOffset = 2002

Comment by Byron Nevins [ 28/Sep/11 ]

Output is more scary now. This is what you see with the logging turned up:
(note bad grammar in the error message as well)

d:\gf\main\nucleus\cluster>cli install-node --dcom --sshuser wnevins -W d:/pw --archive d:/temp/gf.zip wnevins-lnr
Listening for transport dt_socket at address: 1234
CLASSPATH= D:\glassfish3\glassfish\modules\admin-cli.jar
Commands: [install-node, --dcom, --sshuser, wnevins, -W, d:/pw, --archive, d:/temp/gf.zip, wnevins-lnr]
asadmin extension directory: D:\glassfish3\glassfish\lib\asadmin
Prepare
Process program options
Parsing program options
Update program options
Passwords were read from password file: D:/pw
Parse command options
params:

{dcom: [true] sshuser: [wnevins] archive: [d:/temp/gf.zip] }

operands: [wnevins-lnr]
Prevalidate command options
Inject command options
Validate command options
Domain XML file = D:\glassfish3\glassfish\domains\domain1\config\domain.xml
org.jvnet.hk2.component.ComponentException: ConfigInjector for org.glassfish.grizzly.config.dom.NetworkConfig is not found, is it annotated with @Conf
igured
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:122)
at org.jvnet.hk2.config.ConfigModel.parseValue(ConfigModel.java:920)
at org.jvnet.hk2.config.ConfigModel.<init>(ConfigModel.java:836)
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:105)
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:123)
at org.jvnet.hk2.config.ConfigModel.parseValue(ConfigModel.java:920)
at org.jvnet.hk2.config.ConfigModel.<init>(ConfigModel.java:836)
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:105)
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:123)
at org.jvnet.hk2.config.ConfigModel.parseValue(ConfigModel.java:920)
at org.jvnet.hk2.config.ConfigModel.<init>(ConfigModel.java:836)
at org.jvnet.hk2.config.DomDocument.buildModel(DomDocument.java:105)
at org.jvnet.hk2.config.DomDocument.getModelByElementName(DomDocument.java:138)
at org.jvnet.hk2.config.ConfigParser.handleElement(ConfigParser.java:141)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:98)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:115)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:110)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:106)
at com.sun.enterprise.admin.cli.cluster.NativeRemoteCommandsBase.checkIfNodeExistsForHost(NativeRemoteCommandsBase.java:311)
at com.sun.enterprise.admin.cli.cluster.InstallNodeCommand.validate(InstallNodeCommand.java:113)
at com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:254)
at com.sun.enterprise.admin.cli.AsadminMain.executeCommand(AsadminMain.java:299)
at com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:238)
asadmin --host localhost --port 4848 --passwordfile D:/pw --interactive=true --echo=false --terse=true install-node --archive d:/temp/gf.zip --install
dir $

{com.sun.aas.productRoot}

--create=false --save=false --force=false --dcom=true --sshuser wnevins --sshport 22 wnevins-lnr
Execute command
Found D:\temp\gf.zip
com.sun.enterprise.universal.process.WindowsException: Can not create directory - it already exists: smb://10.28.51.117/D$/glassfish3/
Command install-node failed.
Listening for transport dt_socket at address: 1234

d:\gf\main\nucleus\cluster>lnrc

Comment by Chris Kasso [ 01/Nov/11 ]

It appears this problem is occurring because the classpath of asadmin (specifically admin-cli.jar) does not contain the value add jar files. The install-node and verify-domain-xml commands are both local and thus do not share the CP of the server. When they attempt to parse the domain.xml they locate elements for which no class is available.

One solution is to build OGS such that admin-cli.jar contains das-backup.jar in its CP.

A more generic solution is needed though. A value-add developer should be able to add new config via the ConfigExtension interface and drop their value-add modules into the modules directory without the need to modify the CP of asadmin in the way that is currently required. The current approach defeats the value of the ConfigExtension interface.





[GLASSFISH-16669] Importing a SSL signed certificate from the Admin Console From a Certificate On the Server Created: 17/May/11  Updated: 17/May/11

Status: Open
Project: glassfish
Component/s: admin, admin_gui, rest-interface
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: LocusAsaf Assignee: Jason Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next

 Description   

Loading a SSL certificate into Glassfish is difficult right now. The instructions in the Glassfish documentation are not very clear and there is a lot of different literature online that differs from it, which makes things even more confusing. It would be great if you could load a certificate into a domain directly from the console (by choosing the signed certificate file from your machine) and then assign it to be used by that domain.



 Comments   
Comment by Jason Lee [ 17/May/11 ]

This is an RFE the user and I discussed on IRC to be considered in the GlassFish 4 timeframe.





[GLASSFISH-16523] Platform Services - Add Support for All UNIX Created: 02/May/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Tags: ee7ri_cleanup_deferred

 Description   

We currently support all versions of Windows, all versions of Linux and Solaris-SMF.
Add support for all UNIX including non-SMF Solaris.



 Comments   
Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16522] Add Command for list-services Created: 02/May/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Tags: ee7ri_cleanup_deferred

 Description   

Add list-services command



 Comments   
Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16440] change message to user when trying to start Glassfish using same binary that started original Glassfish process Created: 22/Apr/11  Updated: 22/May/13

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

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


 Description   

When I try to start Glassfish twice, using the same binary, it doesn't detect this, and reports generic message about some process already started:

"There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server."

There is indeed a process already using the admin port, but this part of the message lead me to believe that it thought it was another binary starting itself to create an instance of Glassfish server - "it probably is another instance of a GlassFish server". Is there any way to know using process ID and path comparisions, along with domain.xml to detect which binary of Glassfish was started that is using port already?

Here is what I see:

C:\glassfish31\glassfish3\glassfish\jersey\samples>which asadmin
c:/glassfish31/glassfish3/glassfish/bin/asadmin.bat

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

C:\glassfish31\glassfish3\glassfish\jersey\samples>asadmin start-domain domain1
There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server.
Command start-domain failed.



 Comments   
Comment by Tom Mueller [ 22/Apr/11 ]

Do you have a suggestion about what the message should say in the example that you provided at the end of the description?

The start-domain could try to do the following:

1. Look in the config directory of the domain that you are trying to start for a "pid" file, and if one is there, and that pid is active on the system, then the message could say, "the DAS you are trying to start is already running".

2. If there is no pid file or the pid in that file is not active on the system, start-domain could look at the other domains in the domains directory it is using (or in the default domains directory) to see if there are any other domains that also use the same port, and if those domains have pid file and one of those pids is active, then it could print a message that says, "such and such domain is already running and it uses the same port as this domain".

3. At this point, the process listening on port 4848 might be a GlassFish DAS for a domain from an entirely different install of GlassFish or from a non-default domains directory. Using the capabilites of "jps" we could look at the process information for the Java process running on the system to see if any ASMain classes are running, and from the command line arguments for the process, we could determine the config directory for the process, and from that determine if that process is listening on the requested port (this requires parsing the domain.xml for a potentially different version of GlassFish). Start-domain could then look for a pid directory for that server and see if it matches the pid that we are looking at and if so, print a message as in step 2. Depending on how ASMain was started, the command line information may or may not be available.

4. If the process hasn't been found yet, start-domain could probe port 4848 by sending a message to it to see how it responds. If it responds with something that looks like GlassFish, we could print a message saying, "port 4848 is in use by a process that is very likely a GlassFish process from another install or a different domains directory". However, probing an unknown server might be considered unfriendly, so a command option might be needed to have start-domain do this.

5. If the probe doesn't yield anything, then start-domain could print a message that says, "there is a process already using port 4848, but start-domain could not determine anything about what that process might be"

Comment by jbenoit [ 23/Apr/11 ]

I'm not sure what exact message I'd expect to see in my scenario. Your comments and messages back to user are more helpful I think than what user currently sees, and are on the right track of what I'd expect and hope to see. Maybe something like this:

There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
Not successful in starting the domain : domain1
Other Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1

Command start-domain failed.

Maybe I'm being overly verbose, but you get the idea.

It just struck me as odd that glassfish didn't know that it was "this same glassfish" that was just started, and reported back to user that port 4848 was in use in previous command. The ouptut from the first start-domain command is clearly telling user which glassfish is started, including path information, i.e.
"Successfully started the domain : domain1
domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1
Log File: C:\glassfish31\glassfish3\glassfish\domains\domain1\logs\server.log
Admin Port: 4848"

Than along comes this second attempt to start-domain in the same shell, using the same path to the same glassfish, yet the glassfish couldn't somehow leverage some information from some place to report back to user that "this same glassfish" is already started. Makes glassfish look like it's not maximizing the known set of information available when producing error message back to user, it doesn't match what seems to be obvious when reporting "it probably is another instance of a GlassFish server."

My use case is this: I'm testing multiple binary installs of various Glassfish versions, both inside Netbeans and standalone. Sometimes I start Glassfish within Netbeans IDE and leave it running. I then do some other testing of another Glassfish install outside of Netbeans. When I try to start standalone Glassfish, it complains that port is already in use. Then I remember that I may have started Glassfish within Netbeans, so I stop domain running inside Netbeans. Then my standalone Glassfish domain can start. Other times Glassfish in Netbeans isn't the culprit, it's another standalone install of Glassfish started and left running, someplace, which I have to track down manually. I was hoping that Glassfish itself could be more helpful identifying the culprit process that is using default port, thus blocking another instance of Glassfish from starting. The analogy is "port in use" messages seen in server.log, which now identify which port is already in use, so user can change conflicting ports, 3700, 7676 etc. If Glassfish's asadmin start-domain domain1 command can be more helpful in helping users identify which process is using port, and if it's Glassfish process using that port, help user find path to that process, then user can more quickly stop the blocking process, or change conflicting ports, or take whatever appropriate corrective action necessary.

Ideally, from the use case scenario/perspective I've described, I think I'd like to know what path to "other Glassfish" is running so I could stop it, if it's Glassfish, that is using port that blocks new Glassfish from starting.

Comment by jbenoit [ 23/Apr/11 ]

To clarify, in my original scenario, where I start glassfish twice using same binary from same path, proposed message could be:

There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
Not successful in starting the domain : domain1
Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\glassfish31\glassfish3\glassfish\domains\domain1

Command start-domain failed.

In the case where it's a different Glassfish binary install from different location that was started and left running, thus blocking my new Glassfish from starting, then this type of message may be more appropriate and help point to location of offending Glassfish occupying conflicting port:

There is a process already using the admin port 4848 – it is another instance of a GlassFish server.
Not successful in starting the domain : domain1
Glassfish Domain domain1 already using this port: 4848 - domain Location: C:\another\glassfish31\glassfish3\glassfish\domains\domain1

Command start-domain failed.

the key is to include path to another "domain Location" so we know where to go to stop process, or take other corrective action.





[GLASSFISH-16526] Add restart-service command Created: 02/May/11  Updated: 17/Oct/12

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

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

Issue Links:
Dependency
blocks GLASSFISH-16311 Improve operating service (OS) integr... Open
Tags: ee7ri_cleanup_deferred

 Description   

For the user's convenience, run the platform-dependent commands needed to restart a (GlassFish) service.



 Comments   
Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-17774] set network listener address to ${EXTERNAL-ADDR} fails with ConstraintViolationException Created: 18/Nov/11  Updated: 14/Jan/12

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

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

Tags: 3_1_2-exclude

 Description   

Following instructions from Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide (http://docs.oracle.com/cd/E18930_01/html/821-2426/gjfnl.html#gjdlw) we set up our cluster instances and then tried to set:

set T91GLF_CLUSTER-config.network-config.network-listeners.network-listener.http-listener-1.address=\$

{EXTERNAL-ADDR}

But failed with:
remote failure: Could not change the attributes: javax.validation.ConstraintViolationException: Constraints for this NetworkListener configuration have been violated: on property [ address ] violation reason [ must be a valid network address ]
javax.validation.ConstraintViolationException: Constraints for this NetworkListener configuration have been violated: on property [ address ] violation reason [ must be a valid network address ]
Command set failed.

EXTERNAL-ADDR for the instance is shown as serv3898 which is a valid hostname and can be solved as IP address.
It isn't possible to set the value via console web application either.

So How is the feature of different listenaddresses for cluster members supposed to be working?



 Comments   
Comment by Peter Doschkinow [ 01/Dec/11 ]

This method:

a) set http-listener-1 to a variable in the cluster config:
asadmin set c1-config.network-config.network-listeners.network-listener.http-listener-1.address=$

{EXTERNAL-ADDR}
b) create your instance/instances like:
asadmin create-local-instance --systemproperties EXTERNAL-ADDR=192.168.56.1 --cluster c1 i1

has very different consequences when applied to other listeners:

Trying to use the same method to bind the iiop listener to a specific address with:
asadmin set c1-config.iiop-service.iiop-listener.orb-listener-1.address=${EXTERNAL-ADDR}

does not complain, the entry is made in the iiop-listener element in domain.xml:
<iiop-listener id="orb-listener-1" port="$

{IIOP_LISTENER_PORT}

" address="$

{EXTERNAL-ADDR}"></iiop-listener>
but seem to not have been interpreted and does not achieve the desired binding.

If you try to apply the same method to bind the jmx listener to a specific address, you can not use "asadmin set" since the address attribute seem to not be writable, but when edited by hand in domain.xml:
<jmx-connector port="${JMX_SYSTEM_CONNECTOR_PORT}" address="${EXTERNAL-ADDR}

" security-enabled="false" name="system" auth-realm-name="admin-realm"></jmx-connector>
the desired binding works: TCP 192.168.56.1:28686 0.0.0.0:0 LISTENING

This leads to the assumption that the method should be ok, but there are maybe implementation bugs.

Comment by Tom Mueller [ 02/Dec/11 ]

A workaround for the original problem is to stop the DAS, manually edit the domain.xml file so that the address attribute is "$

{EXTERNAL_ADDR}

" for the http-listener in the T91GLF_CLUSTER-config and then start the DAS again. The correct property substitution will occur when the server is started. The problem here is with the validation during the set command not substituting in the system property before doing the validation.

Regarding the first comment, please create separate issues if you are seeing property interpolation issues. This issue will be used to fix the specific problem of validation failing when a set command is done on an attribute that has a validator.

Comment by Tom Mueller [ 02/Dec/11 ]

Jennifer, can you please look at this. It appears that the problem is that when the validator is evaluated by HK2 during a set command, the value that is passed to the validator has not system properties substituted, so the validation fails. Thanks.

Comment by Jennifer Chou [ 22/Dec/11 ]

If the set command passes the resolved value to hk2, this will pass the validation but hk2 will set the property as the resolved value instead of the variable $

{EXTERNAL-ADDR}

.

Either
hk2 would need to be enhanced so we can do a validation without setting the property value.

Or
org.glassfish.grizzly.config.dom.NetworkAddressValidator can evaluate $

{XXXX}

values as valid.

Transferring to Justin to evaluate this for NetworkAddressValidator.





[GLASSFISH-17553] convert install-node and uninstall-node (dcom, ssh) to remote command Created: 01/Nov/11  Updated: 30/Nov/11

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

Type: Improvement Priority: Major
Reporter: Anissa Lam Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, the following commands are local command. GUI needs to be a remote command so we can add the feature in GUI.
install-node, install-node-ssh, install-node-dcom and the corresponding uninstall command.






[GLASSFISH-17520] restart-instance and stop-local-instance have inconsistent views of whether the instance is up causing devtest failure Created: 28/Oct/11  Updated: 19/Sep/14

Status: In Progress
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2_b06, 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude

 Description   

The admin devtests on the trunk and the 3.1.2 branch are current failing due to an issue with instance runtime status checking in the stop/start/restart commands. This problem has been there for sometime, but it was recently made visible by an change that cause the REST service to be started as part of instance startup.

Here is the problem. During instance startup, there is the following sequence of events:

1) AdminAdapter starts (which allows admin commands to be executed)
2) other services start (REST is now one of these)
3) the pid file is written.

The restart-domain command calls _get-runtime-info to determine if the server has started. So restart-domain thinks the server is started when (1) is completed.

The stop-local-instance command looks for the pid file. So it thinks the server is started when (3) is completed.

If (2) takes a relatively long time, it is possible for restart-domain to complete successfully, and then stop-local-instance to run immediately after it and think that the just started instance is still down. So stop-local-instance doesn't actually stop the instance.

To reproduce this problem, run this script on an instance:

asadmin restart-instance i1
asadmin restart-instance i1
asadmin stop-local-instance i1

It has to be in a script so that the commands are executed without a delay.

To fix this, the various commands need to be given a consistent view of when the server is up. One possibility is that _get-runtime-info needs to check if the pid file has been written before returning the pid.



 Comments   
Comment by scatari [ 07/Dec/11 ]

Please correct me if I am wrong, I do not see a customer use case here that has a quick stop followed by a restart. Does it need to be considered for 3.1.2?

Comment by Byron Nevins [ 14/Dec/11 ]

Can't reproduce.
Not a likely scenario for users.

Should investigate in 4.0
Should not fix for 3.1.2

Also not reproducible:

d:\gf\branches\3.1.2\admin>call asadmin restart-instance i1
i1 was restarted.
Command restart-instance executed successfully.
i1 was restarted.
Command restart-instance executed successfully.
The instance, i1, is stopped.
Command stop-instance executed successfully.

Comment by Byron Nevins [ 18/Feb/13 ]

confirmed. Easy to reproduce with the sample 3 command script...





[GLASSFISH-17345] LB doesn't work after stopping and starting cluster Created: 26/Sep/11  Updated: 19/Sep/14

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

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

MacOS


Attachments: File SimpleSessionDemo.war    
Tags: 3_1_x-exclude

 Description   

running in native mode with load balancer setup and deploy a web application. Web page comes up as expected. stop and then start the cluster and go to the web page and I get a 404.



 Comments   
Comment by Mahesh Kannan [ 26/Sep/11 ]

We have seen this behavior in native mode.

Steps to reproduce:

1. asadmin start-domain
2. deploy the attached SimpleSessionDemo.war
3. Access the app from browser (localhost:50080/SimpleSessionDemo/DemoServlet)
(The above works)
4. asadmin stop-cluster SimpleSessionDemo
5. asadmin start-cluster SimpleSessionDemo
6. Now try to access localhost:50080/SimpleSessionDemo/DemoServlet. THIS FAILS

Comment by prasads [ 18/Feb/13 ]

Moving this to 4.0.1 since the LB support is not available in 4.0





[GLASSFISH-20798] redeployment of an already deployed application resets the deployment order to 100 Created: 05/Sep/13  Updated: 05/Sep/13

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

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


 Description   

using the asadmin command to redeploy an application causes the deployment order value to be reset to the default.

I think it should retain the already set value unless a new value is specified.






[GLASSFISH-20935] When target a JMS resource to a cluster, should enforce no Node of any instances in the cluster has "localhost" as 'Node Host' Created: 18/Dec/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2, 3.1.2.2, 4.0
Fix Version/s: 4.1

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


 Description   

GlassFish JMS module forms MQ conventional cluster by taking 'Node Host' from each GlassFish instance's Node for imq.cluster.brokerlist and imq.cluster.masterbroker. Therefore the 'Node Host' of each GlassFish Node of the instances must not set to 'localhost' or else MQ conventional cluster may not be formed because 'localhost' can not represent the Node system's address on another system. This is especially important since the GlassFish default Node 'localhost-domain1' has its 'Node Host' set to 'localhost' by default which has often caused, as reported by GlassFish users, MQ cluster establishment problem on GlassFish cluster start up






[GLASSFISH-20921] Password from passwords file provided for create-password-alias command with --pass