[GLASSFISH-15261] cannot launch Admin Console: javax.servlet.ServletException: thrown in browser. Created: 17/Dec/10  Updated: 21/Feb/11  Resolved: 18/Dec/10

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b34

Type: Bug Priority: Blocker
Reporter: shaline Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris Sparc
Browser : firefox 3.6


Attachments: Text File server.log    
Tags: 3_1-approved, 3_1-verified

 Description   

Build Used : latest GF nightly dated b34_12/17.

Installed the latest GF nightly using the latest-ogs.zip bundle, and started the domain. Launched the Admin Console, using http://hostname:4848.
The below Exception is shown in the browser:

HTTP Status 500 -
type Exception report
message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'treeForm'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'treeForm'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.NullPointerException

note The full stack traces of the exception and its root causes are available in the Oracle GlassFish Server 3.1 logs.

Oracle GlassFish Server 3.1

server.log has the below Exception:

[#|2010-12-17T15:20:39.931-0800|SEVERE|oracle-glassfish3.1|com.sun.jersey.spi.co
ntainer.ContainerResponse|_ThreadID=15;_ThreadName=Thread-1;|The RuntimeExceptio
n could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
at org.glassfish.admin.rest.ResourceUtil.getParamMetaData(ResourceUtil.j
ava:441)
at org.glassfish.admin.rest.ResourceUtil.getMethodMetaData(ResourceUtil.
java:256)
at org.glassfish.admin.rest.ResourceUtil.getMethodMetaData(ResourceUtil.
java:236)
at org.glassfish.admin.rest.resources.TemplateListOfResource.getMethodMe
taData(TemplateListOfResource.java:360)
at org.glassfish.admin.rest.resources.TemplateListOfResource.buildAction
ReportResult(TemplateListOfResource.java:286)
at org.glassfish.admin.rest.resources.TemplateListOfResource.get(Templat
eListOfResource.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMeth
odDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchPr
ovider.java:186)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDi
spatcher.dispatch(ResourceJavaMethodDispatcher.java:70)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethod
Rule.java:279)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocator
Rule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHa
ndPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocator
Rule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHa
ndPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(Resourc
eClassRule.java:86)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHa
ndPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(R
ootResourceClassesRule.java:74)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequ
est(WebApplicationImpl.java:1347)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequ
est(WebApplicationImpl.java:1279)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleReque
st(WebApplicationImpl.java:1229)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleReque
st(WebApplicationImpl.java:1219)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._servic
e(GrizzlyContainer.java:180)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service
(GrizzlyContainer.java:145)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java
:180)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java
:168)

at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java
:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(Container
Mapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:8
17)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFil
ter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultPro
tocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java
:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextT
ask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.
java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadP
ool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool
.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2010-12-17T15:20:39.950-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingu
i|_ThreadID=15;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoin
t = 'http://localhost:4848/management/domain/configs/config.json'; attrs = '{}'|
#]



 Comments   
Comment by Anissa Lam [ 17/Dec/10 ]

Does this happen consistently ?
If GUI can't launch, QL will fail too. I have the latest workspace, but i am not seeing this. Shing Wai mentioned he saw this occasionally.

The NPE is from REST, and it is a valid request
http://localhost:4848/management/domain/configs/config.json';

Transfer to REST for investigation.

Comment by Anissa Lam [ 17/Dec/10 ]

Please attache server.log

Comment by shaline [ 17/Dec/10 ]

Attached the server.log
Used the bundle latest-ogs.zip and was able to reproduce this consistenly.
even deleted and recreated a new domain, and saw the same issue with the new domain as well.

Comment by Anissa Lam [ 17/Dec/10 ]

With the 12/17 nightly build for OGS and OpenSource version, I can reproduce the problem consistently on my Mac.
I can also reproduce this after i updated my workspace.
With Mitesh patch jar that gives more debug info, I am seeing the following:

[#|2010-12-17T19:47:43.082-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|*****Got model as:null commandName:create-config|#]

[#|2010-12-17T19:47:43.083-0800|SEVERE|oracle-glassfish3.1|com.sun.jersey.spi.container.ContainerResponse|_ThreadID=17;_ThreadName=Thread-1;|The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
at org.glassfish.admin.rest.ResourceUtil.getParamMetaData(ResourceUtil.java:442)
at org.glassfish.admin.rest.ResourceUtil.getMethodMetaData(ResourceUtil.java:256)

The create-config call is very suspicious.
This is related to the checkin from Bhaki for GLASSFISH-15214

The "create-config" command is removed.
Diffs:
------
Index: trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java
===================================================================
— trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java (revision 43911)
+++ trunk/v3/admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java (revision 43912)
@@ -65,7 +65,7 @@

  • </pre>
  • <p/> <p/> <p/> Objects of the following type(s) are allowed in the list {@link Config }

    */

  • @Create(value="create-config", i18n=@I18n("create.config.command"))
    +
    @Element(required=true)
    List<Config> getConfig();

I looked at the REST source code, in ResourcesGeneratorBase.java, it has:

put("ListConfig", "create-config");

It probably didn't realize "create-config" is being removed and thus the problem.

Comment by Anissa Lam [ 17/Dec/10 ]

I have tried to add back create-config, but make that a hidden command, and changed REST code to refer to the hidden command, everything works.

Thats the only solution i can think of now, maybe the REST team knows how to do ListConfig without create-config at all.

Here is the diff to solve the problem, and make GUI working again.
I have tested GUI manually, and also run QL test.
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 127, Failures: 0, Skips: 0
[echo] [testng] ===============================================

~/Awork/V3/NOW/v3 757) svn diff admin
Index: admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java
===================================================================
— admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java (revision 43930)
+++ admin/config-api/src/main/java/com/sun/enterprise/config/serverbeans/Configs.java (working copy)
@@ -65,7 +65,7 @@

  • </pre>
  • <p/> <p/> <p/> Objects of the following type(s) are allowed in the list {@link Config }

    */
    -
    + @Create(value="_create-config", i18n=@I18n("create.config.command"))
    @Element(required=true)
    List<Config> getConfig();

Index: admin/rest/src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java
===================================================================
— admin/rest/src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java (revision 43930)
+++ admin/rest/src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java (working copy)
@@ -514,7 +514,7 @@
put("ListAuditModule", "create-audit-module");
put("ListAuthRealm", "create-auth-realm");
put("ListCluster", "create-cluster");

  • put("ListConfig", "create-config");
    + put("ListConfig", "_create-config");
    put("ListConnectorConnectionPool", "create-connector-connection-pool");
    put("ListConnectorResource", "create-connector-resource");
    put("ListCustomResource", "create-custom-resource");
    @@ -565,4 +565,4 @@
    put("UserGroup",new CollectionLeafMetaData("_create-user-group", "_delete-user-group", "User Group"));
    }};

If the REST team thinks this is fine, I will ask for approval and check in. Or, they may have a better fix. Either way, I want to ensure Monday nightly build will have GUI working.

Comment by Jason Lee [ 18/Dec/10 ]

Looks good to me.

Comment by ludo [ 18/Dec/10 ]

ok...
People changing CLI should test admin gui,
CLI is a public interface!!!
Who is using this hidden cli now? If noboby, it should be removed

Comment by Anissa Lam [ 18/Dec/10 ]

Since this is reviewed by REST team, I will start the 3.1 change process to have the above changed code checked in. This ensure GUI works starting on Sunday nightly build.
If there is preference to remove the hidden command, that will need to be done by admin and REST and ensure everything works fine again.

How bad is its impact? (Severity)
Severity 1. Blocking bug.

How often does it happen?
Whenever user wants to launch GUI.

Will many users see this problem? (Frequency)
Everyone.

How much effort is required to fix it? (Cost)
Several hours. svn diff is included in previous comment.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
The risk should be min. I searched through entire v3 and didn't see anywhere else referencing "create-config". This cannot be worst than GUI not able to launch at all. Ran QL and manually tested GUI.

Comment by Anissa Lam [ 18/Dec/10 ]

Fix checked in on 12/18. Should be available starting from 12/19 nightly build.

Comment by shaline [ 25/Jan/11 ]

Verified in promoted b38.





[GLASSFISH-15240] [BLOCKING] IIOP Connection Failure Created: 16/Dec/10  Updated: 20/Feb/11  Resolved: 21/Dec/10

Status: Closed
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

Type: Bug Priority: Blocker
Reporter: gopaljorapur Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File cart.ear    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15322 Code error in IiopFolbGmsClient durin... Closed
Tags: 3_1-approved, 3_1-blocking, 3_1-verified

 Description   

I am using Build 33

All IIOP Tests failed due to

INFO: DTX5019: Transaction Manager is ready. Using [com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate] as the delegate
Inside IC
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: agent1; port: 23702 vmcid: OMG minor code: 1 completed: No
at sun.reflect.GeneratedConstructorAccessor35.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513



 Comments   
Comment by Tim Quinn [ 16/Dec/10 ]

Gopal,

Can you point to a particular test that shows this problem?

Is this a client on one system trying to contact a server on another system?

Comment by Tim Quinn [ 16/Dec/10 ]

[from an e-mail from Gopal]

I will ask Gopal to attach the EAR to this issue.

Please find the attached app

Deploy:
/export/NovCVS/glassfish3/bin/asadmin --user admin deploy --retrieve /export/NovCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true /export/NovCVS/agentrepo/iiop/cart.ear

Appclient execution:
/export/NovCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701 -classpath /export/NovCVS/agentrepo//appclient/cartClient/cart-app-clientClient.jar -xml /export/NovCVS/agentrepo//appclient/sun-acc.xml cart.client.CartFailoverClient ICFailover Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 getResourceBundle
WARNING: Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager
Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 log
INFO: list[i] ==> hat2k1.us.oracle.com:23700
Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 getResourceBundle
WARNING: Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager
Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 log
INFO: list[i] ==> hat2k1.us.oracle.com:23701
Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 getResourceBundle
WARNING: Can not find resource bundle for this logger. class name that failed: org.glassfish.enterprise.iiop.impl.GlassFishORBManager
Dec 16, 2010 4:41:27 PM com.sun.logging.LogDomains$1 log
INFO: corbaloc url ==> iiop:1.2@hat2k1.us.oracle.com:23700,iiop:1.2@hat2k1.us.oracle.com:23701
Dec 16, 2010 4:42:04 PM com.sun.logging.LogDomains$1 log
INFO: DTX5019: Transaction Manager is ready. Using [com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate] as the delegate
Inside IC
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: agent1; port: 23704 vmcid: OMG minor code: 1 completed: No
at sun.reflect.GeneratedConstructorAccessor35.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy31.connectFailure(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:198)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:363)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
at com.sun.enterprise.naming.impl.SerialContext.narrowProvider(SerialContext.java:452)

Comment by Tim Quinn [ 17/Dec/10 ]

Attaching example EAR from Gopal.

Comment by Ken Cavanaugh [ 18/Dec/10 ]

svn revision 43648 included a fix to issue 14987 that modified the IiopFolbGmsClient.getClusterInstanceInfo method as follows:

private ClusterInstanceInfo getClusterInstanceInfo( Server server,
Config config ) {
fineLog( "getClusterInstanceInfo: server

{0}, config {1}",
server, config ) ;

final String name = server.getName() ;
fineLog( "getClusterInstanceInfo: name {0}

", name ) ;

final int weight = Integer.parseInt( server.getLbWeight() ) ;
fineLog( "getClusterInstanceInfo: weight

{0}", weight ) ;
// start here:
String hostName = null ;

String nodeName = server.getNodeRef() ;
Node node = null;
if (nodes Unable to render embedded object: File (= null) nodes.getNode(nodeName); // PROBLEM) not found.
if (node != null && node.isLocal()) {
try { hostName = InetAddress.getLocalHost().getHostName() ; } catch (UnknownHostException exc) {
fineLog( "getClusterInstanceInfo: caught exception for localhost lookup {0}

",
exc ) ;
}
} else if (nodes != null) {
if (node != null)

{ hostName = node.getNodeHost() ; }

}

if (hostName == null)

{ hostName = nodeName ; }

// end here
fineLog( "getClusterInstanceInfo: host

{0}", hostName ) ;

final IiopService iservice = config.getIiopService() ;
fineLog( "getClusterInstanceInfo: iservice {0}

", iservice ) ;

final List<IiopListener> listeners = iservice.getIiopListener() ;
fineLog( "getClusterInstanceInfo: listeners

{0}", listeners ) ;

final List<SocketInfo> sinfos = new ArrayList<SocketInfo>() ;
for (IiopListener il : listeners) { SocketInfo sinfo = new SocketInfo( il.getId(), hostName, resolvePort( server, il ) ) ; sinfos.add( sinfo ) ; }
fineLog( "getClusterInstanceInfo: sinfos {0}

", sinfos ) ;

final ClusterInstanceInfo result = new ClusterInstanceInfo( name, weight,
sinfos ) ;
fineLog( "getClusterInstanceInfo: result

{0}", result ) ;

return result ;
}


The problem is the line of code above with the PROBLEM! comment: it is clearly wrong, because it does not
assign the result of the getNode call to anything. This error results in hostName set
to nodeName, which is the name of the node agent, and useless in an IOR.

The fix is to rewrite the code between the start and end comments to be as follows:

final String nodeName = server.getNodeRef() ;
String hostName = nodeName ;
if (nodes != null) {
Node node = nodes.getNode( nodeName ) ;
if (node != null) {
if (node.isLocal()) {
try { hostName = InetAddress.getLocalHost().getHostName() ; } catch (UnknownHostException exc) {
fineLog( "getClusterInstanceInfo: caught exception for localhost lookup {0}

",
exc ) ;
}
} else

{ hostName = node.getNodeHost() ; }

}
}

With this change, 2 failover dev tests that were failing pass.

Comment by Ken Cavanaugh [ 21/Dec/10 ]

Fixed in GF rev 44021.

Comment by Ken Cavanaugh [ 24/Dec/10 ]

Please attach the sequence of commands used to create the cluster in the
failure case. I know this works with ssh (at least in my tests), so there
must be something different in how we set up clients. I have checked that the fix
I added in 44021 is still in the workspace. Given the 12/22 release date of
b34, it should contain 44021, but I cannot easily verify that.





[GLASSFISH-15092] Nucleus distribution is completely broken Created: 10/Dec/10  Updated: 30/Dec/10  Resolved: 30/Dec/10

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 3.1_b31
Fix Version/s: 3.1

Type: Bug Priority: Blocker
Reporter: Sanjeeb Sahoo Assignee: dochez
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-15095 Nucleus distribution is completely br... Resolved
depends on GLASSFISH-15222 Nucleus distribution is completely br... Resolved
depends on GLASSFISH-15093 Nucleus distribution is completely br... Resolved
depends on GLASSFISH-15094 Nucleus distribution is completely br... Resolved
depends on GLASSFISH-15192 Nucleus distribution is completely br... Closed

 Description   

I can't start nucleus distribution at all. I have so far found bugs in three different areas that need to be addressed. So, this is an umbrella bug which I will refer to from the more specific ones.



 Comments   
Comment by Nazrul [ 22/Dec/10 ]

This is an umbrella bug

Comment by Nazrul [ 30/Dec/10 ]

All related issues has been resolved.





[GLASSFISH-14827] Failover of RemoteObject stored in http session does not work Created: 19/Nov/10  Updated: 20/Feb/11  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: failover
Affects Version/s: 3.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Blocker
Reporter: gopaljorapur Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File server.log.instance101     Text File server.log.instance102     Text File server.log.instance103    
Issuezilla Id: 14,827
Tags: 3_1-verified

 Description   

I am using Build 30

The app stores EJB RemoteObject in http session and tries to retrieve the same
after injecting the failure on the instance that handled the initial request

I have attached the relevent logs



 Comments   
Comment by gopaljorapur [ 19/Nov/10 ]

Created an attachment (id=5551)
instance101 log

Comment by gopaljorapur [ 19/Nov/10 ]

Created an attachment (id=5552)
instance 102 log

Comment by gopaljorapur [ 19/Nov/10 ]

Created an attachment (id=5553)
instance 103 log

Comment by gopaljorapur [ 19/Nov/10 ]

session scope is Modified Attribute

Comment by Mahesh Kannan [ 07/Dec/10 ]

The reason for the failure is that initial version sent by the web container is -1 and hence the replication layer tosses away the replicated data. I have given a fix to Gopal and it has fixed this issue.

Will close the issue once we do the shoal integration

Comment by Mahesh Kannan [ 07/Dec/10 ]

I am marking this as a Blocker and I am going to close 14865 as this issue is the root cause of 14865.

14865 merely reports that the loadRequest timed out after failing to load the data within 3 sec.

Comment by Mahesh Kannan [ 14/Dec/10 ]

We integrated the new a shoal jar. The issue was that the first save coming from the web container was ignored by the shoal layer.





[GLASSFISH-14824] [BLOCKING]: b30 is not functioning Created: 19/Nov/10  Updated: 29/Nov/10  Resolved: 29/Nov/10

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Blocker
Reporter: zorro Assignee: Satish Kumar
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://aras2.us.oracle.com:8080/logs/gf31/gms/stress_b30_nov19/scenario_0001_Fri_Nov_19_15_42_39_PST_2010/


Issuezilla Id: 14,824

 Description   

Oracle GlassFish Server 3.1 (build 30)

This is a test stopper.

Installed das, and three nodes on separate machines.
GLASSFISH-1: admin GUI is not loading and is frozen with an empty screen.
GLASSFISH-2: Cluster nodes are not accessible.
das log shows:

[#|2010-11-19T15:13:10.201-0800|WARNING|oracle-glassfish3.1|java.util.prefs|_ThreadID=15;_ThreadName=Thread-1;|Couldn't
flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.|#]

All logs:
http://aras2.us.oracle.com:8080/logs/gf31/gms/stress_b30_nov19/scenario_0001_Fri_Nov_19_15_42_39_PST_2010/



 Comments   
Comment by zorro [ 19/Nov/10 ]

Installed b30 3 times and the product did not work.
The node's logs on machine the second and third machine show:
java.lang.Exception
at
com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:233)
....
javax.resource.NotSupportedException: MQRA:EC:Error creating Remote Message
Consumer:
...

Comment by kumara [ 19/Nov/10 ]

Likely a configuration issue. -> jms because the exception is during auto-creation of topics.

The admin console issue is being addressed separately. The update check is going to be removed from
initialization of admin console to avoid situations like this. (The machine was moved to a different
network and now requires a HTTP proxy to connect to Internet and therefore the timeout message in
DAS log file).

Caused by: com.sun.messaging.jms.JMSException: [CREATE_DESTINATION_REPLY(35)] [C4036]: A broker
error occurred. :[503] [B4286]: [Thread-jms[0]]Auto-creation of destination richAppTopic is not allowed
because service jms is currently in restricted service mode: Persistent store has not been synchronized
with master broker [broker2(mq://10.133.184.122:27676/)] user=guest,
broker=localhost:27676(41939)
at
com.sun.messaging.jmq.jmsclient.ProtocolHandler.throwServerErrorException(ProtocolHandler.java:407
9)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.createDestination(ProtocolHandler.java:1462)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.createDestination(ProtocolHandler.java:1396)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.addInterest(ProtocolHandler.java:2234)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.addInterest(ProtocolHandler.java:2223)
at com.sun.messaging.jmq.jmsclient.WriteChannel.addInterest(WriteChannel.java:101)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.addInterest(ConnectionImpl.java:1378)
at com.sun.messaging.jmq.jmsclient.Consumer.registerInterest(Consumer.java:153)
at
com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.addInterest(MessageConsumerImpl.java:184)
at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.init(MessageConsumerImpl.java:165)
at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.<init>
(MessageConsumerImpl.java:123)
at com.sun.messaging.jmq.jmsclient.TopicSubscriberImpl.<init>(TopicSubscriberImpl.java:110)
at
com.sun.messaging.jmq.jmsclient.UnifiedSessionImpl.createSubscriber(UnifiedSessionImpl.java:319)
at
com.sun.messaging.jmq.jmsclient.UnifiedSessionImpl.createConsumer(UnifiedSessionImpl.java:637)
at
com.sun.messaging.jmq.jmsclient.UnifiedSessionImpl.createConsumer(UnifiedSessionImpl.java:583)
at
com.sun.messaging.jms.ra.EndpointConsumer.createRemoteMessageConsumer(EndpointConsumer.java:
548)
... 39 more

Comment by Satish Kumar [ 29/Nov/10 ]

Duplicate of 14788





[GLASSFISH-14797] Realm: error when adding a user to a realm in a new config Created: 18/Nov/10  Updated: 17/Feb/11  Due: 04/Feb/11  Resolved: 02/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1_b41

Type: Bug Priority: Blocker
Reporter: shaline Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File 14797-2.diff     File 14797.diff    
Issue Links:
Dependency
depends on GLASSFISH-14860 create-file-user should allow specify... Reopened
Duplicate
is duplicated by GLASSFISH-15821 c1-config/Security/Realms/file, Creat... Resolved
Issuezilla Id: 14,797
Tags: 3_1-verified

 Description   

build used : GF V3.1 nightly dated 11/18

Create a new config by copying from default-config.
create a new file realm under new-config/security/realms node.
Select the new file realm and click "Manage Users" button.
We see an error as below:
"File realm new-realm does not exist"

server.log has the below error:
[#|2010-11-18T19:47:09.370-0800|INFO|glassfish3.1|javax.enterprise.system.core.s
ecurity.com.sun.enterprise.security.auth.realm|_ThreadID=15;_ThreadName=Thread-1
;|SEC1115: Realm [new-realm] of classtype [com.sun.enterprise.security.auth.
realm.file.FileRealm] successfully created.|#]

[#|2010-11-18T19:47:14.168-0800|SEVERE|glassfish3.1|org.glassfish.admingui|_Thre
adID=15;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'ht
tp://localhost:4848/management/domain/configs/config/new-config/security-service
/auth-realm/new-realm/list-users'; attrs = '{}'; RestResponse:

{"message":"F ile realm new-realm does not exist","command":"list-file-users AdminCommand" ,"exit_code":"FAILURE"}

"|#]

[#|2010-11-18T19:47:14.189-0800|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=
Thread-1;|***** users = |#]



 Comments   
Comment by srinik76 [ 28/Nov/10 ]

The error happens in the REST GUI Interface also. REST URL is mentioned in the server log attached as part of bug description

Comment by Jason Lee [ 01/Dec/10 ]

Fix committed (r43284)

Comment by shaline [ 27/Jan/11 ]

This issue exists in promoted b39.
Create a config by copying from default-config.
Create standalone instance referring this config, and start the instance. ( this issue can be seen only when the instance is running).
--Under the new-config/security/Realms/ create a new file realm. --Provide the keyfile as $

{com.sun.aas.instanceRoot}

/config/keyfile
--Select the created keyfile and try to add a user using "Manage Users" button.
Add username, password. click OK.
The below Error gets displayed in the console.

"An error has occurred
Check server log for more information."

Server.log does not have exceptions, but the below message us seen:
[#|2011-01-27T12:56:37.908-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=87;_ThreadName=Thread-;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-01-27T12:56:37.924-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=87;_ThreadName=Thread-;|SEC1117: Realm [file] successfully updated.|#]

[#|2011-01-27T12:56:38.000-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=21;_ThreadName=Thread-1;|Add user failed. parent=http://localhost:4
848/management/domain/configs/config/local-config/security-service/auth-realm/file/create-user?target=local-config; attrs =

{userpassword=adminadmin, use rname=newadmin, target=local-config, authrealmname=file, groups=[]}

|#]

Comment by Anissa Lam [ 27/Jan/11 ]

As you mentioned, this occurs only when the instance is running. There maybe some restriction for running server, i am not sure. But there has been discussion about user in fileRealm.
I see that we are passing info correctly to backend.
Requesting Kumar to evaluate.

Comment by shaline [ 27/Jan/11 ]

The User actually gets created even with the Error shown above. Select the new file realm in the left tree node, and click the manage Users button. Notice that the user is created.
When we try to delete the created user , we get the below error in GUI Console.
An error has occurred
DELETE http://localhost:4848/management/domain/configs/config/remote-ins-config/security-service/auth-realm/newfilerealm/delete-user?target=remote-ins-config&name=user1 returned a response status of 500

server.log has the below message:

[#|2011-01-27T17:05:49.445-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|
_ThreadID=31;_ThreadName=Thread-1;|Exception Occurred :DELETE http://localhost:4
848/management/domain/configs/config/remote-ins-config/security-service/
auth-realm/newfilerealm/delete-user?target=remote-ins-config&name=user1 returned a response status of 500|#]

Comment by Anissa Lam [ 27/Jan/11 ]

Here is what i tried.

  • create-instance
  • create- new file realm
  • add user1 to this new realm. FINE, no exception.
  • delete user2 ERROR in server.log
    [#|2011-01-27T17:51:19.298-0800|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=admin-thread-pool-4848(5);|Exception Occurred :DELETE http://localhost:4848/management/domain/configs/config/ABC-config/security-service/auth-realm/test/delete-user?target=ABC-config&name=user2 returned a response status of 500|#]

Again, the user is deleted. even though there is error.
The code is the same whether the server is running or not. I checked what we passed in is correct.
So, I still believe this is a security bug.

Comment by kumarjayanti [ 27/Jan/11 ]

someone please give me the exact steps : full details of the commands. Or should i use GUI to reproduce this ?. Has you tried to reproduce this problem with CLI ?.

Comment by Anissa Lam [ 27/Jan/11 ]

I don't see the problem when using CLI. However, I also see that the correct info is passed in. It will be nice if you can look at your end to see what maybe the problem.
I remember there are issues where CLI/GUI behaves differently and that is expected, like keyfile doesn't exist case.
I have put in the steps in the above comment, here it is again. Please use GUI for these steps.

1. create a standalone instance, with the default provided.
Instance name: ABC
Node: localhost-domain1
Configuration: default-config, select Copy.

2. go to ABC-config -> Security -> Realms
create a file realm, newRealm, specifying $

{com.sun.aas.instanceRoot}

/config/keyfile as the KeyFile

3. Add a user to this newRealm
So far no issue.

4. go to Standalone Instances tree node. Start the ABC instance

5. go to ABC-config -> Security -> Realms -> newRealm
click Manage User and create a new user.
You will see error, with the SEVERE error logged. But the user is created.

6. Now, try to delete this new user. Again, you will see error deleting, but the user is actually deleted.

Note that all these error occurs ONLY when the instance is running.

Thanks for looking into this.

Comment by kumarjayanti [ 27/Jan/11 ]

Ok here are my observations....

1. as shaline points out the GUI reports errors only when the instance is UP and running. When the instance is not running this is not an issue.

2. i goto new-realm under new-config (with instance running) and say manage-users and create a user test.

GUI : An error has occured, check sever.log for more inof

DAS Server.log :
-------

[#|2011-01-28T09:53:56.779+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=65;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T09:53:56.798+0530|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=32;_ThreadName=Thread-1;|Add user failed. parent=http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/create-user?target=new-config; attrs =

{userpassword=test, username=test, target=new-config, authrealmname=new-realm, groups=[]}

|#]
----------

Instance In1 log :
------------
Nothing...
--------------

cat keyfile : (test user is there and this matches the backend log on DAS above)
test;

{SSHA256}

8m3So6x/nS+eZjP2uMO3sL/RjNvWFnJR65p2kwOe8WbUFGPzaJ9E7A==;

3. In GUI go back to Realms under new-config. Select new-realm again and click manage-users
The user test appears correctly there.

4. In GUI delete the user test now:

GUI : An error has occurred
DELETE http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/delete-user?target=new-config&name=test returned a response status of 500

DAS server.log :
-------------

[#|2011-01-28T10:00:04.391+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=99;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:00:04.417+0530|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=29;_ThreadName=Thread-1;|Exception Occurred :DELETE http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/delete-user?target=new-config&name=test returned a response status of 500|#]
-------------

Instance in1 sever.log :
-------------
Nothing..
-------------

cat keyfile : (user test is gone from the backend)
<EMPTY>

5. In GUI go back to Realms under new-config, select new-realm again and click manage-users
GUI : the user test is no longer present its gone.

So how can this be a backend security error ?.

I tried CLI commands for the same and here is the output (with instance in1 running) :

./asadmin create-file-user --target new-config --authrealmname new-realm test1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

./asadmin list-file-users --authrealmname new-realm new-config
test1
Command list-file-users executed successfully.

./asadmin delete-file-user --target new-config --authrealmname new-realm test1
Command delete-file-user executed successfully.

./asadmin list-file-users --authrealmname new-realm new-config
Command list-file-users executed successfully.

And the server.log shows no backend errors :

DAS Server.log
------------
[#|2011-01-28T10:04:21.070+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=65;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:04:39.378+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=98;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]
------------

Instance in1 server.log
-------------
[#|2011-01-28T10:04:21.092+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=64;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:04:39.435+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=62;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]
-------------

Comment by Anissa Lam [ 27/Jan/11 ]

Thanks. Its just we had problem before regarding creating user and CLI and GUI behaves differently, so would like you to double check.

Assign to Jason to see why we are getting error when backend is fine.

Comment by kumarjayanti [ 27/Jan/11 ]

In Summary : if we go back in the GUI by selecting the Realms (under new-config) on the left-pane and then select new-realm and click on manage-users, it shows the right values. And not something erroneous/random. If the previous operation was to create the user "test" then it would show the user "test" and if the previous operation was to delete the user "test" it would show that there are no more users.

So it is clear to me that this is not a backend error.

It also appears to me that the GUI is executing the right command at the backend. However i see one difference. When i excecute the commands CLI, the command seems to have been replicated in the instance in1 log. However when doing the same operations from GUI Nothing ever appears in the instance in1 logs. Not sure why this difference.

Comment by kumarjayanti [ 27/Jan/11 ]

I tried to see if there is some interference with the shared domains/domain1/config/keyfile and so i changed the keyfile for new-realm to point to /tmp/keyfile and created the file.

Then repeated the same steps and it shows the same behavior as before.

Comment by kumara [ 27/Jan/11 ]

When you fix this, please be sure to remove printing of password from the log message. Passwords must not be written to log files in clear.

Comment by Jason Lee [ 31/Jan/11 ]

I don't think is a REST or Console issue. When the Console issues the REST request to create the user, ultimately, create-file-user is called (the actual call is at ResourceUtil.java:202, though the params are set up earlier in the call stack):

CommandRunner cr = habitat.getComponent(CommandRunner.class);
RestActionReporter ar = new RestActionReporter();

cr.getCommandInvocation(commandName, ar).parameters(parameters).execute();
return ar;

commandName = "create-file-user"
parameters =

{username: [user2] userpassword: [user2] target: [in1-config] authrealmname: [newRealm] }

The topMessage in the ActionReporter says "An error occurred during replication" and the exitCode is "FAILURE". This looks like a backend issue to me. I don't know why we don't see this from the command line (even with AS_DEBUG set to true), but the AdminCommand is clearly returning an error condition to the REST layer, which we dutifully relay. It's possible, I guess, that the console is sending bad/incorrect data, but rebuilding the CLI command from the data above works, so I'd be surprised to see that be the case.

Comment by Jason Lee [ 01/Feb/11 ]

Reassigning to security to evaluate the issue documented above.

Comment by kumarjayanti [ 02/Feb/11 ]

The bug is marked a blocker because you are logging passwords when the exception occurs. Abhijit noticed this. So you should fix that, and in the mean time nithya will try to debug the issue. Please reassign to us after you fix the logging issue.

Comment by kumarjayanti [ 02/Feb/11 ]

Nithya has debugged with debugger breakpoints today and it is clear that the command replication is failing. The command never reaches the instance for execution when the GUI path is used. However when the same thing is run by CLI command-line the debugger breakpoint is hit on the instance.

So it appears the Replication API is being invoked incorrectly by the REST Service code.

---------
This also confirms my observation (posted : 27/Jan/11 08:54 PM) : However i see one difference. When i excecute the commands CLI, the command seems to have been replicated in the instance in1 log. However when doing the same operations from GUI Nothing ever appears in the instance in1 logs. Not sure why this difference.
---------

Comment by Jason Lee [ 02/Feb/11 ]

This seems to be a GUI issue. Changing component and reclaiming ownership. Fix and dev test coming shortly for review.

Comment by Jason Lee [ 02/Feb/11 ]

Thanks to Tom, I think we've tracked this down to a Console issue. Fix (and test) attached.

How bad is its impact? (Severity)
Moderate. Administrators are unable to add new users to realms associated with standalone instances (or clusters, I would guess).

How often does it happen? (Frequency)
Every time

How much effort is required to fix it? (Cost)
Moderate. Most of the time was spent in diagnosing. The actual fix is very simple.

What is the risk of fixing it? (Risk)
Very little, as this affects just this one page.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes. The CLI works as expected.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
Unknown, but quite likely for quite some time.

Do regression tests exist for this issue?

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
GUI Dev Tests

When will a tested fix be ready for integration?
The fix is in a diff attached to this issue. The patch also contains a new test to catch regressions.

Comment by Anissa Lam [ 02/Feb/11 ]

========
In line# 370:
RestResponse response = RestUtil.delete(endpoint, attrs);

I see that RestUtil.delete() is calling
checkStatusForSuccess(cr);
which throws RuntimeException unless it succeeds. So, you will never get to the next if() statement.
You probably need to catch that exception.
(Ideally, Everything should really go through RestUtil.restRequest() which parse the response, and return failure/Warning. But we don't want to change that now.)

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

Sounds like you remove the authrealmname in the original code, but when you add it back, it is commented out.
Is this the intend ?

+// attrs.put("authrealmname", realmName);

Comment by Jason Lee [ 02/Feb/11 ]

That commented out line actually needs to be removed. REST adds that based on the URL.

WRT to RestUtil.delete(), I have no comment on that. The only reason there's a change there is that NetBeans cleaned up the logging code, a change we can probably live without.

Comment by Anissa Lam [ 02/Feb/11 ]

I still prefer catching the Exception in the delete() case, otherwise,GUI screen will be messed up with exception showing, if there is any error in the deletion.

Please add the comment that REST adds authRealmName and we shouldn't specify it in the code.

Comment by Jason Lee [ 02/Feb/11 ]

I've attached another patch with some cleanups.

Comment by Anissa Lam [ 02/Feb/11 ]

ok. change looks good, although you didn't add the comment
thanks.

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Jason Lee [ 02/Feb/11 ]

I forgot about that part. If we add it here, though, we'd probably need to make similar comments on every other REST endpoint to be consistent, right? I don't think sending it is a problem, but it's unnecessary, so I cleaned it up.

Comment by Jason Lee [ 02/Feb/11 ]

Fix committed to trunk (r44835) and branch (r44836).

Comment by shaline [ 17/Feb/11 ]

Verified in promoted b43.





[GLASSFISH-8182] <BLOCKING>NoClassDefFoundError: javax/net/ssl/SSLContext error on server start Created: 05/May/09  Updated: 08/May/09  Resolved: 08/May/09

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: V3

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

Operating System: All
Platform: Linux


Issuezilla Id: 8,182

 Description   

GV3 Build :
http://gf-hudson.sfbay/hudson/view/GFv3%20Preview/job/gf-preview-build-nightly/lastSuccessfulBuild/artifact/bundles/glassfish-v3-b47a-05_04_2009.zip

No Server start i am getting the following error in server log, and all the ssl
apps are failing to run.

Server log
==========
[#|2009-05-05T15:50:29.799+0530|INFO|glassfish|org.jvnet.hk2.osgiadapter|_ThreadID=14;_ThreadName=Thread-1;org.glassfish.connectors.runtime
[47];|Started bundle org.glassfish.connectors.runtime [47]|#]

[#|2009-05-05T15:50:29.869+0530|INFO|glassfish|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=14;_ThreadName=Thread-1;|Started
JMXConnector, JMXService URL =
service:jmx:rmi:///jndi/rmi://dhcp-cblr03-229-164.India.Sun.COM:8686/jmxrmi|#]

[#|2009-05-05T15:50:29.915+0530|INFO|glassfish|null|_ThreadID=12;_ThreadName=Thread-1;|Listening
on port 8181|#]

[#|2009-05-05T15:50:29.919+0530|INFO|glassfish|null|_ThreadID=15;_ThreadName=Thread-1;|javax/net/ssl/SSLContext
java.lang.NoClassDefFoundError: javax/net/ssl/SSLContext
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at
com.sun.grizzly.util.IntrospectionUtils.findMethods(IntrospectionUtils.java:868)
at
com.sun.grizzly.util.IntrospectionUtils.setProperty(IntrospectionUtils.java:305)
at
com.sun.grizzly.http.SelectorThread.configureProperties(SelectorThread.java:1097)
at
com.sun.grizzly.http.SelectorThread.initEndpoint(SelectorThread.java:1047)
at
com.sun.enterprise.v3.services.impl.GrizzlyProxy$1.run(GrizzlyProxy.java:195)
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLContext
at
org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:564)
at
org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:58)
at
org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 9 more

#]

[#|2009-05-05T15:50:29.920+0530|INFO|glassfish|null|_ThreadID=12;_ThreadName=Thread-1;|Listening
on port 4848|#]

[#|2009-05-05T15:50:29.972+0530|INFO|glassfish|org.jvnet.hk2.osgiadapter|_ThreadID=12;_ThreadName=Thread-1;org.glassfish.deployment.common
[21];|Started bundle org.glassfish.deployment.common [21]|#]

[#|2009-05-05T15:50:30.018+0530|INFO|glassfish|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=12;_ThreadName=Thread-1;|GlassFish
v3 startup time : Felix(1718ms) startup services(821ms) total(2539ms)|#]

[#|2009-05-05T15:51:25.692+0530|INFO|glassfish|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=16;_ThreadName=Thread-1;|[AutoDeploy]
Selecting file
/space/tango-branches/tango-2.0.a/glassfishv3/glassfish/domains/domain1/autodeploy/jaxws-s1.war
for autodeployment.|#]

[#|2009-05-05T15:51:25.695+0530|INFO|glassfish|org.jvnet.hk2.osgiadapter|_ThreadID=16;_ThreadName=Thread-1;org.glassfish.deployment.admin
[5];|Started bundle org.glassfish.deployment.admin [5]|#]

[#|2009-05-05T15:51:25.783+0530|INFO|glassfish|org.jvnet.hk2.osgiadapter|_ThreadID=16;_ThreadName=Thread-1;org.glassfish.web.beans-integration
[122];|Started bundle org.glassfish.web.beans-integration [122]|#]



 Comments   
Comment by anand_mishra [ 05/May/09 ]

this problem occur when i enabled network-listener for port="8181"

<network-listener port="8181" enabled="true" protocol="http-listener-2"
transport="tcp" name="http-listener-2"
thread-pool="http-thread-pool"></network-listener>

Comment by sonialiu [ 05/May/09 ]

I installed 05/04 nightly build (from
http://gf-hudson.sfbay/hudson/job/preview-nightly/lastSuccessfulBuild/artifact/bundles),
When I enabled ssl for http-listener-2 (port 8181, set "enabled=true"), startup
server failed. This bug blocked all the SQE ssl tests. Upgraded the bug to P1.

Comment by sonialiu [ 05/May/09 ]

add cc

Comment by sonialiu [ 06/May/09 ]

I have verified that the bug is fixed in build b47a.

Comment by anand_mishra [ 08/May/09 ]

Issue is fixed in b47a-05_06_2009.

Comment by anand_mishra [ 08/May/09 ]

closing this issue as it is fixed in v3-b47a-05_06_2009 build





[GLASSFISH-8179] Deployment error in hello-singleton-ejb webservices sample Created: 05/May/09  Updated: 27/Nov/10  Resolved: 14/May/09

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Blocker
Reporter: anand_mishra Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 8,179

 Description   

Sample used : samples/javaee6/webservices/hello-singleton-ejb
Glassfish build :
http://gf-hudson.sfbay.sun.com/hudson/view/GFv3%20Preview/job/gf-preview-build-nightly/lastSuccessfulBuild/artifact/bundles/latest-sdk-unix.sh

Server Log
==========
[#|2009-05-05T13:24:17.887+0530|INFO|glassfish|org.jvnet.hk2.osgiadapter|_ThreadID=15;_ThreadName=Thread-1;org.glassfish.extras.grizzly-container
[170];|Started bundle org.glassfish.extras.grizzly-container [170]|#]

[#|2009-05-05T13:24:17.892+0530|INFO|glassfish|null|_ThreadID=15;_ThreadName=Thread-1;|logger
= java.util.logging.Logger@10eeb26|#]

[#|2009-05-05T13:24:17.895+0530|SEVERE|glassfish|com.sun.enterprise.v3.admin.CommandRunnerImpl|_ThreadID=15;_ThreadName=Thread-1;|Exception
in command execution : com.sun.enterprise.module.ResolveError: Failed to start
org.glassfish.webservices.jsr109-impl(JSR-109 implementation to deploy
Metro):3.0.0.Preview-SNAPSHOT
com.sun.enterprise.module.ResolveError: Failed to start
org.glassfish.webservices.jsr109-impl(JSR-109 implementation to deploy
Metro):3.0.0.Preview-SNAPSHOT
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:143)
at
org.jvnet.hk2.osgiadapter.OSGiModuleImpl$1$1$1.loadClass(OSGiModuleImpl.java:280)
at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:91)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:106)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at org.jvnet.hk2.component.Habitat$1.get(Habitat.java:252)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at java.util.AbstractCollection.toArray(AbstractCollection.java:124)
at java.util.ArrayList.addAll(ArrayList.java:472)
at
com.sun.enterprise.v3.server.SnifferManagerImpl.getSniffers(SnifferManagerImpl.java:85)
at
com.sun.enterprise.v3.server.SnifferManagerImpl.hasNoSniffers(SnifferManagerImpl.java:112)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:151)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:410)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:425)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:560)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:137)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:313)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:180)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:202)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:740)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:631)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:900)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:162)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle
96: package; (package=javax.xml.ws.spi.http)
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3090)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1439)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:774)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:137)
... 34 more

#]


 Comments   
Comment by hsprabhu [ 05/May/09 ]

Blocking us from testing the metro samples.

Comment by bsnaresh [ 05/May/09 ]

The same issue is seen for the Jersey/REST sample message-board-war.

Comment by hsprabhu [ 05/May/09 ]

Re-assigning to Bhakti who is the metro samples author

Comment by Bhakti Mehta [ 05/May/09 ]

I am having problems installing the javaee 6 sdk on both solaris and mac
http://gf-hudson.sfbay.sun.com/hudson/view/GFv3%20Preview/job/gf-preview-build-nightly/lastSuccessfulBuild/artifact/bundles/latest-sdk-unix.sh
for this issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=8179

I suspect webservices-api and jaxb-api still as pack.gz files.
Terena says she can install on linux box but the server does not start up
I do not think this will be a webservices issue but general isues with sdk

Comment by Bhakti Mehta [ 05/May/09 ]

I think there are multiple issues in latest sdk.
Terena says she can install Java EE SDK 6 on Linux with no problems but
the server won't start up at all. Reassigning to Sathyan

Comment by Bhakti Mehta [ 05/May/09 ]

Added to cc

Comment by Snjezana Sevo-Zenzerovic [ 05/May/09 ]

Taking ownership...

Comment by Snjezana Sevo-Zenzerovic [ 05/May/09 ]

Installer configurator class has not been modified to uncompress jar files which
were recently moved into modules/endorsed directory and this cause server
startup failure. Issue is fixed now.

Comment by anand_mishra [ 14/May/09 ]

issue no longer appearing, closing this now.





[GLASSFISH-10568] ql: failed to deploy jsfastrologer.war on AIX. Created: 25/Oct/09  Updated: 20/Apr/11  Resolved: 07/Oct/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1_b01
Fix Version/s: 3.1.1

Type: Bug Priority: Blocker
Reporter: sherryshen Assignee: kchung
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: AIX
Platform: All


Attachments: Text File server.log.jsfastrologer    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16364 OSGI issue shown by Bean validator on... Resolved
Issuezilla Id: 10,568
Status Whiteboard:

v3_exclude

Tags: 3_1_1-approved

 Description   

With the fix of
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10545
it is OK to deploy hellojsp.war, but next failure is at
deploying jsfastrologer.war

The ql run is w.r.t. gf-trunk-build-continuous,
around #2995, Oct. 25, 2009. The build has the fix
33289. Issue #10545: Add org.glassfish.apf.context to Import-Package
explicitly to solve class loading issue on IBM JDK

The hudson run can be viewed at
http://sqe-hudson.sfbay.sun.com:8080/hudson/job/sherry-ql-aix/3/

deploy-v3-impl:
[echo] deploying hellojsp.war
deploy-v3-impl-unix:
[exec] Application deployed successfully with name hellojsp.war
.....
[exec] Command deploy executed successfully.
deploy-v3-impl:
[echo]
deploy-v3-impl-unix:
[exec] com.sun.enterprise.admin.cli.CommandException:
remote failure: Exception while loading the app :
java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException:
java.lang.IllegalStateException:
Application was not properly initialized at startup,
could not find Factory:
javax.faces.context.FacesContextFactory
[exec] Command deploy failed.
[exec] Result: 1
....
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 110, Failures: 73, Skips: 29
[echo] [testng] Configuration Failures: 1, Skips: 0
[echo] [testng] ===============================================



 Comments   
Comment by sherryshen [ 25/Oct/09 ]

added line for war file, which was mis-copied before.

deploy-v3-impl:
[echo] deploying jsfastrologer.war
deploy-v3-impl-unix:
[exec] com.sun.enterprise.admin.cli.CommandException:
remote failure: Exception while loading the app :
java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException:
java.lang.IllegalStateException:
Application was not properly initialized at startup,
could not find Factory:
javax.faces.context.FacesContextFactory
[exec] Command deploy failed.
[exec] Result: 1

Comment by Sanjeeb Sahoo [ 26/Oct/09 ]

Next time, attach server.log.
Reassigning to jsf team to do initial investigation.

Comment by Sanjeeb Sahoo [ 26/Oct/09 ]

added cc

Comment by Ryan Lubke [ 26/Oct/09 ]

Please attach the server log for the failed run.

Thanks.

Comment by sherryshen [ 26/Oct/09 ]

Created an attachment (id=3624)
server.log for deploying jsfastrologer.war

Comment by sherryshen [ 26/Oct/09 ]

The steps and env to get server.log.jsfastrologer.
-bash-3.00$ ./asadmin start-domain
Waiting for DAS to start ................
Started domain: domain1
Domain location:
/export/hudson/workspace/sherry-ql-aix/glassfishv3/glassfish/domains/domain1
Log file:
/export/hudson/workspace/sherry-ql-aix/glassfishv3/glassfish/domains/domain1/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.
-bash-3.00$ asadmin deploy
/export/hudson/workspace/sherry-ql-aix/quicklook/dist/jsftest/jsfastrologer.war
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
loading the app : java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start: org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException: java.lang.IllegalStateException:
Application was not properly initialized at startup, could not find Factory:
javax.faces.context.FacesContextFactory
Command deploy failed.
-bash-3.00$-bash-3.00$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr5-20090529_04(SR5))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc-32
jvmap3260sr5-20090519_35743 (JIT enabled, AOT enabled)
J9VM - 20090519_035743_bHdSMr
JIT - r9_20090518_2017
GC - 20090417_AA)
JCL - 20090529_01
-bash-3.00$

Comment by Ryan Lubke [ 26/Oct/09 ]

JSF is not being initialized (no log message indicating it's being bootstrapped)
when the application is deployed. This means that our ServletContextListener
isn't being invoked by the web container.

To confirm, what build of v3 is this?

Comment by Ryan Lubke [ 26/Oct/09 ]

I'm able to reproduce the issue on aixas13.sfbay.sun.com using the web bundle
from the GF continuous build [1].

I put some break points within the web container where the container invokes the
integration points JSF uses with the web container (mainly the
ServletContextListener and ServletContainerInitializer). In both cases, there
were no ServletContextListeners or ServletContainerInitializers present. This
meshes with my observation of the log - no jsf initialization message.

Jan, can you please look into this?

[1] http://hudson.glassfish.org/job/gf-trunk-build-continuous/

Comment by kumara [ 26/Oct/09 ]

AIX support is being defered to v3.1. Thank you everyone for your hard work in getting AIX support so far
along in v3 release.

Comment by sherryshen [ 29/Oct/09 ]

Not a blocker any more.

Comment by Shing Wai Chan [ 30/Oct/09 ]

In the debugger, I saw that
ServletContainerInitializerUtil.getServletContainerInitializers() return an
empty Iterable in that environment.

In a ubunta machine, if I switch to use IBM JDK, then I see the same problem.
So, this is an IBM JDK related issue, rather than AIX specific problem.

Comment by jluehe [ 14/Apr/10 ]

...

Comment by Shing Wai Chan [ 19/Apr/10 ]

...

Comment by kchung [ 07/Oct/10 ]

IBM JDK issue.

Comment by scatari [ 05/Apr/11 ]

Marking as to be fixed in 3.1.1.

Comment by Bhakti Mehta [ 15/Apr/11 ]

Changed to blocker as all QL failures are P1s now

Comment by Sivakumar Thyagarajan [ 18/Apr/11 ]

This issue appears to be a duplicate of GLASSFISH-16364, and is due to the non-availability of services specified through the ServiceProvider mechanism in IBM JDK. In this specific case, it is the FacesContextFactory service. Marking this as a duplicate.

Comment by Bhakti Mehta [ 20/Apr/11 ]

Sahoo's fix for 16364 fixed this issue http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.1-aix-build/lastSuccessfulBuild/artifact/bundles/QL-GP-report.html





[GLASSFISH-10020] ERROR deploying JPA 2.0 to Glassfish v3 Created: 06/Oct/09  Updated: 16/Nov/09  Resolved: 16/Nov/09

Status: Closed
Project: glassfish
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: V3

Type: Bug Priority: Blocker
Reporter: geranimo Assignee: Mitesh Meswani
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: Other


Issuezilla Id: 10,020

 Description   

Part of persistence.xml file :

...
persistence version="2.0"
...

Error at deployment time:

[#|2009-10-06T16:04:51.593+0300|SEVERE|glassfish|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=19;_ThreadName=Thread-1;Deployment
descriptor file META-INF/persistence.xml in archive
[classes].;2;248;cvc-complex-type.3.1: Value '2.0' of attribute 'version' of
element 'persistence' is not valid with respect to the corresponding attribute
use. Attribute 'version' has a fixed value of '1.0'.;|"DPL8015: Invalid
Deployment Descriptors in Deployment descriptor file META-INF/persistence.xml in
archive [classes].
Line 2 Column 248 – cvc-complex-type.3.1: Value '2.0' of attribute 'version' of
element 'persistence' is not valid with respect to the corresponding attribute
use. Attribute 'version' has a fixed value of '1.0'."|#]

[#|2009-10-06T16:04:51.593+0300|SEVERE|glassfish|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=19;_ThreadName=Thread-1;cvc-complex-type.3.1:
Value '2.0' of attribute 'version' of element 'persistence' is not valid with
respect to the corresponding attribute use. Attribute 'version' has a fixed
value of '1.0'.;|"DPL8005: Deployment Descriptor parsing failure :
cvc-complex-type.3.1: Value '2.0' of attribute 'version' of element
'persistence' is not valid with respect to the corresponding attribute use.
Attribute 'version' has a fixed value of '1.0'."|#]

[#|2009-10-06T16:04:51.593+0300|SEVERE|glassfish|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=19;_ThreadName=Thread-1;|Exception
while deploying the app
java.io.IOException: org.xml.sax.SAXParseException: cvc-complex-type.3.1: Value
'2.0' of attribute 'version' of element 'persistence' is not valid with respect
to the corresponding attribute use. Attribute 'version' has a fixed value of '1.0'.
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:117)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:36)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:547)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:489)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:223)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:172)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:247)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:419)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:434)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:521)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:137)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:313)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:180)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:208)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:655)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:905)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:161)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.1: Value '2.0' of
attribute 'version' of element 'persistence' is not valid with respect to the
corresponding attribute use. Attribute 'version' has a fixed value of '1.0'.
at
com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:295)
at
com.sun.enterprise.deployment.archivist.ExtensionsArchivist.open(ExtensionsArchivist.java:76)
at
com.sun.enterprise.deployment.archivist.PersistenceArchivist.readPersistenceDeploymentDescriptor(PersistenceArchivist.java:74)
at
com.sun.enterprise.deployment.archivist.WarPersistenceArchivist.open(WarPersistenceArchivist.java:51)
at
com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:328)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:215)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:208)
at
com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:142)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:114)
... 29 more
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.1: Value '2.0' of
attribute 'version' of element 'persistence' is not valid with respect to the
corresponding attribute use. Attribute 'version' has a fixed value of '1.0'.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:410)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processOneAttribute(XMLSchemaValidator.java:2773)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2685)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2037)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:685)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:626)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3095)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:922)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at
com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:289)
... 37 more

#]

When changing the persistence.xml file to:

...
persistence version="1.0"
...

there is no error at deployment time.



 Comments   
Comment by Hong Zhang [ 06/Oct/09 ]

assign to mitesh to take a look

Comment by Mitesh Meswani [ 06/Oct/09 ]

Can you please post you complete pesitence.xml

I am able to deploy persistence.xml written as follows

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" version="2.0">

Thanks,
Mitesh

Comment by geranimo [ 09/Oct/09 ]

Hello,

Thank you for your prompt reply.

I have the same persistence.xml file, but I get the error mentioned previously
when deploying JPA 2.0.
This is my complete persistence.xml file :

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" version="2.0">

<persistence-unit name="BShopPU" transaction-type="RESOURCE_LOCAL">
<non-jta-data-source>jdbc/mysqlds</non-jta-data-source>
<properties/>
</persistence-unit>
</persistence>

Comment by Mitesh Meswani [ 10/Oct/09 ]

Which build of GlassFish you are deploying this to. Have you tried latest
promoted build?

Comment by geranimo [ 10/Oct/09 ]

I downloaded a Glassfish v3 Preview Windows Installer about ten days ago.
According to the error output:
<code>Value '2.0' of attribute 'version' of element 'persistence' is not valid
with respect to the corresponding attribute use. Attribute 'version' has a fixed
value of '1.0'</code>

it might be a trivial configuration problem.

If it is any help, once in a while, when deploying JPA 2.0 to Glasfish v3, I get
this message in Netbeans:

<b>Oct 11, 2009 8:37:35 AM : Retrieving Location:
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd

Error: File not found in the specified address :
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd</b>

I also want to tell you that I think you are doing an amazing job on J2EE 6 and
Glassfish v3. Actually, next week I am going to participate as a Junior
Architect in conferences of an international IT company and I am going to
suggest the use of latest Sun Microsystems' hardware and software platform.

I just hope that they will agree and I will have your help on solving any bugs
that might appear.

Comment by Mitesh Meswani [ 11/Oct/09 ]

AFAIR, the functionality of parsing 2.0 schema was not implemented in preview.
Can you please try this against latest promoted build of GlassFish. You can get
it from http://download.java.net/glassfish/v3/promoted/latest-glassfish.zip

As I mentioned above, this works for me against current code base.

Thanks for kind words about GlassFish

Comment by Mitesh Meswani [ 13/Oct/09 ]

Marking as WORKSFORME as this works with latest code base. Please try your test
case with latest GlassFish build and reopen if it does not work for you.

Comment by geranimo [ 16/Nov/09 ]

The server I downloaded from your suggest link works great, there are no more
problems with deploying jpa 2.0





[GLASSFISH-15572] Unable to start OHS with lbplugin installed Created: 14/Jan/11  Updated: 17/Jan/11  Resolved: 17/Jan/11

Status: Closed
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_b36
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jothir Assignee: kshitiz_saxena
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL 32-bit and OHS.


Attachments: Text File console~OHS~1.log    
Tags: 3_1, 3_1-blocking, plugin

 Description   

I tried configuring glassfish-lbplugin on OHS but was not able to start ohs.
Copied all the files from glassfish-plugin/lib/webserver-plugin/linux/apache2.2 to bea_default/Oracle_WT1/instances/instance1/OHS/ohs1/plugins/lbplugin

snippet from the console log:
--------------------------------
11/01/14 15:48:03 Start process
--------
/space/jothir/bea_default/Oracle_WT1/ohs/bin/apachectl startssl: execing httpd
[Fri Jan 14 15:48:03 2011] [warn] Errors will be logged into /space/jothir/bea_default/Oracle_WT1/instances/instance1/diagnostics/logs/OHS/ohs1/ohs1.log

      • glibc detected *** /space/jothir/bea_default/Oracle_WT1/ohs/bin/httpd.worker: free(): invalid pointer: 0xbfcc2734 ***
        ======= Backtrace: =========
        /lib/libc.so.6[0x8a2595]
        /lib/libc.so.6(cfree+0x59)[0x8a29d9]
        /space/jothir/bea_default/Oracle_WT1/instances/instance1/config/OHS/ohs1/modules/mod_loadbalancer.so(logInit__FPcPCci+0x6a)[0xb5f4133a]
        /space/jothir/bea_default/Oracle_WT1/instances/instance1/config/OHS/ohs1/modules/mod_loadbalancer.so[0xb5f360dc]
        /space/jothir/bea_default/Oracle_WT1/ohs/bin/httpd.worker(ap_run_post_config+0x4d)[0x807e579]
        /space/jothir/bea_default/Oracle_WT1/ohs/bin/httpd.worker(main+0x758)[0x80699b8]
        /lib/libc.so.6(__libc_start_main+0xdc)[0x84ee9c]
        /space/jothir/bea_default/Oracle_WT1/ohs/bin/httpd.worker(apr_bucket_mmap_make+0x61)[0x8065c25]

Attached the full log for reference.



 Comments   
Comment by kshitiz_saxena [ 17/Jan/11 ]

This was a configuration issues. The required files were not copied under modules directory resulting in OHS crash. Following files were missing :
modules/resource
modules/resource/LBPluginDefault_root.res
modules/resource/LBPlugin_root.res
modules/errorpages
modules/errorpages/default-error.html
modules/errorpages/sun-http-lberror.html
Once files are copied, OHS is running properly.

Closing this issue as cannot reproduce.





[GLASSFISH-15559] [PERF]: JAXB string interning introduces major performance regression for webservices Created: 13/Jan/11  Updated: 03/Dec/12  Resolved: 18/Jan/11

Status: Closed
Project: glassfish
Component/s: jax-rs
Affects Version/s: 3.1_b31
Fix Version/s: 3.1

Type: Bug Priority: Blocker
Reporter: Scott Oaks Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAXB-805 [PERF]: JAXB string interning introdu... Resolved
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Tags: PSRBUG

 Description   

The upgrade to jaxb 2.2.2 in build 31 has caused a significant regression in webservices performance. [The underlying issue is in jaxb, which isn't a category, so I'm using jax-rs; not sure if that is the most appropriate.]

The root cause is the new string.intern() calls performed by FastInfosetConnector.InterningXmlVisitor. If I take the 2.2.1 FastInfosetConnector class and run it in 2.2.2, the regression goes away (the only difference in that class is the 2.2.2 classes uses a new InterningXmlVisitor(visitor) object; the 2.2.1 class uses the passed-in visitor directly). Running that test is what I referred to below when I said I needed to gather a little more data first.

I realize that may affect other parts of the code, but these intern calls are clearly a problem. In specj, we are spending 10% of our time just doing string intern calls, and the webservices calls in specj (which is what uses jaxb) are a very minor part of the workload. The actual webservice call – that is com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke() – takes 3x longer with jaxb 2.2.2, and the jaxb unmarshalling (com.sun.xml.bin.api.Bridge.unmarshal -> com.sun.xml.bind.v2.runtime.unmarshaller.FastInfosetConnector.bridge()) takes 7x longer. All that time is from the string interning.



 Comments   
Comment by Martin Grebac [ 18/Jan/11 ]

The updated jaxb release 2.2.3-1 was integrated to GF 3.1.





[GLASSFISH-15553] com.sun.faces.spi problems when installing older version of Mojarra into GlassFish 3.1 Created: 12/Jan/11  Updated: 11/May/11  Due: 18/Jan/11  Resolved: 13/Jan/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File i_gf_15553.patch     Text File i_gf_15553.patch     Zip Archive i_gf_15553.zip    

 Description   

The way in which issues JAVASERVERFACES-1835 and GLASSFISH -14028 were fixed involved evolving the com.sun.faces.spi system, but these changes were not done in a backwards compatible way.

I need to roll back the changes to these issues and re-integrate them in a way that allows older versions of Mojarra 2.0, most noteably 2.0.4, to successfully exist.



 Comments   
Comment by Ed Burns [ 13/Jan/11 ]

This patch captures the "overwrite the jsf-connector.jar with a Mojarra 2.0.4 specific version" version of the fix for this issue.

Comment by Ed Burns [ 13/Jan/11 ]

Zip of changed files. The patch seems to have duplicates in it.

Comment by Ed Burns [ 13/Jan/11 ]

Sheetal's simple idea to add the interfaces from 2.1.0 to 2.0.4. This, combined with a small fix to ConfigManager, should solve the problem.

Comment by Ed Burns [ 13/Jan/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
Adding jsf-ri/src/main/java/com/sun/faces/spi/AnnotationScanner.java
Adding jsf-ri/src/main/java/com/sun/faces/spi/HighAvailabilityEnabler.java
Transmitting file data ...
Committed revision 8810.

Comment by swaki69 [ 28/Mar/11 ]

How can I implement this fix?

Comment by ricardorodrigues [ 11/May/11 ]

Have you implemented this fix. How? I'm having the same problem!

Comment by Ed Burns [ 11/May/11 ]

Can you please describe the problem you are having in more detail?





[GLASSFISH-15551] appclient does not work on windows with cygwin Created: 12/Jan/11  Updated: 20/Feb/11  Due: 18/Jan/11  Resolved: 14/Jan/11

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_b38

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

Tags: 3_1-approved, 3_1-blocking, 3_1-verified

 Description   

appclient fails on windows with cygwin

Here is the log

> /cygdrive/c/ha/glassfish3/glassfish/ config
> $ C:/ha/glassfish3/glassfish/bin/appclient -client C:/ha/ file_repository//appclient/cartClient.jar -xml C:/ha/ file_repository//appclient/sun-acc.xml++ dirname C:/ha/glassfish3/ glassfish/bin/appclient
> + _AS_INSTALL=C:/ha/glassfish3/glassfish/bin/..
> + export _AS_INSTALL
> + case "`uname`" in
> ++ uname
> ++ cygpath --windows C:/ha/glassfish3/glassfish/bin/..
> + _AS_INSTALL='C:\ha\glassfish3\glassfish\'
> + . 'C:\ha\glassfish3\glassfish\/config/asenv.conf'
> ++ AS_IMQ_LIB=../../mq/lib
> ++ AS_IMQ_BIN=../../mq/bin
> ++ AS_CONFIG=../config
> ++ AS_INSTALL=..
> ++ AS_DEF_DOMAINS_PATH=../domains
> ++ AS_DEF_NODES_PATH=../nodes
> ++ AS_DERBY_INSTALL=../../javadb
> ++ AS_JAVA=C:/ha/jdk1.6.0_23
> + chooseJava
> + '[' C:/ha/jdk1.6.0_23 '!=' '' ']'
> + javaSearchType=AS_JAVA
> + javaSearchTarget=C:/ha/jdk1.6.0_23
> + JAVA=C:/ha/jdk1.6.0_23/bin/java
> + '[' '!' -x C:/ha/jdk1.6.0_23/bin/java ']'
> ++ C:/ha/jdk1.6.0_23/bin/java -classpath 'C:\ha\glassfish3\glassfish \/lib/gf-client.jar' org.glassfish.appclient.client.CLIBootstrap - client C:/ha/file_repository//appclient/cartClient.jar -xml C:/ha/ file_repository//appclient/sun-acc.xml
> + eval '"C:\ha\jdk1.6.0_23\jre\bin\java.exe"' '- Dcom.sun.aas.installRoot="C:\ha\glassfish3\glassfish"' '- Djava.security.policy="C:\ha\glassfish3\glassfish\lib\appclient \client.policy"' - Djava .system .class .loader=org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader 'Djava.security.auth.login.config="C:\ha\glassfish3\glassfish\lib \appclient\appclientlogin.conf"' '-Djava.ext.dirs="C:\ha \glassfish3\glassfish\lib\ext";"C:\ha\jdk1.6.0_23\jre\lib\ext"' ' Djava.endorsed.dirs="C:\ha\glassfish3\glassfish\lib\endorsed";"C:\ha \glassfish3\glassfish\modules\endorsed";"C:\ha\jdk1.6.0_23\jre\lib \endorsed"' 'javaagent:"C:\ha\glassfish3\glassfish\lib\gf client.jar"=mode=acscript,arg=configxml,arg="C:\ha \glassfish3\glassfish\domains\domain1\config\sun acc.xml",client=jar="C:/ha/file_repository//appclient/ cartClient.jar",arg=xml,arg="C:/ha/file_repository//appclient/sun acc.xml"' -jar '"C:/ha/file_repository//appclient/cartClient.jar"' $'\r'
> ++ 'C:\ha\jdk1.6.0_23\jre\bin\java.exe' '-Dcom.sun.aas.installRoot=C: \ha\glassfish3\glassfish' '-Djava.security.policy=C:\ha \glassfish3\glassfish\lib\appclient\client.policy' - Djava .system .class .loader=org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader '-Djava.security.auth.login.config=C:\ha\glassfish3\glassfish\lib \appclient\appclientlogin.conf' '-Djava.ext.dirs=C:\ha \glassfish3\glassfish\lib\ext'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\bin\java.exe: command not found
> ++ 'C:\ha\jdk1.6.0_23\jre\lib\ext' '-Djava.endorsed.dirs=C:\ha \glassfish3\glassfish\lib\endorsed'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\lib\ext: command not found
> ++ 'C:\ha\glassfish3\glassfish\modules\endorsed'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \glassfish3\glassfish\modules\endorsed: command not found
> ++ 'C:\ha\jdk1.6.0_23\jre\lib\endorsed' 'javaagent:C:\ha \glassfish3\glassfish\lib\gf-client.jar=mode=acscript,arg= configxml,arg=C:\ha\glassfish3\glassfish\domains\domain1\config\sun- acc.xml,client=jar=C:/ha/file_repository//appclient/ cartClient.jar,arg=xml,arg=C:/ha/file_repository//appclient/sun acc.xml' -jar C:/ha/file_repository//appclient/cartClient.jar $'\r'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\lib\endorsed: command not found
>
>



 Comments   
Comment by Tim Quinn [ 13/Jan/11 ]

As I said to Gopal in e-mail, I suspect the problem is this.

The appclient script runs a java command executing CLIBootstrap, which in turn computes a second java command which actually launches the ACC. CLIBootstrap uss conventional techniques to determine what OS is current so it can use the correct path separator character. When running on Windows, even under cygwin, Java reports the separator character as '\' and the path separator char as ';' and so CLIBootstrap creates a java command using those characters. Further, CLIBootstrap prepares the second java command to run java.exe.

I think cygwin appends another .exe to the file path to find the actual executable on the Windows system, and of course java.exe.exe is not present in the Java installation. That causes the error message that java.exe cannot be found. The subsequent errors are because cygwin seems to be interpreting the ; Windows path separator which CLIBootstrap used as command separators as *nix shells do.

It may be a simple matter of CLIBootstrap detecting not only if the OS is Windows but also whether cygwin is the current shell. The appclient script can pass an additional property to CLIBootstrap to indicate this if needed. Elena has allowed me to use an SQE Windows test system with cygwin installed to work on this further.

Comment by Tim Quinn [ 13/Jan/11 ]

updating fix version

Comment by Tim Quinn [ 13/Jan/11 ]

Review discussion:

How bad is its impact? (Severity)
This is a regression and is causing sqe tests using Windows and cygwin to fail. Users will have the same problems in that environment.

How often does it happen? (Frequency)
Always with Windows and cygwin.

How much effort is required to fix it? (Cost)
I already have a fix I am testing.

What is the risk of fixing it? (Risk)
Low. The change consists of very simple changes to the appclient script (adding env var assignments and adding env var substitutions on a command to pass information into the CLIBootstrap class) plus a handful of parallel changes in CLIBoostrap.java to use these properties if/when they are defined.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There is no workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Comment by Tim Quinn [ 14/Jan/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 44520
Author: tjquinn
Date: 2011-01-15 00:41:33 UTC
Link:

Log Message:
------------
Fix for 15551

The app client CLIBootstrap class, which prepares the actual java command to launch the ACC, needed to use Unix-style path separators if the user is on Windows but running under cygwin.

These changes pass some additional information from the appclient and appclient.bat scripts to CLIBootstrap by env vars and a property.

Approved: Nazrul
Code Reviewed: Byron

Tests: QL, deployment and ejb devtests; manual tests on Windows with and without cygwin

Revisions:
----------
44520

Modified Paths:
---------------
trunk/v3/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java
trunk/v3/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient.bat





[GLASSFISH-15416] [STRESS] specjent2010 run against b36 failed Created: 03/Jan/11  Updated: 05/Jan/11  Resolved: 05/Jan/11

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: future release
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: zorro Assignee: amitagarwal
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

solaris sparc jdk 6u22



 Description   

The following is the logs and configuration of a faild specjent2010 run against b36.
configuration.

Please note that there are exceptions which are specj's
business logic related (they do not relate to the appserver)
i.e. java.io.NotSerializableException: java.util.Formatter is specj
But some exceptions like java.lang.StackOverflowError seems to be a bug.

http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/

Physical location: /net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/

Please evaluate the logs for addressing possible issues.

This is the log and configuration of a successful 7-day longevity run of specjent10 against b33.
http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/logs/bigapp-opteron-3/
Physical location: /net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/logs/bigapp-opteron-3/



 Comments   
Comment by Nazrul [ 03/Jan/11 ]

Amit: Are you seeing this type of issues when you run SPECj?

Comment by zorro [ 03/Jan/11 ]

Note: Specj determines pass/fail according to the information in the summary.xml as stated below.
(look for <passed>false</passed> and <passed>true</passed> in the summary.xml below).

b33

39 passed true
0 passed false
/net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/summary.xml

b36

33 passed true
6 passed false
/net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/summary.xml

Comment by Nazrul [ 04/Jan/11 ]

We are not supposed to run SPECj application in HA mode.

Looking at the server log, it looks like we are running into serialization issues:

[#|2010-12-30T20:15:50.516-0800|INFO|oracle-glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=78;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute specUtils for session aa2a28e143662004d431d1cb7a4a
java.io.NotSerializableException: java.util.Formatter

Do you use manual steps to setup the SPECj application?

Comment by zorro [ 04/Jan/11 ]

There is no manual setup.
All configurations are done internally in specjent10.

Comment by amitagarwal [ 05/Jan/11 ]

First of all I am not seeing this issue in our setup.
As per logs Stackoverflow exception happens just once, and before appserver could start completely. This does not seem to be related to specj. I see org.glassfish.gmbal.impl.* calls going into loop thats results into stackoverflow.
One way to resolve this overflow error is to change -Xss128k to -Xss198k or someone responsible for org.glassfish.gmbal.impl.* needs to see why call sequence is so long.
Perhaps this happens only in sparc setup.

Other exceptions are harmless, they are part of specj runs.

I could run specj against b36 on OEL setup without any issues.

Comment by Nazrul [ 05/Jan/11 ]

Closing this as a duplicate of GLASSFISH-15422





[GLASSFISH-15347] java.lang.OutOfMemoryError: Java heap space and other failures during Nile Book Store longevity run. Created: 25/Dec/10  Updated: 28/Dec/10  Resolved: 27/Dec/10

Status: Closed
Project: glassfish
Component/s: group_management_service
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b34

Type: Bug Priority: Blocker
Reporter: zorro Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris Sparc jdk 6u22


Issue Links:
Duplicate
is duplicated by GLASSFISH-15357 Command stop-cluster failed after 600... Resolved
Tags: 3_1-blocking

 Description   

b33 started 7-day longevity runs using NileBookStore bigapp against a 3-node cluster on 4 sparc solaris machines.

Bug:
After a few hours of run the following exceptions were thrown massively.
Note: Intermittently transactions succeed.

[#|2010-12-25T13:58:04.991-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=16;_ThreadName=Thread-1;|java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Arrays.java:3209)
at java.lang.String.<init>(String.java:215)
at java.nio.HeapCharBuffer.toString(HeapCharBuffer.java:542)
at java.nio.CharBuffer.toString(CharBuffer.java:1157)
at com.sun.enterprise.web.PEAccessLogValve.log(PEAccessLogValve.java:652)
at com.sun.enterprise.web.PEAccessLogValve.run(PEAccessLogValve.java:1122)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2010-12-24T22:35:15.600-0800|WARNING|oracle-glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=16;_ThreadName=Thread-1;|LoadRequestCommand timed out while waiting for result java.util.concurrent.TimeoutException|#]

[#|2010-12-24T22:35:15.900-0800|WARNING|oracle-glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=16;_ThreadName=Thread-1;|LoadRequestCommand timed out while waiting for result java.util.concurrent.TimeoutException|#]

[#|2010-12-24T22:35:17.000-0800|WARNING|oracle-glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=16;_ThreadName=Thread-1;|LoadRequestCommand timed out while waiting for result java.util.concurrent.TimeoutException|#]

[#|2010-12-24T22:35:18.530-0800|WARNING|oracle-glassfish3.1|org.shoal.ha.cache.command.load_request|_ThreadID=16;_ThreadName=Thread-1;|LoadRequestCommand timed out while waiting for result java.util.concurrent.TimeoutException|#]

org.shoal.ha.cache.command.save|_ThreadID=16;_ThreadName=Thread-1;|Aborting command transmission for ReplicationFramePayloadCommand:1 because beforeTransmit returned false|#]
[#|2010-12-25T13:41:39.169-0800|WARNING|oracle-glassfish3.1|ShoalLogger|_ThreadID=16;_ThreadName=Thread-1;|Error during groupHandle.sendMessage(null, /NileBookStore; size=287193|#]

java.net.SocketException: Invalid argument
at sun.nio.ch.Net.setIntOption0(Native Method)
at sun.nio.ch.Net.setIntOption(Net.java:157)
at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:406)
at sun.nio.ch.SocketOptsImpl.setBoolean(SocketOptsImpl.java:38)
at sun.nio.ch.SocketOptsImpl$IP$TCP.noDelay(SocketOptsImpl.java:284)
at sun.nio.ch.OptionAdaptor.setTcpNoDelay(OptionAdaptor.java:48)
at sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:268)
at com.sun.grizzly.http.SelectorThread.setSocketOptions(SelectorThread.java:1490)
at com.sun.grizzly.http.SelectorThreadHandler.configureChannel(SelectorThreadHandler.java:91)
at com.sun.grizzly.http.SelectorThreadHandler.onAcceptInterest(SelectorThreadHandler.java:102)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:300)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:263)
at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:200)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

#]

All logs:
http://aras2.us.oracle.com:8080/logs/gf31/gms/set_12_25_10_t_14_13_41/scenario_0001_Sat_Dec_25_14_14_09_PST_2010/

physical location:
/net/asqe-logs.us.oracle.com/export1/gms/gf31/gms/set_12_25_10_t_14_13_41/scenario_0001_Sat_Dec_25_14_14_09_PST_2010/



 Comments   
Comment by zorro [ 27/Dec/10 ]

7-day run against nightly build 33 stopped after 2 days with failures stated above.
Stopping cluster failed with:
asadmin stop-cluster clusterz1
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command stop-cluster failed.

all logs:
http://aras2.us.oracle.com:8080/logs/gf31/gms/set_12_27_10_t_12_14_01/scenario_0001_Mon_Dec_27_12_31_14_PST_2010/

physical location.
/net/asqe-logs.us.oracle.com/export1/gms/gf31/gms/set_12_27_10_t_12_14_01/scenario_0001_Mon_Dec_27_12_31_14_PST_2010/

Comment by shreedhar_ganapathy [ 27/Dec/10 ]

Based on feedback from Rajiv and Sony, the issue seems to be the same as the one reported in 15231 which was seen in b33 and fixed in b34.

Also the heap size for Niles app should be -Xmx1024m based on input from Sony from runs in prior releases. The domain xml shows the run was set at 512m.

Please run with b34 and if you see this issue, please reopen it.

Comment by Mahesh Kannan [ 27/Dec/10 ]

Closing this based on Shreedhar's comment





[GLASSFISH-15331] need create-ssl command to be able to create SSL under protocol Created: 22/Dec/10  Updated: 04/Jan/11  Resolved: 04/Jan/11

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b33
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Anissa Lam Assignee: ludo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15313 accessing ssl tab after protocol crea... Closed

 Description   

Sorry, I was just told by Srini that there doesn't seem to be a way to create SSL under Protocol.
(Network Config-> Protocol)

I looked at create-ssl, it only takes in the following type:

@Param(name = "type", acceptableValues = "network-listener, http-listener, iiop-listener, iiop-service, jmx-connector")

Does it mean you need to add another type 'protocol' so that Srini can create SSL under protocol ?
We will need you to add support of creating SSL under protocol. This is blocking GUI GLASSFIS-15313.
thanks and sorry for the late notice.



 Comments   
Comment by Nazrul [ 27/Dec/10 ]

Getting help from Justin

Comment by Justin Lee [ 27/Dec/10 ]

what's not working here? why doesn't one of those --type options work? the type is used to locate the protocol to use. Now, we can add a --protocol option and make both --protocol and --type optional but at least one has to be set. That's fairly trivial. But my 2 big questions are 1) what exactly doesn't work about the current command and 2) shouldn't this wait for 3.2 at this point?

Comment by Anissa Lam [ 27/Dec/10 ]

If i create a protocol, how do i create the SSL element under it ? Maybe there is a way, I just can't figure that out.
If you can provide me CLI to create the SSL element under Protocol, that will do.

If i run:
%asadmin create-protocol myProtocol
%asadmin create-http --default-virtual-server server myProtocol

I can see the element in domain.xml. Good.
<protocol name="myProtocol">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
</protocol>

Now, can you tell me how to create the <SSL> for this protocol ?

I would like the protocol element to end up like this
<protocol name="myProtocol">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" ssl3-enabled="false" cert-nickname="myCert"></ssl>
</protocol>

Comment by Justin Lee [ 28/Dec/10 ]

You create the, say, network-listener, then call create-ssl with --type=network-listener and the name of the listener. It'll find the protocol from the listener and create things appropriately.

And yes, that seems horribly convoluted to me, too. But it's been that way for years and I don't know why either.

Comment by Anissa Lam [ 28/Dec/10 ]

What if this protocol is NOT used by any Network Listener yet ? How do i do it ?
Without being able to create the SSL by just specify the protocol name, GUI is very BAD shape.
We need this to be fixed.

Comment by Anissa Lam [ 28/Dec/10 ]

move this to P1. GUI still need to make some changes (although minor) once this bug is fixed. Time is running out. I would like to see this being work on soon.

Comment by Anissa Lam [ 28/Dec/10 ]

1) How bad is its impact? (Severity)
Cannot create SSL under protocol unless this protocol has network listener using it. This impacts GUI user as well as CLI . But more severe with GUI. GUI user cannot get to the SSL tab of this protocol.

2) How often does it happen? (Frequency)
Whenever the protocol is not referenced by Network Listener.

3) How much effort is required to fix it? (Cost)
Justin to provide.

4) What is the risk of fixing it? (Risk)
Justin to provide.

Comment by Justin Lee [ 28/Dec/10 ]

Actually, I'm pretty sure no change is needed. If, for example, you pass --type=network-listener and a listener of that type does not exist, the create-ssl command will attempt to find or create a protocol with that name. So in the case of the GUI, you just need to pass --type=network-listener and let the command deal with the missing listener. Give that a try and if it doesn't work, we can go the route of the hidden parameter.

Comment by Anissa Lam [ 28/Dec/10 ]

Thanks for providing the work around.
I just tested the suggested option, and it is working fine.

~/Awork/V3/v3 520) v3admin create-protocol myProtocol
Command create-protocol executed successfully.
~/Awork/V3/v3 521) v3admin create-http --default-virtual-server server myProtocol
Command create-http executed successfully.
~/Awork/V3/v3 522) v3admin create-ssl --certname AAAA --type network-listener myProtocol
Network Listener named myProtocol does not exist. Creating or using the named protocol element instead.
Command create-ssl executed successfully.

domain.xml looks good too:
<protocol name="myProtocol">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
<ssl ssl2-enabled="true" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="AAAA" client-auth-enabled="true"></ssl>
</protocol>

So, closing this bug as fixed. Thanks !!

Comment by srinik76 [ 30/Dec/10 ]

Still we need REST URL to create-ssl under protocol specifying type

Currently ssl is under each network listener. Currently when ssl needs to be created protocol there is not create-ssl under protocol and also we cannot use create-ssl rest call under network listener. Rest team needs to work on this.

I tested the CLI and it works fine by specifying type attribute and mentioning protocol name for listener id.

We need a translated create-ssl call in rest api under protocol.

Comment by Anissa Lam [ 30/Dec/10 ]


Srini indicated above that REST needs to make create-ssl command available for Protocol. Assign to the correct component.

Comment by Anissa Lam [ 04/Jan/11 ]

Requesting help from Ludo.

create-ssl command allows you to specify the type to decide where the SSL element should be created under.

However, specifying "--type network-listener" takes in either network listener name OR protocol name and it is 'smart' enough to decide where <SSL> should be created under.

%asadmin create-ssl --type network-listener myProtocolName

or

%asadmin create-ssl --type network-listener myListenerName

However, in REST, the command is under NetworkListener only. There is no create-ssl command under protocol.

we need this fixed.

Comment by ludo [ 04/Jan/11 ]

Fix ready for review

delete-ssl is also tricky and fixed: it is there in the generic @Delete on SSL, so do not need to expose more delete-ssl commands under particular nodes.
The key for delete-ssl is the parent name (protocol, listener, jmx-connector etc)
Patch:

  1. This patch file was generated by NetBeans IDE
  2. Following Index: paths are relative to: /Users/ludo/acvs/v3/admin/rest/src/main/java/org/glassfish/admin/rest
  3. This patch can be applied using context Tools: Patch action on respective folder.
  4. It uses platform neutral UTF-8 encoding and \n newlines.
  5. Above lines and this line are ignored by the patching process.
    Index: generator/CommandResourceMetaData.java
      • generator/CommandResourceMetaData.java Base (BASE)
        +++ generator/CommandResourceMetaData.java Locally Modified (Based On LOCAL)
        @@ -1,7 +1,7 @@
        /*
  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -274,12 +274,9 @@
    {"HttpService", "list-protocols", "GET", "list-protocols", "list-protocols"}

    ,

    {"HttpService", "list-virtual-servers", "GET", "list-virtual-servers", "list-virtual-servers"}

    ,

    {"IiopListener", "create-ssl", "POST", "create-ssl", "Create", "id=$parent", "type=iiop-listener"}

    ,

  • {"IiopListener", "delete-ssl", "DELETE", "delete-ssl", "Delete", "id=$parent", "type=iiop-listener"}

    ,

    {"IiopService", "create-ssl", "POST", "create-ssl", "Create", "type=iiop-service"}

    ,

  • {"IiopService", "delete-ssl", "DELETE", "delete-ssl", "Delete", "type=iiop-service"}

    ,

    {"IiopService", "list-iiop-listeners", "GET", "list-iiop-listeners", "list-iiop-listeners"}

    ,

    {"JmxConnector", "create-ssl", "POST", "create-ssl", "Create", "id=$parent", "type=jmx-connector"}

    ,

  • {"JmxConnector", "delete-ssl", "DELETE", "delete-ssl", "Delete", "id=$parent", "type=jmx-connector"}

    ,

    {"JavaConfig", "create-profiler", "POST", "create-profiler", "Create Profiler"}

    ,

    {"JavaConfig", "generate-jvm-report", "GET", "generate-jvm-report", "Generate Report", "target=$grandparent"}

    ,

    {"JmsService", "list-jms-hosts", "GET", "list-jms-hosts", "list-jms-hosts"}

    ,
    @@ -305,7 +302,6 @@

    {"LoadBalancer", "apply-http-lb-changes", "POST", "apply-http-lb-changes", "apply-http-lb-changes", "id=$parent"}

    ,

    {"LoadBalancer", "export-http-lb-config", "POST", "export-http-lb-config", "export-http-lb-config", "lbname=$parent"}

    ,

    {"NetworkListener", "create-ssl", "POST", "create-ssl", "Create", "id=$parent", "type=http-listener"}

    ,

  • {"NetworkListener", "delete-ssl", "DELETE", "delete-ssl", "Delete", "id=$parent", "type=http-listener"}

    ,

    {"Node", "_delete-node", "DELETE", "delete-node", "Delete Node", "id=$parent"}

    ,

    {"Node", "_update-node", "POST", "_update-node", "Update Node", "name=$parent"}

    ,

    {"Node", "ping-node-ssh", "GET", "ping-node-ssh", "Ping Node", "id=$parent"}

    ,
    @@ -323,6 +319,7 @@

    {"Protocol", "delete-http", "DELETE", "delete-http", "Delete", "id=$parent"}

    ,

    {"Protocol", "delete-protocol-filter", "DELETE", "delete-protocol-filter", "Delete", "protocol=$parent"}

    ,

    {"Protocol", "delete-protocol-finder", "DELETE", "delete-protocol-finder", "Delete", "protocol=$parent"}

    ,
    +

    {"Protocol", "create-ssl", "POST", "create-ssl", "Create", "id=$parent", "type=http-listener"}

    ,
    \ No newline at end of file

    {"Config", "_get-rest-admin-config", "GET", "_get-rest-admin-config", "_get-rest-admin-config"}

    ,

    {"Config", "_set-rest-admin-config", "POST", "_set-rest-admin-config", "_set-rest-admin-config"}

    ,

    {"Resources", "_get-activation-spec-class", "GET", "get-activation-spec-class", "Get Activation Spec Class"}

    ,
    Index: resources/TemplateResource.java

      • resources/TemplateResource.java Base (BASE)
        +++ resources/TemplateResource.java Locally Modified (Based On LOCAL)
        @@ -1,7 +1,7 @@
        /*
  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2009-2010 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2009-2011 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -475,10 +475,12 @@
    // This has to be smarter, since we are encoding / in resource names now

private void addDefaultParameter(HashMap<String, String> data) {

  • int index = uriInfo.getAbsolutePath().getPath().lastIndexOf('/');
  • String defaultParameterValue =
  • //uriInfo.getAbsolutePath().getPath().substring(index + 1);
  • getEntity().getKey();
    + String defaultParameterValue = getEntity().getKey();
    + if (defaultParameterValue==null) {// no primary key + //we take the parent key. + // see for example delete-ssl that that the parent key name as ssl does not have a key + defaultParameterValue= parent.getKey(); + }

    data.put("DEFAULT", defaultParameterValue);
    }

Comment by Jason Lee [ 04/Jan/11 ]

Looks good. Thanks, Ludo

Comment by ludo [ 04/Jan/11 ]

Committed revision 44209.
Revision: 44209
Author : ludo
Date : Jan 4, 2011 11:17:45 AM
Fix for http://java.net/jira/browse/GLASSFISH-15331
Review Jason Lee





[GLASSFISH-14867] [BLOCKING]IIOP Loadbalancing not happening when new instances added to the cluster Created: 29/Nov/10  Updated: 20/Feb/11  Due: 18/Jan/11  Resolved: 25/Jan/11

Status: Closed
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_b30
Fix Version/s: 3.1_ms08

Type: Bug Priority: Blocker
Reporter: gopaljorapur Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File patch.tgz    
Tags: 3_1-approved, 3_1-blocking, 3_1-verified

 Description   

Scenario:
1. Deploy an application to a cluster with
three instances
2. Start up one client with target-server+ specifying the three instances.

3. In a loop (100 iterations):
Create a new InitialContext
Do a lookup
Remember which instance the lookup went to

4. Add two new instances

5. Then do 100 new IntialContext/lookup.

New instances should process some of new requests

Its not happening and we see following exception in the server.log of new instance

[#|2010-11-25T17:48:17.568-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=16;_ThreadName=Thread-1;|Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:246)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:286)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:100)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:459)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:351)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:202)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:128)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:88)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
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:243)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:116)
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:96)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.RuntimeException: Error while binding JNDI name enterprise.lottery_annotation_ejb_stateful.Lottery for EJB : LotteryBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1550)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:218)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
... 23 more
Caused by: javax.naming.NameAlreadyBoundException: Use rebind to override
at com.sun.enterprise.naming.impl.TransientContext.doBindOrRebind(TransientContext.java:293)
at com.sun.enterprise.naming.impl.TransientContext.bind(TransientContext.java:232)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.bind(SerialContextProviderImpl.java:98)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:99)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:709)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:726)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:208)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:189)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5608)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1535)
... 26 more

#]

[#|2010-11-25T17:48:17.573-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-1;|Exception while loading the app|#]

[#|2010-11-25T17:48:17.642-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-1;|Exception while loading the app|#]



 Comments   
Comment by Ken Cavanaugh [ 21/Dec/10 ]

Impact:
Breaks backward compatibility with GF 2.1

Frequency:
Test case is always reproducible

Effort:
Mostly known, as a new method was needed in the InitialGroupInfoService. Still testing to
complete fix.

Risk:
Impact is limited to IIOP FOLB.

Comment by Ken Cavanaugh [ 23/Jan/11 ]

I have two versions of the test. One version creates all 5 instances before starting the cluster, and
then load balances across the 5 instances. That version works. LB is somewhat uneven, because the
start-instance command that starts the 5th instance returns (from asadmin) before the change has
propagated across the entire cluster. Until propagation completes, the client may not load balance to the new instance.
Typically in my testing this takes around 50-70 new InitialContext/lookup/invoke cycles. It is certainly
possible that in some cases the test could fail because the propagation does not complete until after the
tests's 100 (may be too small) cycles complete.

The second version create a 5 instance cluster, shuts down the cluster, restarts 3 instances,
and the creates and starts 2 more instances. This case failed due to issue 15665 until I changed
the test EJB getLocation method to use com.sun.aas.instanceName instead of the instance_name
property assigned by the test framework when setting up the instances. With the old instance_name property,
the test appeared to indicate that all cycles are handled by the same instance (always the last one created),
even though at least some degree of load balancing was actually taking place. With the change
to com.sun.aas.instanceName, the test is at least load balancing across the 3 individual instances.
I need to perform more testing to see if there is a problem remaining in this second or not.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

It appears that the cause of this problem is that the server-side ORB does not
process the shoal notification in the create-new-instances case (but obviously
does in the use-existing instance case). This in turn happens because
Server.isRunning() (one of the Duck methods on the server config bean)
return false when IiopFolbGmsClient is processing the update. I don't know why
that's happening (it looks like possibly the wrong admin port is being used
in NetUtils?), but I can take the fact that this call is from shoal as sufficient
evidence that the node is up and not call Server.isRunning in that case.
Server.isRunning is still needed in the initial bootstrap case, where some of the
nodes may be offline but still configured in the cluster.

I am rebuilding with this change. I'll update this issue later after I re-run the tests.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

I removed the link to issue 15665, because Tom's workaround (use a separate
create-system-property command) should apply in any situation.

Comment by Ken Cavanaugh [ 25/Jan/11 ]

This patch should be the same as the upcoming commit
to GF 3.1. It includes the b024 ORB and any naming and
GF orb glue changes.

Comment by Ken Cavanaugh [ 25/Jan/11 ]

Fixed in GF rev 44706. Also verified for the SQE tests (using a patch) by Gopal.





[GLASSFISH-15639] [Stress] richAcces + SSL stress test run on Win 2008, jvm crashed after 4 days of running. Created: 20/Jan/11  Updated: 24/Feb/11  Resolved: 24/Feb/11

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 3.1_b37
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: easarina Assignee: Chris Kasso
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File domain.xml     Text File hs_err_pid4216.log    
Tags: 3_1-blocking, 3_1-review

 Description   

Windows 2008 machines. Nightly nuild 38 01/14 was installed on three amchines:
asqe-oblade-15 DAS + in3
bigapp-oblade-1 in1
bigapp-oblade-2 in2

Was executed richAcces stress test, SSL was enbaled. Was used adefault EMBEDDED MQ mode.
After about 4 days of running without any issues, in3 jvm crashed on one asqe-oblade-15.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The JVM crash on asqe-oblade-15 happened on 1/18/11 at 1:36 pm. Please see jvm crash log under file C:\export\glassfish3\glassfish\nodes\node3\in3\config (see this log bellow)
================================================================

--------------- T H R E A D ---------------

Current thread (0x00000000090bf000): JavaThread "TransactionReaper" [_thread_in_Java, id=2716, stack(0x000000000d140000,0x000000000d160000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x000000000066006e

Registers:
RAX=0x00000000c7a1e3e8, RBX=0x00000000d3274840, RCX=0x00000000d4209be0, RDX=0x00000000f170afd8
RSP=0x000000000d15f4c0, RBP=0x00000000f170afd8, RSI=0x0000000000000000, RDI=0x00000000f1769cc8
R8=0x00000000f1709698, R9=0x0000000000660036, R10=0x0000000000000000, R11=0x00000000f1709698
R12=0x0000000000000000, R13=0x0000000000000000, R14=0x000000000d15f558, R15=0x00000000090bf000
RIP=0x0000000002af57c2, EFLAGS=0x0000000000010202

Register to memory mapping:

RAX=0x00000000c7a1e3e8

{instance class}
- klass: {other class}

RBX=0x00000000d3274840
java.util.ArrayList
- klass: 'java/util/ArrayList'

RCX=0x00000000d4209be0
[Ljava.lang.Object;
- klass: 'java/lang/Object'[]
- length: 38

RDX=0x00000000f170afd8

[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xe0000000]

Stack: [0x000000000d140000,0x000000000d160000], sp=0x000000000d15f4c0, free space=125k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J com.sun.messaging.jmq.util.UID.equals(Ljava/lang/Object;)Z

====================================
On in2 bigapp-oblade-2 : There is a JVM crash on 1/19/11 1:22 am. Please see jvm crash log under file C:\export\glassfish3\glassfish\nodes\node1\in1\config

--------------- T H R E A D ---------------

Current thread (0x0000000006ac4800): JavaThread "TransactionReaper" daemon [_thread_in_Java, id=3928, stack(0x000000000ca00000,0x000000000ca20000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000650085

Registers:
RAX=0x00000000c40c4b20, RBX=0x0000000000000003, RCX=0x00000000f0953400, RDX=0x00000000c76fe1f8
RSP=0x000000000ca1f640, RBP=0x00000000d2dbd440, RSI=0x00000000c7a1d728, RDI=0x59d92d9d95057f07
R8=0x0000000000000001, R9=0x00000000d4249428, R10=0x0000000000000004, R11=0x000000000065004d
R12=0x0000000000000000, R13=0x00000000c78f3488, R14=0x00000000c40121b0, R15=0x0000000006ac4800
RIP=0x0000000001d782c6, EFLAGS=0x0000000000010286

Register to memory mapping:

RAX=0x00000000c40c4b20{instance class}
  • klass: {other class}

    RBX=0x0000000000000003
    0x0000000000000003 is pointing to unknown location

    RCX=0x00000000f0953400

    [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xe0000000]

    Stack: [0x000000000ca00000,0x000000000ca20000], sp=0x000000000ca1f640, free space=125k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    J com.sun.messaging.jmq.jmsserver.data.TransactionReaper.run()V

    ====================================
    On in1 - bigapp-oblade-1 : There is a JVM crash on 1/19/11 10:08 AM. Here is the reason for the crash. Please see jvm crash log under file C:\export\glassfish3\glassfish\nodes\node1\in1\config

    --------------- T H R E A D ---------------

    Current thread (0x0000000008aae000): JavaThread "Grizzly-kernel-thread(1)" daemon [_thread_in_vm, id=3572, stack(0x0000000008360000,0x0000000008380000)]

    siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000000

    Registers:
    RAX=0x0000000000000000, RBX=0x0000000008aae000, RCX=0x0000000000000e00, RDX=0x0000000000000000
    RSP=0x000000000837f2b0, RBP=0x000000000a85bc50, RSI=0x0000000000000000, RDI=0x0000000000000000
    R8=0x0000000000000032, R9=0x000000000a85bc50, R10=0x0000000000000000, R11=0x0000000000000246
    R12=0x0000000000000032, R13=0x00000000c53922d8, R14=0x000000000837f448, R15=0x0000000008aae000
    RIP=0x000000006dadf79e, EFLAGS=0x0000000000010202

    Register to memory mapping:

    RAX=0x0000000000000000
    0x0000000000000000 is pointing to unknown location

    RBX=0x0000000008aae000
    "Grizzly-kernel-thread(1)" daemon prio=10 tid=0x0000000008aae000 nid=0xdf4 runnable [0x000000000837f000]
    java.lang.Thread.State: RUNNABLE

    RCX=0x0000000000000e00
    0x0000000000000e00 is pointing to unknown location

    RDX=0x0000000000000000
    0x0000000000000000 is pointing to unknown location

    RSP=0x000000000837f2b0
    0x000000000837f2b0 is pointing into the stack for thread: 0x0000000008aae000
    "Grizzly-kernel-thread(1)" daemon prio=10 tid=0x0000000008aae000 nid=0xdf4 runnable [0x000000000837f000]
    java.lang.Thread.State: RUNNABLE

    RBP=0x000000000a85bc50
    0x000000000a85bc50 is pointing to unknown location

    RSI=0x0000000000000000
    0x0000000000000000 is pointing to unknown location

    RDI=0x0000000000000000
    0x0000000000000000 is pointing to unknown location

    R8 =0x0000000000000032
    0x0000000000000032 is pointing to unknown location

    R9 =0x000000000a85bc50
    0x000000000a85bc50 is pointing to unknown location

    R10=0x0000000000000000
    0x0000000000000000 is pointing to unknown location

    R11=0x0000000000000246
    0x0000000000000246 is pointing to unknown location

    R12=0x0000000000000032
    0x0000000000000032 is pointing to unknown location

    R13=0x00000000c53922d8 {constMethod}
    - klass: {other class}
  • method: 0x00000000c53922e0 {method}

    'accept0' '(Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;[Ljava/net/InetSocketAddress;)I' in 'sun/nio/ch/ServerSocketChannelImpl'

  • exceptions: 0x00000000c4001ef8

R14=0x000000000837f448
0x000000000837f448 is pointing into the stack for thread: 0x0000000008aae000
"Grizzly-kernel-thread(1)" daemon prio=10 tid=0x0000000008aae000 nid=0xdf4 runnable [0x000000000837f000]
java.lang.Thread.State: RUNNABLE

R15=0x0000000008aae000
"Grizzly-kernel-thread(1)" daemon prio=10 tid=0x0000000008aae000 nid=0xdf4 runnable [0x000000000837f000]
java.lang.Thread.State: RUNNABLE

Top of Stack: (sp=0x000000000837f2b0)
0x000000000837f2b0: 0000000008aae000 0000000000002048
0x000000000837f2c0: 000000000837f438 000000000837f438
0x000000000837f2d0: 00000000000009a0 000000000837f430
0x000000000837f2e0: 0000000000000000 000000000837f438
0x000000000837f2f0: 0000000008aae1c8 00000000c4832e18
0x000000000837f300: 0000000000000000 000000006d6c3215
0x000000000837f310: 000000006dee6520 000000000837f430
0x000000000837f320: 0000000008aae1c8 00000000c4149600
0x000000000837f330: 0000000000000001 0000000000000001
0x000000000837f340: 0000000000000010 50bc850a8fa60002
0x000000000837f350: 0000000000000000 0000b74226c117d6
0x000000000837f360: 0000000000000001 00000000012258fa
0x000000000837f370: 00000000c4149600 000000000837f410
0x000000000837f380: 00000000c53922e0 00000000012312a0
0x000000000837f390: 0000000000000001 00000000c53c1f98
0x000000000837f3a0: 0000000008aae000 000000006da91dbd

Instructions: (pc=0x000000006dadf79e)
0x000000006dadf78e: 83 38 02 00 00 06 00 00 00 80 3d 2a ca 41 00 00
0x000000006dadf79e: 48 8b 16 74 17 44 8b 4a 08 0f b6 0d 0a b0 40 00

Stack: [0x0000000008360000,0x0000000008380000], sp=0x000000000837f2b0, free space=124k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x24f79e]

[error occurred during error reporting (printing native stack), id 0xc0000005]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.nio.ch.ServerSocketChannelImpl.accept0(Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;[Ljava/net/InetSocketAddress;)I+0
j sun.nio.ch.ServerSocketChannelImpl.accept()Ljava/nio/channels/SocketChannel;+94
j com.sun.grizzly.TCPSelectorHandler.acceptWithoutRegistration(Ljava/nio/channels/SelectionKey;)Ljava/nio/channels/SelectableChannel;+11
j com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler.acceptWithoutRegistration(Ljava/nio/channels/SelectionKey;)Ljava/nio/channels/SelectableChannel;+2
j com.sun.grizzly.http.SelectorThreadHandler.onAcceptInterest(Ljava/nio/channels/SelectionKey;Lcom/sun/grizzly/Context;)Z+2
J com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(Ljava/nio/channels/SelectionKey;Lcom/sun/grizzly/SelectorHandler;Lcom/sun/grizzly/NIOContext;)Z
J com.sun.grizzly.SelectorHandlerRunner.doSelect(Lcom/sun/grizzly/SelectorHandler;Lcom/sun/grizzly/NIOContext;)Z
J com.sun.grizzly.SelectorHandlerRunner.run()V
j java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V+59
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub



 Comments   
Comment by sb110099 [ 21/Jan/11 ]

Update : jvm bug 7014061 filed by Amy .

--Sudipa

Comment by Nazrul [ 27/Jan/11 ]

Tracking bug. Excluding from un-scrubbed list

Comment by Nazrul [ 01/Feb/11 ]

I am closing this tracking bug. Please re-open the issue if we see issues with RichAccess run.

Comment by sb110099 [ 07/Feb/11 ]

Reopening this bug as we are still seeing the issue with b40.

This is the 3rd time we are able to reproduce the issue on same setup (at SCA) with either SSL or without SSL . (Last update from India: they also saw a crash on Windows setup with b40 and Richaccess+SSL , yet to get more details).

With Abhijit's help, we have a jdk Engineer (Zhengyu Gu) monitoring the last run. He has updated bug http://monaco.sfbay.sun.com/detail.jsf?cr=7014061 with his findings so far .

We are going to restart the run with flag XX:+ShowMessageBoxOnError as advised by Zhengyu for him to be able to attach a debugger.

Thanks,
Sudipa

Comment by Nazrul [ 07/Feb/11 ]

Getting help from Alexey

Comment by sonymanuel [ 07/Feb/11 ]

The crash log and domain.xml from IEC setup is attached.

Comment by oleksiys [ 08/Feb/11 ]

According to the crash reports attached in 7014061, mentioned 4 crashes don't look related.
Two times it happens in
com.sun.messaging.jmq.util.UID.equals(...)

I found the source[1] and it looks like:

124 /**
125 * Equals
126 */
127 public boolean equals(Object obj) {
128 if (! (obj instanceof UID))

{ 129 return false; 130 }

131 return (this.id == ((UID)obj).id);
132 }

don't see anything suspicious, no native calls etc.

Other 2 crashes occur on different places: jmq TransactionReaper and socket accept.

So, IMO, as i told crashes don't look related and probably they are caused by some general JDK/OS issue.

WBR.

[1] http://www.docjar.com/html/api/com/sun/messaging/jmq/util/UID.java.html

Comment by amyk [ 08/Feb/11 ]

For the com.sun.messaging.jmq.util.UID.equals frame in hs_err logs, suggested GlassFish QE to try potential temporary workarounds described in the "Java Trouble-Shooting and Diagnostic Guide" while JVM engineer is looking into the issue (7014061/jvm).

[information from Sony (IEC):
non-SSL run completed 24x7 with JDK 1.6.0_22 64 bit.
SSL - 1 instance crashed on 5th day. 2 instances completed 24x7. JDK used was 1.6.0_23.]

Comment by Chris Kasso [ 24/Feb/11 ]

The test completed with SSL enabled using update 24. If we see the problem again on U24 we can reopen the issue.

Comment by Chris Kasso [ 24/Feb/11 ]

Cannot reproduce on u24





[GLASSFISH-15616] [PERF] Felix getBundle() calls causing performance regressions Created: 19/Jan/11  Updated: 03/Dec/12  Due: 03/Feb/11  Resolved: 03/Feb/11

Status: Closed
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1
Fix Version/s: 3.1_b41

Type: Bug Priority: Blocker
Reporter: Scott Oaks Assignee: Richard S. Hall
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File felix-combined.jar     Java Archive File felix-get-bundle-cache.jar     Java Archive File felix-symname-index.jar    
Issue Links:
Dependency
blocks GLASSFISH-13573 [PERF] Huge regression with trade2 be... Closed
Tags: PSRBUG

 Description   

We are facing performance in object serialization calls through two different paths, each of which ends up calling into felix for bundle information (org.apache.felix.framework.PackageAdminImpl.getBundles() and org.apache.felix.framework.PackageAdminImpl.getBundle()).

The ideal thing would be to fix this by having Felix cache the information for that class directly (and so I am starting with a single bug). Failing that, we will need to modify at least two codepaths in glassfish to overcome this issue. Here are the specifics:

1) Within the ORB, CDRInputStream_1.0.getClassFromString() call to OSGIListener$ClassCodeBaseHandlerImpl.loadClass() which calls org.apache.felix.framework.PackageAdminImpl.getBundles(). The performance of getClassFromString() has regressed by an order of magnitude from 2.1.1, and all of that time is due to the call to getBundles().

2) Within the EJB container, serialization in the EJBObjectOutputStream calls com.sun.enterprise.naming.til.OSGiObjectInputOutputStreamFactoryImpl.annotateClass() which calls org.apache.felix.framework.PackageAdminImpl.getBundle(). That turns out to be a very expensive call, particularly since it is frequent called with a class that is not part of the bundle. Hence, note that this cache needs to be a negative cache – the time is mostly spent from getBundle() calling getClassByDelegation, where the later creates and throws a ClassNotFoundException. getBundle needs to keep track of negative hits and retrn null immediately instead of taking the exception path.

I have done quick-and-dirty caches in the above two paths; it has improved our non-HA trade2 performance by about 5% and our HA trade2 performance by about 12%.



 Comments   
Comment by Richard S. Hall [ 19/Jan/11 ]

What do you mean by, "The ideal thing would be to fix this by having Felix cache the information for that class directly..." ?

For (1) it seems like it should be fairly easy to cache and sort this information.

For (2) you could possibly avoid calling getBundle() if the class' class loader is not an instance of BundleReference, because it is not as costly in that case.

Comment by Scott Oaks [ 19/Jan/11 ]

By "ideal", I mean first that from my parochial point of view, changing one class is easier than changing two, and second I expect that other unknown code paths will call getBundle/getBundles and also benefit from this sort of caching as well. But my point of view could be myopic.

Comment by Richard S. Hall [ 19/Jan/11 ]

You must specifically be referring to (1), because caching for (2) doesn't really make sense. For (1), bundle lookup by symbolic name could be improved by adding a cache.

Comment by Scott Oaks [ 19/Jan/11 ]

I am not specifically referring to 1. If caching doesn't make sense for 2, then is there some other way to improve the performance of 2 so that everyone that calls getBundle can benefit (regardless of whether the class is or is not found)?

Also, I don't believe the suggestion to see if the classloader is an instance of BundleReference will help, because that call is already in org/apache/felix/framework/Felix.getBundle(), and we still get all the classnotfound exceptions from calling into getClssByDelegation.

Comment by Richard S. Hall [ 19/Jan/11 ]

For the most part, getBundle() largely just checks to see if the class' class loader is an instance of BundleReference and if so, calls BundleReference.getBundle() to get the Bundle associated with the class loader. There are a few sanity checks in there to make sure the bundle is from the same framework as the Package Admin service, but otherwise that's it.

The only costly part is if you are asking for classes that do not come from a bundle, in particular, from the system bundle (i.e, the JRE), in which case it checks to see if the class is actually exported by the system bundle. This last part could potentially be converted to a simple package name check rather than an actual class load, but that could lead to some issues...I'd have to think about it.

Regarding checking for BundleReference, the getClassByDelegation() is only called if the class' class loader is NOT a BundleReference. So, there is only one other place the class could be coming from if it isn't coming from a Bundle...that would be the system bundle (which is typically the class path).

Comment by Sanjeeb Sahoo [ 20/Jan/11 ]

I will let Richard investigate first.

Comment by Richard S. Hall [ 20/Jan/11 ]

The attached JAR file includes a cache for PackageAdmin.getBundle() only. Please see if this makes a difference. To test it, overwrite felix.jar in your GF installation.

Comment by Richard S. Hall [ 24/Jan/11 ]

The felix-symname-index.jar attachment adds an index for bundle retrieval by symbolic name. Replace felix.jar in your GF installation to use it. This patch is not 100% done, since it has a corner case that still needs to be addressed, but it should be ok for testing purposes.

Comment by Richard S. Hall [ 24/Jan/11 ]

The felix-combined.jar attachment has both the getBundle() cache and the symbolic name index. Replace felix.jar in your GF installation to test it.

Comment by Richard S. Hall [ 24/Jan/11 ]

I have updated felix-symname-index.jar and felix-combined.jar, since there was a potential NPE if a bundle doesn't specify a symbolic name. The old JARs passed the OSGi CT, but I'm updating them here to be safe. Again, the symbolic name index is not 100% complete yet, but should be good enough for testing.

Comment by Scott Oaks [ 25/Jan/11 ]

Here are test results of my testing of the patches: total improvement with the combined patch is 11.77%. When we account for the trade2 variation, we start out 10.5 - 11.5% behind.

==============================================================================
/export/trade2_logs/sdo.jan21/logs.311.ha:
Benchmark Samples Mean Stdev
trade2_inmem 2 9581.32 91.18
==============================================================================
/export/trade2_logs/sdo.jan21/logs.311.ha.combined:
Benchmark Samples Mean Stdev %Diff
trade2_inmem 3 10709.29 98.41 11.77
==============================================================================
/export/trade2_logs/sdo.jan21/logs.311.ha.bundle:
Benchmark Samples Mean Stdev %Diff
trade2_inmem 17 10583.94 41.96 10.46
==============================================================================
/export/trade2_logs/sdo.jan21/logs.311.ha.symname:
Benchmark Samples Mean Stdev %Diff
trade2_inmem 3 9712.95 74.20 1.37 0.238
==============================================================================

Comment by Richard S. Hall [ 25/Jan/11 ]

Given the numbers, I'd be inclined to not add the symbolic name index since it appears to have little impact. It is better to avoid code complexity unless there is good reason to add it.

Comment by Richard S. Hall [ 03/Feb/11 ]

I have integrated Felix 3.0.8 into trunk and the 3.1 branch to address this issue. The new version of Felix includes a weak hashmap cache for system bundle classes in PackageAdmin.getBundle(). This release does not include the symbolic name index since the minimal improvement was not deemed worth the complexity.

QuickLook tests all passed for me. Please close this issue if you are satisfied.





[GLASSFISH-466] JBI - Java EE Service Engine: java.lang.NoClassDefFoundError: com/sun/jbi/wsdl11wrapper/Wsdl11WrapperHelper Created: 23/Mar/06  Updated: 23/Mar/06  Resolved: 23/Mar/06

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 9.0pe
Fix Version/s: 9.0pe

Type: Bug Priority: Blocker
Reporter: gopalan Assignee: mu125243
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 466

 Description   

Using:
GlassFish Build 41
OpenESB 1 M8 Build 060217_2

We have a scenario where a BPEL JBI Service Engine is trying to invoke an EJB
Web Service whose endpoints are activated in the JBI NMR by the Java EE Service
Engine. The invocation never returns an is stuck at the Java EE side with a
java.lang.NoClassDefFoundError.

This particular bug is blocking us for the demo that we are trying to prepare
for Java One. This demo would showcase the Java EE Service Engine so we are very
keen on getting it working.

[#|2006-03-23T00:36:38.720-0800|SEVERE|sun-appserver-pe9.0|javax.enterprise.system.container.ejb|_ThreadID=28;_ThreadName=p:
thread-pool-1; w:
2;_RequestID=857e1a5c-ff13-4b28-b1d8-54b177380f62;|serviceengine.error_incoming_request

java.lang.NoClassDefFoundError: com/sun/jbi/wsdl11wrapper/Wsdl11WrapperHelper

at
com.sun.enterprise.jbi.serviceengine.util.soap.MessageExchangeHelper.unWrapMessage(MessageExchangeHelper.java:183)

at
com.sun.enterprise.jbi.serviceengine.util.soap.MessageExchangeHelper.denormalizeMessage(MessageExchangeHelper.java:97)

at
com.sun.enterprise.jbi.serviceengine.bridge.JAXRPCMessageProcessor.doWork(JAXRPCMessageProcessor.java:89)

at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:440)

#]


 Comments   
Comment by gopalan [ 23/Mar/06 ]

Created an attachment (id=174)
The server logs

Comment by mu125243 [ 23/Mar/06 ]

With glassfish build 41 and latest openESB build dated Mar 14th mainline kit, I
don't get this error message. Please note that the build that you are using is
almost a month old. Could you try it with latest build ?

Comment by mu125243 [ 23/Mar/06 ]

The openESB build you are using is very old, use the latest Mar 14th .

Regards,
Manisha.

Comment by mu125243 [ 23/Mar/06 ]

Got following email from Gopalan,closing the bug.
Hello Manisha

Thanks I have the scenario working with the March 14th build of OpenESB(1.M9,
build 060314_7) and GlassFish build 41.

Last night I was using GlassFish build 41 and OpenESB(1.M8, build 060217_2)

The BPEL SE can now invoke an EJB deployed on GlassFish b41 and get a successful
response.

Thanks once again.

Cheers
Gopalan.





[GLASSFISH-4069] Sun Java System Application Server 9.1 (build b58g) "out of bound memory" Created: 04/Feb/08  Updated: 13/Feb/08  Resolved: 13/Feb/08

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: 9.1.1
Fix Version/s: 9.1.1

Type: Bug Priority: Blocker
Reporter: hobione Assignee: mukesh_garg
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://faa.gov


Issuezilla Id: 4,069

 Description   

Hi:
My organization just installed Sun Application Server 9.1 in the production; we
are having an issue with memory out of bound.
http://forums.java.net/jive/thread.jspa?threadID=36239&tstart=0

Is it a bug or do I need to increase default heap size from 192 to 512?
Should we go ahead uninstall 9.1 and go with Glassfish v2 UR1?

Please advise. By the way, I also would like to add my organization name under
Who is using Glassfish, how do I do that?

Thanks
Hobi



 Comments   
Comment by harpreet [ 13/Feb/08 ]

This issue is fixed in 9.1.1. Follow the forum thread where the reporter has confirmed that it is not
reproducible in 9.1 Update 1. Marking the issue as "invalid" for 9.1.1.

Comment by harpreet [ 13/Feb/08 ]

This issue is fixed in 9.1.1. Follow the forum thread where the reporter has confirmed that it is not
reproducible in 9.1 Update 1. Marking the issue as "invalid" for 9.1.1.





[GLASSFISH-16636] Web Monitoring Tests Broken in 3.1.1 -- Sometimes Created: 14/May/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1
Fix Version/s: 3.1.1

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

Issue Links:
Dependency
blocks GLASSFISH-16650 Admin DevTests Umbrella Resolved
Tags: 3_1_1-approved

 Description   

See the 3.1.1 Admin DevTests. They are breaking on "totalservletsloaded"

Here is the email I sent out to Admin alias about this -->

I'm trying to figure out automated tests we have for Web Monitoring. This makes no sense to me. Does it make sense to you?

Scenario:
I create a cluster with 2 instances.
Deploy HelloWeb to the cluster
start the 2 instances.
i1.applications.HelloWeb.server.totaljspcount-count = 0
Hit the webapp, on i1, in a browser.
i1.applications.HelloWeb.server.totaljspcount-count = 1

That makes sense. the count never changes again.

Now hit the web app on i2
i2.applications.HelloWeb.server.totaljspcount-count = 2

Whoa! Unexpected! It talked to the other instance and knew it should set it to 2? The 2 never changes

Meantime:
i1.applications.HelloWeb.server.totalservletsloadedcount-count = 0
i2.applications.HelloWeb.server.totalservletsloadedcount-count = 2

These values never change. i1 has no servlets loaded? i2 has 2 servlets loaded? What are we testing here? This seems really weird. Is it a bug or a feature?

Then I deployed a different simple app to DAS. Then a copy of that same app to the cluster.
DAS has servlets loaded count set to 3. For exactly the same app, i1 has the servlets loaded count set to 0



 Comments   
Comment by Byron Nevins [ 14/May/11 ]

I ran the entire dev-tests on my Windows machine. *ALL* of the web tests passed. I got one failure which ironically is the new test added by Carla in svn#46789:

create-instance-offline-config-install-dir

Comment by scatari [ 16/May/11 ]

Approved for 3.1.1 as one of the criteria has been 100% of all of admin dev. tests passing.

Comment by Byron Nevins [ 16/May/11 ]

I had an old build. This was not an issue...





[GLASSFISH-16606] asadmin enable-secure-admin will not work on additional domains Created: 11/May/11  Updated: 11/May/11  Resolved: 11/May/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: deathtooracle Assignee: Tim Quinn
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any



 Description   

We have 2 independant domains running on the same server, domain1 was created by the installer and the domain 'ad' through:
/opt/glassfish3.1/bin/asadmin create-domain --portbase 4900 --savemasterpassword=true ad
Now,
/opt/glassfish3.1/bin/asadmin enable-secure-admin
does not let one choose which domain to secure, instead it always uses domain1 (port 4848). That means, we cannot secure the admin GUI on domain ad.
We have a high security environment here where unsecured / clear-text admin GUIs are forbidden. So, we cannot use glassfish 3.1 until this bug is resolved.

Please fix or provide us with a working workaround.



 Comments   
Comment by Tim Quinn [ 11/May/11 ]

As with any asadmin command, you must specify the correct admin port on the enable-secure-admin command in order for asadmin to connect to the domain you want.

The default is 4848. You need to specify the correct admin port for your second domain explicitly, using

asadmin --host hostName --port portNumber rest-of-command

The default hostName is the same host where you run the asadmin command, so that part is optional if that's what you want to do.

Comment by deathtooracle [ 11/May/11 ]

Excellent, thank you very very much.





[GLASSFISH-15956] man page: remove --upgrade option from start-local-instance Created: 10/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b41
Fix Version/s: 3.1

Type: Bug Priority: Blocker
Reporter: Nazrul Assignee: Paul Davies
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved

 Description   

Filing this bug since we are fixing man pages.

%asadmin start-local-instance --help shows --upgrade option. Please remove it.

Refer to http://java.net/jira/browse/GLASSFISH-15851



 Comments   
Comment by Paul Davies [ 11/Feb/11 ]

Duplicate of GLASSFISH-15947





[GLASSFISH-15895] enable-monitoring command is broken for clusters and instances Created: 08/Feb/11  Updated: 01/Apr/11  Resolved: 09/Feb/11

Status: Closed
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1_b41
Fix Version/s: 3.1_b42

Type: Bug Priority: Blocker
Reporter: Harshad Vilekar Assignee: Byron Nevins
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File diffs.txt     Java Archive File flashlight-framework.jar    
Tags: 3_1-approved, 3_1-verified, added-devtest

 Description   

No resource monitoring data is displayed on Admin GUI - when the JMS connection Factory is created with target = cluster. Same issue with CLI.

Steps:

  • create and start three instance cluster:

$ asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 11368 c1 running
in1 localhost 58077 11367 c1 running
in3 localhost 8619 11369 c1 running
Command list-instances executed successfully.

  • Enable Monitoring for the cluster
  • asadmin create-jms-resource --target c1 --restype javax.jms.QueueConnectionFactory jms_QCF
  • asadmin list-jms-resources c1 | grep jms_QCF
    jms_QCF
  • create new physics destination: myQ (target = c1)
  • asadmin list-jmsdest c1

mq.sys.dmq
myQ
Command list-jmsdest executed successfully.

  • asadmin get -m "in1.*" | grep jms_QCF

Newly created JMS resource is not listed.

Also see earlier reported issue: http://java.net/jira/browse/GLASSFISH-14132



 Comments   
Comment by Harshad Vilekar [ 08/Feb/11 ]

This works fine for target = server. Use these additional steps on Admin Console:

1. Resources - JMS Resources - Connection Factories - jms_QCF - Target - Manage Targets - server - Add- Save

2. Resources - Connection Connection Pool - jmsQCF - Ping (not sure if this is needed)

3. Enable Monitoring: server-config - Monitoring - Level - High (for all) - Change Level - Save

4. Server - Monitor - Resources - View - jms_QF

Comment by Nazrul [ 08/Feb/11 ]

If enable-monitoring (and disable-monitoring) is broken for target=cluster, we will need a fix for this.

Comment by Byron Nevins [ 08/Feb/11 ]

Lots of misleading and complicated info on this Issue including the summary.

I'm changing it to reflect the real problem which is that enable-monitoring is not working correctly for clusters and instances.

Comment by Byron Nevins [ 08/Feb/11 ]

Work-around

Example for Windows

call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.orb=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH

call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.connector-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.http-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jms-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jvm=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.orb=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.transaction-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.web-container=HIGH

Comment by Byron Nevins [ 08/Feb/11 ]

Very simple & easy problem and fix. Here is another example of how not having devtests is expensive!!

Final Analysis:
It was always using the MonitoringService of DAS

Fix:
Use the correct MonitoringService!

The way it works is you, say, call DAS and tell it to turn on dtrace for cluster c1. DAS writes the change to the c1-config. Then DAS calls all the instances in the cluster. If any of them happen to be running then they do precisely the same thing that DAS just did on their own personal copy of domain.xml. If they are not running then they will get the change the next time they sync up.

I'll attach the diffs...

Comment by Byron Nevins [ 08/Feb/11 ]

These are the diffs for the fix

Comment by Byron Nevins [ 09/Feb/11 ]

Summary:
It's really a minor gaff. The problem is that it wasn't detected until now. When you run the command – DAS will ALWAYS change its own config exclusively and completely ignore the target. If the instance(s) happen to be running - they will adjust their own config correctly. As soon as the instances restart they will sync and lose the correct config. Meantime DAS has incorrect monitoring config.

This results in a very puzzling situation for the user – just look at the original description and comments on this bug to see what I mean.

========================
1. How bad is its impact? (Severity)
The impact is bad. Very bad. The fix is trivial and has no risk at all.

  • Identify why the fix needs to occur now:
    o Likely to generate a customer support call
    o Significantly impacts the operation of a primary release driver feature (clustering)

2. How often does it happen? (Frequency)
100%

3. How much effort is required to fix it? (Cost)
Zero cost – I have a fix ready to go. It is trivial and the diffs are attached to this issue.

4. What is the risk of fixing it? (Risk)
No risk. It is already 100% broken. It would be difficult to make it worse.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes and yes. It is the usual answer for any fouled-up command that exclusively sets config – the work-around is to use the low-level "set" command.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Definitely. But that would be a lot more work than fixing it. The bug is 100% contained. This is a pretty simple command that simply changes config. None of the business-end of the code is touched. All I had to change is to get the MonitoringService config object based on the target – rather than always injecting the one in the DAS config. Literally a few lines of code.

7. How long has the bug existed in the product?
At all times post 3.0

8. Do regression tests exist for this issue?
No. Monitoring DevTests are being developed furiously right now. This issue can be added right away.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Probably not necessary. Unfortunately there must have been no tests at all otherwise this would have been immediately detected.
Simple manual tests are all that is required. Namely, enable-monitoring for DAS, then for a cluster then a stand-alone cluster. Examine domain.xml for correct changes. Do this before and after the changes. I've already done this methodically.

Direct answer: It can't possibly destabilize GlassFish – it is 100% broken now.

10. When will a tested fix be ready for integration?
Within moments of its approval and review.

Comment by Byron Nevins [ 09/Feb/11 ]

Note to code reviewers –

In the code before the change, the MonitoringService object is injected. It is not checked. It could conceivably be null.

The fix does this:

ms = targetService.getConfig(target).getMonitoringService();

target is GUARANTEED to be a valid target by CommandRunner. Could that config have a null MonitoringService? Yes – but that would mean the user edited out of domain.xml himself and is asking for trouble. Our infrastructure can handle the NPE that would result in that unlikely case.

We could make the error detection and handling more explicit and obvious but I avoided it to make the smallest possible change.

Adding code to produce error messages is to be avoided – this code is already trying to load strings from a localstrings file that does not exist. But I can do it at the cost of a few hours.

Comment by Jennifer Chou [ 09/Feb/11 ]

Question for the JMS folks....

.....unrelated to the bug in enable-monitoring....assume you have turned on monitoring successfully using either asadmin set or Admin Console (not enable-monitoring), when you Ping the jms_QCF (jmsra and javax.jms.QueueConnectionFactory) that is enabled on c1, should this display the JMS monitoring statistics for c1? If not, how can we see the JMS statistics on c1?

Currently, aftering pinging jms_QCF on DAS (server), the JMS monitoring statistics are displayed.
But, after pinging jms_QCF on c1, the JMS monitoring statistics are not displayed.

Comment by Jagadish [ 09/Feb/11 ]

Jennifer has sent me an email about this issue.

In order to see the monitoring statistics for a pool, the pool need to be initialized.
In DAS, ping-connection-pool will start showing the statistics.
Note : ping-connection-pool is applicable only for DAS.

For non-DAS instances, application need to access the pool once so that the pool is initialized which in-turn will register to monitoring registry to start collecting monitoring statistics. I have sent the steps to Jennifer that shows the monitoring statistics of a connector-connection-pool in a clustered instance.

Comment by Nazrul [ 09/Feb/11 ]

Approved for checkin pending the following activities:

  • Code review
  • Validate that the original reported issues is fixed
  • We have Dev Test(s) for this
  • disable-monitoring with target=cluster is also working
  • Validate that there are no regressions due to this checkin
Comment by Jennifer Chou [ 09/Feb/11 ]

Harshad,

Can you please verify that the original reported issue (without using enable-monitoring) is working with the additional step of accessing the pool as Jagadish had described above? I will send you the the steps for connector-connection-pool.

Comment by Harshad Vilekar [ 09/Feb/11 ]

> For non-DAS instances, application need to access the pool once so that the pool is initialized

Monitoring data looks good after the addition steps (similar to the steps suggested by Jagadish) are executed.

Comment by Byron Nevins [ 09/Feb/11 ]

D:\gf\v3\flashlight\framework\foo\framework>svn commit
Sending src\main\java\org\glassfish\flashlight\cli\DisableMonitoring.java
Sending src\main\java\org\glassfish\flashlight\cli\EnableMonitoring.java
Transmitting file data ..
Committed revision 45029.

==============
45028 was the same but checked into the trunk
==============

List of prerequisites from Nazrul and my answers:

  • Code review
    • Jennifer and Tom
  • Validate that the original reported issues is fixed
    • done by Jennifer
  • We have Dev Test(s) for this
    • 360 new tests
  • disable-monitoring with target=cluster is also working
    • Yes – also fixed and tested
  • Validate that there are no regressions due to this checkin
    • I did a lot of automated and manual testing. Homer reports that the 2 commands are not used by any QA tests.
Comment by Harshad Vilekar [ 21/Feb/11 ]

Original issue was verified on B42.





[GLASSFISH-15881] [Intermittent] appclient hangs during dynamic cluster issue Created: 07/Feb/11  Updated: 20/Feb/11  Due: 13/Feb/11  Resolved: 15/Feb/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b40
Fix Version/s: 3.1_b42

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

Attachments: Text File kernel-15881.patch     Java Archive File kernel.jar     Java Archive File kernel.jar     GZip Archive threaddump.tar.gz    
Tags: 3_1-approved, 3_1-verified

 Description   

This issue is seen intermittently

Since its a serious issue, I am filing a Blocker

This happens only on Solaris sparc platform

Scenario:
This issue happens when we run appclient with endpoints specified

I am reproducing the issue and providing environment to Tim Quinn for debugging



 Comments   
Comment by Tim Quinn [ 07/Feb/11 ]

Gopal,

Can you now reproduce this at will?

Have you been able to get a thread dump? This will be critical for us to progress on this.

Comment by gopaljorapur [ 07/Feb/11 ]

I can not reproduce this issue at will.

Though, occurances of hang is very high, we have seen it many times in our environment, I am trying to reproduce now, will give you the setup once I do

Comment by Chris Kasso [ 08/Feb/11 ]

It would be useful to capture in the issue which version of Solaris the problem has been seen on as well as specifics around how the cluster was changed. How many instances did you start with and how many did you add?

Can you also better characterize how often the issue is seen?

Once you start seeing the problem does each successive run of the appclient see the problem or does it remain intermittent?

Comment by gopaljorapur [ 08/Feb/11 ]

Its Solaris 10 Niagara SunFire T2000 machine

To start with we have 8 instances in the cluster, I add two instances later

Can you also better characterize how often the issue is seen?

  • The issue is seen 4-5 times

Now I am trying to reproduce, its not happening since 1-2 hrs

Once you start seeing the problem does each successive run of the appclient see the problem or does it remain intermittent?

  • It remains intermittent
Comment by Nazrul [ 08/Feb/11 ]

Spoke to Gopal today. He is unable to re-produce the issue (he is trying). I am excluding the issue for now from 3.1. If we can re-produce it, we will take a look.

Comment by gopaljorapur [ 08/Feb/11 ]

Finally, I am able to reproduce the issue

appclient is in hang state, I will send system info to Tim to check process state

I am trying to get thread dump, but its throwing following error

jstack -l 15269
15269: Unable to open door: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
root@bigapp-niagara-1 # jstack -F 15269
Attaching to process ID 15269, please wait...
Error attaching to process: Did not find libthread in target process/core!

Please remove 3_1-exclude tag

Comment by gopaljorapur [ 09/Feb/11 ]

Thread dump

Comment by Ken Cavanaugh [ 09/Feb/11 ]

From the ORB viewpoint, the only CORBA activity in any of the dumps is a waiting getClusterInstanceInfo
request in the appclient. This request is apparently for the first InitialContext creation, which happens
through a long chain of hk2 startup code triggered from app client initialization. It's apparent (since
there is no corba activity at all in any of the instances) that this request is not being handled, but it
also did not get an error. I think lazy init is used by defaujlt, because otherwise the getClusterInstanceInfo
would have failed with a connection error (since there is no sign of a CORBA selector thread that would be
listening for new ACCEPT events). Therefore the lightweight listener is active each server instance
and at least allowed the client to make a connection to a server instance.

Is it possible that somehow the lightweight listener (com.sun.enterprise.v3.service.impl.ServiceInitializerHandler)
lost the request from the client, and failed to start the ORB (clearly there is no ORB running in any
of the servers, since there are not ORB threads present in the thread dumps)? We may need help from
someone on the Grizzly team with this.

Comment by Tim Quinn [ 10/Feb/11 ]

[from Alexey's e-mail]

Hi guys,

Ken, absolutely agree with your comments, looks like the problem is in ServiceInitializerHandler... though as connection is getting accepted (not refused) - it means it's running, but the question is what happens then? Why Corba container is not getting started?

Is there any way to reproduce the issue? Some machine(s) + instructions available?

Thanks.

WBR,
Alexey.

Comment by Tim Quinn [ 10/Feb/11 ]

Because Alexey is currently investigating this problem further, I've transferred this issue to him.

Comment by Tim Quinn [ 10/Feb/11 ]

[From e-mail with Ken]

Tim: IIRC, the client ORB will randomize which endpoint it will use for bootstrapping.

Ken: That's correct.

Tim: And then once bootstrapped a given request for an EJB will be randomized among the currently-active server-side ORBs? (but is sticky once a given EJB is accessed from a given client)

Ken:Correct.

Tim: ...at some point the client is trying to bootstrap to an ORB or, having successfully bootstrapped, is trying to communicate with an EJB on a server but one or the other pathway is non-responsive.

ken: Yes, but from the stack trace, it is the first call from the client to the ORB, and unfortunately, the request neither
succeeds nor fails: it gets lost in limbo. The client will timeout in 30 minutes (which may as well be forever).

Tim: Is there client ORB logging he should turn on so we can tell which ORB is used for bootstrapping, whether bootstrapping succeeds, which ORB is used for the EJB, etc.?

Ken: Yes: turn on FINE logging for the javax.enterprise.system.core.naming logger. That will spit out various
somewhat obscure messages, but I think it will tell you what you want to know.

Comment by oleksiys [ 11/Feb/11 ]

hopefully the fix

Comment by oleksiys [ 11/Feb/11 ]

better fix

Comment by oleksiys [ 11/Feb/11 ]

diff patch

Comment by oleksiys [ 11/Feb/11 ]

The attached diff contains the fix for the lazy service initialization block.

The problem was that even though the lazy service initialization was running inside synchronized block, the reference to the service became available before the actual targetInitializer.initializeService() was called.
So there was a possibility for the newly accepted connection to be passed to the not initialized service, which might lead to unexpected issues depending on timing.

Comment by oleksiys [ 11/Feb/11 ]

diff

Comment by Ryan Lubke [ 11/Feb/11 ]

Alexey and I were talking about the attached changes prior to the meeting.
I'm OK with the changes. They are relatively minor.

Comment by Ryan Lubke [ 11/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature

How often does it happen? (Frequency)
issue is intermittent - depends on timing

How much effort is required to fix it? (Cost)
minimal (see attached patch)

What is the risk of fixing it? (Risk)
minimal - fix is straight forward.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?
Since 3.0 - but the issue surfaced during HA testing which wasn't done in 3.0.

Do regression tests exist for this issue?
No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
HA testing.

When will a tested fix be ready for integration?
2/11/2011

Comment by Ken Cavanaugh [ 11/Feb/11 ]

One thing I don't understand here: why is targetInitializer present at all (as a data member rather
than a local)?
This looks like an attempt to cache the targetInitializer, so that subsequent
calls to onAccept would run faster. But that seems to be incorrect: subsequent
calls to onAccept could be for different services.

Comment by Chris Kasso [ 11/Feb/11 ]

Approved for RC3 pending:

1) Resolving all code review comments. See Ken's comment in the issue.
2) I would like Gopal to confirm the patch fixes 15881.
3) A better understanding of where QA should focus testing. MQ/IIOP?
4) What tests have development performed to verify the fix does not introduce any regressions?

Comment by Ryan Lubke [ 11/Feb/11 ]

I believe it's currently designed such that there will be one ServiceInitializerThread/ServiceInitializerHandler per listener/service.

Comment by Ryan Lubke [ 11/Feb/11 ]

Patched kernel.jar

Comment by Ken Cavanaugh [ 11/Feb/11 ]

Ryan's comment makes sense to me. I thought of the same thing later,
after I made my previous comment.

Comment by Ryan Lubke [ 11/Feb/11 ]

Alexey's patch has been applied (r45070).

Will wait for Gopal's confirmation on his end before marking this as resolved.

Comment by Ryan Lubke [ 14/Feb/11 ]

Update from Gopal on 2/13/2011:

Hi Chris/Ryan,

The full HA run on the patch is not complete, yet

But, with whatever results we have, I dont see a hang (2 times full IIOP run is completed), also I dont see any regression issues (so far)

Comment by gopaljorapur [ 14/Feb/11 ]

We are using RC2 + Patch for verification of patch on a 4 machine 10 instance cluster

Since we are doing thorough verification of the issue, it is taking time to complete verification

Complete IIOP suite was run for 3 times to make sure hang is gone and no other regression is introduced, this happened till saturday evening (13th Feb)

From night of Feb 13, we have started the whole HA Suite , the run is still going on, 90% of the run is complete, so far, so good, no regressions, no hang seen

Comment by gopaljorapur [ 15/Feb/11 ]

hang is not seen, No regression seen with the patch, the issue can be marked as fixed





[GLASSFISH-15816] [PERF] performance regression in IIOPInputStream.simpleReadObject Created: 03/Feb/11  Updated: 03/Dec/12  Resolved: 07/Feb/11

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

Type: Bug Priority: Blocker
Reporter: Scott Oaks Assignee: Mitesh Meswani
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Tags: PSRBUG

 Description   

The performance of IIOPInputStream.simpleReadObject is
some 3x slower in GF 3.1 v GF 3 in client-side profiles.

In V3, that just calls IIOPInputStream.inputObject().

In V3.1, that spends a little more than half its time in inputObject(),
and the other large part of its time in inputObjectUsingFVD(). V3 and
V3.1 do spend the same amount of time in useFullValueDescription() (a
pretty small amount in either case).

So it seems that for whatever reason, we are using the FVD in 3.1 and
not in V3, and that is really slowing us down. We need either a way to
turn of FVD or to improve the performance of that path.

The performance of inputObject() itself also seems to have regressed,
but I think that's because inputObjectUsingFVD() calls it; once we get
recursive calls, it's hard to tell from the profile.



 Comments   
Comment by Ken Cavanaugh [ 03/Feb/11 ]

I think the main reason the FVD is slower is because of the sender.meta calls in getOrderedDescriptions.
This is a remote callback to the client, and that alone will prevent any significant performance optimization.
I don't think caching is easy here either, because essentially we would need to cache
(repositoryID X CodeBase) -> List<FullValueDescription>, and the CodeBase is a CORBA object reference,
which has very weak equals semantics (we can't always decide whether or not two remote references are
equals, through perhaps in this case I could force that). We also have the problem that sender
is a transient object, and will change for every client and every re-start of a client. And restarting
a client is an opportunity for the remote type to change.

I think the real question is why are we using the FVD now? This is determined by
ValueHandlerImpl.useFullValueDescription( Class cls, String repoId ), which determines the
repoId of cls, and if it is different from repoId, returns true. The repoId contains an
RMI hash value, and the serialVersionUID of the class. If either of these are different,
it will force the use of the FVD. So what changed between 3.0 and 3.1?

One small possibility: if the class is an enum, bug 6877056 required a change to the suid: it is
now 0 instead of whatever it was previously.

Some questions:

  • How many times per request is sender.meta called?
  • Are there any enums in the test?
  • Which benchmark does this affect, and by how much?

I can't fix this for RC2, and RC3 may be difficult as well.

Comment by Nazrul [ 03/Feb/11 ]

This affects SpecJ benchmark (part of the exit criteria).

Comment by Ken Cavanaugh [ 03/Feb/11 ]

If this is needed for RC 3, I need more information as soon as possible.
If we cannot avoid the use of the FVD, it will probably not be possible to fix for RC 3.

Comment by Scott Oaks [ 03/Feb/11 ]

The class that is being treated as FVD is org.spec.jent.ejb.mfg.entity.WorkOrder. In RepositoryID.useFullValueDescription() I printed out the clazzRepIDStr and repositoryID: RMI:org.spec.jent.ejb.mfg.entity.WorkOrder:2278B9E1654056DF:DB5326CCDA5E594A
RMI:org.spec.jent.ejb.mfg.entity.WorkOrder:0D0763E46FEF1DB9:DB5326CCDA5E594A

Where do the repository IDs come from? The client is loading that class from the same jar file that was deployed to the server (and there are several other classes in that jar file that I see in the useFullValueDescription() method and the repository IDs match; it is just this one particular class). On the other hand, in the server that class goes through JPA injection (the only transferred class that does that); maybe that seems to change the class definition? That also happened in V3, though I guess the injection could be different.

Comment by Ken Cavanaugh [ 03/Feb/11 ]

The repository ID is of the form RMI:<class name>:<hash code>:<suid>. Here we are
only interested in the <hash code> differences.

The hash code is computed as follows (from the CORBA 3.1 spec section 14.7.2):

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

An RMI Hashed RepositoryId consists of either three or four components, separated by colons:

RMI: <class name> : <hash code> [ : <serialization version UID> ]

The class name is a Java class name as returned by the getName method of java.lang.Class. Any characters not in
ISO Latin 1 are replaced by “\U” followed by the 4 hexadecimal characters (in upper case) representing the Unicode
value.

For classes that do not implement java.io.Serializable, and for interfaces, the hash code is always zero, and the
RepositoryID does not contain a serial version UID.

For classes that implement java.io.Externalizable, the hash code is always the 64-bit value 1.

For classes that implement java.io.Serializable but not java.io.Externalizable, the hash code is a 64-
bit hash of a stream of bytes (transcribed as a 16-digit upper case hex string). An instance of
java.lang.DataOutputStream is used to convert primitive data types to a sequence of bytes. The sequence of
items in the stream is as follows:

1. The hash code of the superclass, written as a 64-bit long.

2. The value 1 if the class has no writeObject method, or the value 2 if the class has a writeObject method,
written as a 32-bit integer.

3. For each field of the class that is mapped to IDL, sorted lexicographically by Java field name, in increasing order:
a. Java field name, in UTF encoding
b. field descriptor, as defined by the Java Virtual Machine Specification, in UTF encoding.

The National Institute of Standards and Technology (NIST) Secure Hash Algorithm (SHA-1) is executed on the stream of
bytes produced by DataOutputStream, producing a 20 byte array of values, sha[0..19]. The hash code is assembled
from the first 8 bytes of this array as follows:

long hash = 0;
for (int i = 0; i < Math.min(8, sha.length); i++)

{ hash += (long)(sha[i] & 255) << (i * 8); }

For Serializable (including Externalizable) classes, the Java serialization version UID, transcribed as a 16 digit upper-case
hex string, shall be appended to the RepositoryId following the hash code and a colon. The Java serialization version
UID is defined in the Java Object Serialization Specification.

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

This is computed in the ObjectStreamClass.computeStructuralUID method.
There are changes that can be made to a class that change the hash code, but not the suid.
For example, the presence or absence of a writeObject method affects the hash code, but not
the suid. Obviously any change in serializable fields would also affect the computations.
Does the WorkOrder class explicitly define its serialVersionUID?

Not sure if the injection changed, perhaps Mitesh might know?

Comment by Nazrul [ 07/Feb/11 ]

Based on latest analysis, this issue is happening due to the new JPA weaving feature. So, assigning to Mitesh.

Comment by Scott Oaks [ 07/Feb/11 ]

The difference in client and server side classes is that the server-side classes are subject to weaving to support new JPA features; the weaving adds new non-transient fields to the class definition.

As we do not (presently) need these features, we are able to turn off the weaving and get the class definitions to match. This gets rid of the client-side performance issue with simpleReadObject(). This may not be viable for other applications which need to use weaving features in a CORBA environment. Theoretically, the client side class could also be woven in that case, except that the necessary classes to do that do not ship with glassfish.

Comment by Scott Oaks [ 07/Feb/11 ]

Using new properties in persistence.xml to turn off weaving.





[GLASSFISH-15783] change-admin-password command changes password with any dummy value. Created: 01/Feb/11  Updated: 21/Feb/11  Due: 03/Feb/11  Resolved: 02/Feb/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b40
Fix Version/s: 3.1_b41

Type: Bug Priority: Blocker
Reporter: shaline Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris Sparc 10


Tags: 3_1-approved, 3_1-verified

 Description   

GF build used: promoted b40.

Create a domain with user name and password. Using asadmin change-admin-password command we can change the adminpassword just by proving a dummy password value.

steps:
Create a domainby proving username/password .
Start domain1

Issue some CLI, like list-jdbc-connection-pools where in username/password should be provided.
command succeeds and lists the pools.

bash-3.00# ./asadmin change-admin-password

Enter admin user name [default: admin]> admin
Enter admin password> [ENTER any dummy value (dummypass)]
Enter new admin password> [Enter the value we want ( adminadmin)]
Enter new admin password again> [adminadmin]
Command change-admin-password executed successfully.

bash-3.00# ./asadmin list-jdbc-connection-pools
Enter admin user name> admin
Enter admin password for user "admin"> [adminadmin]
__TimerPool
DerbyPool
Command list-jdbc-connection-pools executed successfully.



 Comments   
Comment by Chris Kasso [ 01/Feb/11 ]

Updating to P1 given this is a security issue.

Comment by Tom Mueller [ 02/Feb/11 ]

Tim, can you please take a look at this? There is a local change-admin-password command that prompts for the username, the old password, and the new password. This command then uses the ServerRemoteAdminCommand class to run a remote change-admin-password command on the DAS that saves the admin password. The remote command doesn't look at the old password at all, even though it is passed in.

The ServerRemoteAdminCommand constructor accepts a password argument (the old password), but that argument is ignored.

So the bottom line is that in the change-admin-password command, the old password value that is entered by the user is ignored completely. However,the command works and the password is changed. Should the local change-admin-password command not be using the ServerRemoteAdminCommand class?

Comment by Tim Quinn [ 02/Feb/11 ]

In an earlier change (long ago) I incorrectly changed the use of RemoteAdminCommand to ServerRemoteAdminCommand thinking that this class ran inside the DAS.

Changing it to use RemoteAdminCommand fixes this.

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Impacts product security
  • Is a regression of functionality or performance available in a prior release
  • Likely to generate a customer support call

How often does it happen? (Frequency)
any time a user changes the admin password; the actual password is not needed

How much effort is required to fix it? (Cost)
minimal

What is the risk of fixing it? (Risk)
very low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
no workaround

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?
since Oct. 27, 2010

Do regression tests exist for this issue?
might be included in Shaline's tests

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
some that depend on non-default admin user/passwords

When will a tested fix be ready for integration?
upon approval (ready in my workspace)

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Tim Quinn [ 02/Feb/11 ]

Fix checked in to trunk and 3.1 branch.

Project: glassfish
Repository: svn
Revision: 44833
Author: tjquinn
Date: 2011-02-02 23:15:16 UTC
Link:

Log Message:
------------
Fix for 15783

Because this class runs in asadmin (and not in the DAS), it should use RemoteAdminCommand instead of ServerRemoteAdminCommand.

Approved: Chris
Reviewed: Tom
Tests: test of the failure case; now no longer accepts a password change with any random current password; works only if correct current password is provided; QL

Revisions:
----------
44833 (for trunk)
44837 (for 3.1 branch)

Modified Paths:
---------------
trunk/v3/admin/cli/src/main/java/com/sun/enterprise/admin/cli/ChangeAdminPasswordCommand.java

Comment by shaline [ 10/Feb/11 ]

Verified in GF b42 nightly dated 02-09-2011





[GLASSFISH-16404] Define deployment-time service metadata for use in PaaS deployments Created: 21/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: service-orchestration
Affects Version/s: 4.0
Fix Version/s: 4.0_b49

Type: New Feature Priority: Blocker
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16402 Single-click application provisioning... Closed
Tags: ee7_cleanup_closed

 Description   

Service Meta-data:

  • Define a mechanism to specify deployment-time cloud meta-data (cloud.xml or any other appropriate name as we decide) that includes service definitions and service references of an application. The service reference could be a reference to an application-scoped service or global/shared service or external service
  • Optionally define glassfish-cloud.xml schema for glassfish specific defaults and extensions for cloud-metadata. This could also be used by the Orchestrator to map generic service meta-data specified in cloud.xml to a Service Template in an IMS template catalog


 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16405] Automatically provision services during application deployment Created: 21/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: service-orchestration
Affects Version/s: 4.0
Fix Version/s: 4.0_b61

Type: New Feature Priority: Blocker
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16423 Support the basic Paas deploy and und... Closed
depends on GLASSFISH-16424 Additional support for Paas deploy an... Closed
blocks GLASSFISH-16402 Single-click application provisioning... Closed
Tags: ee7_cleanup_closed

 Description   

Automatically provision services during application deployment:

Provision all the required dependent services during deployment of a Java EE application. The application could come up with full/partial/no cloud meta-data.

The Orchestrator would use the IaaS APIs to provision and manage the lifecycle of a Provisioned Service. The Orchestrator must be Service VM Host/Guest OS agnostic. In other words, the Orchestrator must not have any additional dependencies/restrictions on Host/Guest OS of a Service VM Image as we expect the IaaS API and implementation to handle these.

The following must be considered as part of Service Provisioning

  • Service Provider Matching (Template matching rules): Using the service meta-data bundled with or discovered from the application, the Orchestrator must match the service requirements of the application to a Service Template. This template would then be used to provision and realize the Service. These matching rules are still a work in progress. One simple rule that has been identified is: If the application requires a RDBMS service and the service definition is not specified in the cloud meta-data or the service definition does not explicit point to a particular Service Provider(say MySQL), then by default the Orchestrator will select a "default" template (e.g: Derby service template).
  • Atomic provisioning: Provisioning of the dependent services of an application must be atomic (ALL or NONE).
  • Failure handling: If a subset of dependent services cannot be provisioned, the deployment must fail and the state of the system must roll-back to the state prior to the current deployment. [Atomic deployment]
  • Ambiguity during provider matching When multiple plugins can handle particular service requirement and a particular service provider can not be matched then deployment must fail.
  • Automatically provisioning services for vanilla Java EE archives


 Comments   
Comment by Sivakumar Thyagarajan [ 21/Apr/11 ]

Updated the feature description to add additional service provisioning requirements

Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16407] Automatic Service association for a PaaS application Created: 21/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: service-orchestration
Affects Version/s: 4.0
Fix Version/s: 4.0_b55

Type: New Feature Priority: Blocker
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16402 Single-click application provisioning... Closed
Tags: ee7_cleanup_closed

 Description   

Service Association/Binding

Automatically perform necessary actions(create the necessary pools/resources etc) in the application server to bind an application to the services provisioned for the application



 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16403] Support External, Shared Provisioned and Application-Scoped Provisioned Services Created: 21/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: service-orchestration
Affects Version/s: 4.0
Fix Version/s: None

Type: New Feature Priority: Blocker
Reporter: Sivakumar Thyagarajan Assignee: Jagadish
Resolution: Invalid Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16402 Single-click application provisioning... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-17584 allow provisioning of shared services... Sub-task Closed Jagadish  
GLASSFISH-18015 Start and Stop global/shared service Sub-task Resolved Sandhya_Kripalani  
Tags: ee7_cleanup_closed

 Description   

Support association to different types of Services:

The Orchestrator must support binding of an application to the following types of Services:

  • External services(these are not provisioned by the orchestrator, but created and managed by an external user. Their lifecycle is not tied to an application and is not managed by the orchestrator. This is useful in scenarios where a user has existing DB/MoM investments and they want to reuse their existing setup for their application.)
  • Global/shared services (Services that are created by a DAS administrator that are provisioned and managed by the orchestrator. These services can be shared by multiple applications in the domain and the service lifecycle is not tied to a single application. This type of service is useful, for example, when multiple applications in a domain want to share the same database.)
  • Application-scoped services (These are services that are automatically provisioned by the orchestrator during PaaS-style deployment of the application, and their life-cycle is tied to the application's lifecycle.)


 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16402] Single-click application provisioning and deployment of a PaaS application Created: 21/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: service-orchestration
Affects Version/s: 4.0
Fix Version/s: 4.0_b61

Type: New Feature Priority: Blocker
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16403 Support External, Shared Provisioned ... Closed
depends on GLASSFISH-16404 Define deployment-time service metada... Closed
depends on GLASSFISH-16405 Automatically provision services duri... Closed
depends on GLASSFISH-16407 Automatic Service association for a P... Closed
depends on GLASSFISH-16410 Provide a set of standard pre-built S... Closed
depends on GLASSFISH-16411 Add administration and management cap... Closed
depends on GLASSFISH-16408 Service provisioning to support a sta... Closed
depends on GLASSFISH-16409 Support various PaaS deployment scena... Closed
Tags: ee7_cleanup_closed

 Description   

This is the umbrella RFE for the Service Orchestration feature in GlassFish 3.2.

Single-click application provisioning and deployment of a PaaS application through service dependency discovery, service provisioning and service association.



 Comments   
Comment by Sivakumar Thyagarajan [ 21/Apr/11 ]

Adding sub-RFEs for this umbrella RFE.

Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16382] Oracle VM templates for IMS Created: 18/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: iaas
Affects Version/s: 4.0
Fix Version/s: 4.0_b49

Type: New Feature Priority: Blocker
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7_cleanup_closed

 Description   

Must provide prebuilt templates for the OVM 2.2 IMS plugin provider. Templates we must provide:

OEL 5 with GlassFish



 Comments   
Comment by Joe Di Pol [ 02/May/11 ]

Will have a preliminary template in MS3.

Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16379] Oracle VM 3 plugin for IMS Created: 18/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: iaas
Affects Version/s: 4.0
Fix Version/s: 4.0_b43

Type: New Feature Priority: Blocker
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7_cleanup_closed

 Description   

Implement Oracle VM 3 plugin for IMS.



 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16378] IaaS Management Service: API and SPI Created: 18/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: iaas
Affects Version/s: 4.0
Fix Version/s: 4.0_b43

Type: New Feature Priority: Blocker
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16449 Extend installer configurator to hand... Closed
Tags: ee7_cleanup_closed

 Description   

Implement the GlassFish IaaS Management Service (IMS) SPI and API as described in the GlassFish 3.2 Virtualization specification:

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



 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to reassign dochez issue to component lead.

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16360] Steady increase of Perm Gen memory on fresh GF -eventually leading to out of memory error (PermGen) Created: 15/Apr/11  Updated: 02/May/11  Resolved: 20/Apr/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jhasenbe Assignee: Shing Wai Chan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Windows XP, Java 1.6.0_21



 Description   

On a fresh copy of GF (i.e. just downloaded, unpacked and started, without any deployments or configurations), we have found that GF is constantly increasing Perm Gen space required when creating new sessions. This goes on until the server will eventually fail with an OutOfMemory PermGen space exception.

The easiest way to reproduce is
1) load the Administration Console in one session and watch the JVM report -> Memory (not Perm Gen space)
2) open another browser session with the Administration Console.
3) Check the new Perm Gen space
4) repeat from step 2)

In our environment, the Perm Gen space grows between around 2KB and 60KB. That in itself is not a lot, but eventually will kill the server.

We discovered this when we investigated memory issues on a deployed application. After running around 5-6 days (with heavy activity in less time), we get a out of memory exception in Perm Gen.
Looks like the problem was more evident in GF 3.0.1. However, it still exists for GF 3.1.

This issue is a blocker since it stops us from using GF 3.1 in production environment (many sessions in short time).



 Comments   
Comment by Shing Wai Chan [ 18/Apr/11 ]

It is expected that the memory will increase when a new session is created.
For a production environment, one should at least configure the following:
1) the session-timeout under session-config in web.xml of the deployed applications. The default is 30 min.
2) specify sufficient memory in the jvm options.

Comment by jhasenbe [ 20/Apr/11 ]

I am sorry, but I did not talk about heap space but Perm Gen space.
In contrast to heap space, Perm Gen space gets never garbage collected (therefore the name "permanent space") and it is therefore not allowed to grow constantly.
Please re-open the issue and have a closer look. Perm Gen should reach some saturation point and stay at this level.

Thanks!

Comment by Shing Wai Chan [ 20/Apr/11 ]

Thanks for clarification. Can you let us know more about the environment? For Admin Console testing scenario above, do you have any deployed applications in the GlassFish? Do you use cluster, etc?
Can you tell me what jvm option you have set in GlassFish? Can you attach the domain.xml if possible?

Comment by Shing Wai Chan [ 20/Apr/11 ]

I have run the same test in a hello.war with only a index.jsp printing hello. Then there is no issue.
But when I run the same test in admin gui even though I force the gc. I see a minor increase in perm gen as described above.
Then I dump the memory to files for successive access to admin gui.
I find that there are many additional classes of the form sun.reflect.GeneratedConstructorXXX, sun.reflect.GeneratedMethodAccesorXXX.
Those classes are generated by reflection calls when it is invoked more than sun.reflect.inflationThreshold number of times.
I confirm this by accessing the admin gui more than 15 times and I don't increase in perm gen.
And if I set the -Dsun.reflect.noInflation=true, then I find that the admin gui will not increase perm gen after the second access.
So, this is not a bug. It is an optimization from JVM where classes will generated for reflection calls when it is called sufficiently many times.
If one want to plan for space for perm gen, then please use the option sun.reflect.noInflation to check how much memory place is needed.

Comment by jhasenbe [ 26/Apr/11 ]

Thanks for clarification.

However, I have tried your recommendation setting -Dsun.reflect.noInflation=true, but in my environment the perm gen space is steadily increased by between 2-4 KB every time I create a new session for the admin gui (I close my browser and start again to make sure a new session is created on the server).

I have the following environment:

OS: Windows XP
Java: java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)

Comment by jhasenbe [ 26/Apr/11 ]

Here is the content of my domain.xml (don't know how to attache it since the bug is closed):

<domain log-root="$

{com.sun.aas.instanceRoot}/logs" application-root="${com.sun.aas.instanceRoot}

/applications" version="43">
<system-applications>
<application context-root="" location="$

{com.sun.aas.installRootURI}

/lib/install/applications/_admingui" name="_admingui" directory-deployed="true" object-type="system-admin">
<module name="__admingui">
<engine sniffer="web"></engine>
<engine sniffer="security"></engine>
</module>
</application>
</system-applications>
<applications></applications>
<resources>
<jdbc-resource pool-name="_TimerPool" jndi-name="jdbc/_TimerPool" object-type="system-admin"></jdbc-resource>
<jdbc-resource pool-name="DerbyPool" jndi-name="jdbc/__default"></jdbc-resource>
<jdbc-connection-pool datasource-classname="org.apache.derby.jdbc.EmbeddedXADataSource" res-type="javax.sql.XADataSource" name="__TimerPool">
<property name="databaseName" value="$

{com.sun.aas.instanceRoot}/lib/databases/ejbtimer"></property>
<property name="connectionAttributes" value=";create=true"></property>
</jdbc-connection-pool>
<jdbc-connection-pool is-isolation-level-guaranteed="false" datasource-classname="org.apache.derby.jdbc.ClientDataSource" res-type="javax.sql.DataSource" name="DerbyPool">
<property name="PortNumber" value="1527"></property>
<property name="Password" value="APP"></property>
<property name="User" value="APP"></property>
<property name="serverName" value="localhost"></property>
<property name="DatabaseName" value="sun-appserv-samples"></property>
<property name="connectionAttributes" value=";create=true"></property>
</jdbc-connection-pool>
</resources>
<servers>
<server name="server" config-ref="server-config">
<application-ref ref="_admingui" virtual-servers="_asadmin"></application-ref>
<resource-ref ref="jdbc/__TimerPool"></resource-ref>
<resource-ref ref="jdbc/__default"></resource-ref>
</server>
</servers>
<nodes>
<node node-host="localhost" name="localhost-domain1" type="CONFIG" install-dir="${com.sun.aas.productRoot}"></node>
</nodes>
<configs>
<config name="server-config">
<http-service>
<access-log></access-log>
<virtual-server id="server" network-listeners="http-listener-1,http-listener-2"></virtual-server>
<virtual-server id="__asadmin" network-listeners="admin-listener"></virtual-server>
</http-service>
<iiop-service>
<orb use-thread-pool-ids="thread-pool-1"></orb>
<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" lazy-init="true"></iiop-listener>
<iiop-listener port="3820" id="SSL" address="0.0.0.0" security-enabled="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
</iiop-listener>
<iiop-listener port="3920" id="SSL_MUTUALAUTH" address="0.0.0.0" security-enabled="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as" client-auth-enabled="true"></ssl>
</iiop-listener>
</iiop-service>
<admin-service system-jmx-connector-name="system" type="das-and-server">
<jmx-connector port="8686" address="0.0.0.0" security-enabled="false" auth-realm-name="admin-realm" name="system"></jmx-connector>
<property name="adminConsoleContextRoot" value="/admin"></property>
<property name="adminConsoleDownloadLocation" value="${com.sun.aas.installRoot}/lib/install/applications/admingui.war"></property>
<property name="ipsRoot" value="${com.sun.aas.installRoot}/.."></property>
<das-config></das-config>
</admin-service>
<connector-service></connector-service>
<web-container>
<session-config>
<session-manager>
<manager-properties></manager-properties>
<store-properties></store-properties>
</session-manager>
<session-properties></session-properties>
</session-config>
</web-container>
<ejb-container session-store="${com.sun.aas.instanceRoot}

/session-store">
<ejb-timer-service></ejb-timer-service>
</ejb-container>
<mdb-container></mdb-container>
<jms-service default-jms-host="default_JMS_host" type="EMBEDDED">
<jms-host host="localhost" name="default_JMS_host"></jms-host>
</jms-service>
<security-service>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="admin-realm">
<property name="file" value="$

{com.sun.aas.instanceRoot}/config/admin-keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
<property name="file" value="${com.sun.aas.instanceRoot}

/config/keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.certificate.CertificateRealm" name="certificate"></auth-realm>
<jacc-provider policy-provider="com.sun.enterprise.security.provider.PolicyWrapper" name="default" policy-configuration-factory-provider="com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl">
<property name="repository" value="$

{com.sun.aas.instanceRoot}/generated/policy"></property>
</jacc-provider>
<jacc-provider policy-provider="com.sun.enterprise.security.jacc.provider.SimplePolicyProvider" name="simple" policy-configuration-factory-provider="com.sun.enterprise.security.jacc.provider.SimplePolicyConfigurationFactory"></jacc-provider>
<audit-module classname="com.sun.enterprise.security.Audit" name="default">
<property name="auditOn" value="false"></property>
</audit-module>
<message-security-config auth-layer="SOAP">
<provider-config provider-type="client" provider-id="XWS_ClientProvider" class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="dynamic.username.password" value="false"></property>
<property name="debug" value="false"></property>
</provider-config>
<provider-config provider-type="client" provider-id="ClientProvider" class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="dynamic.username.password" value="false"></property>
<property name="debug" value="false"></property>
<property name="security.config" value="${com.sun.aas.instanceRoot}

/config/wss-server-config-1.0.xml"></property>
</provider-config>
<provider-config provider-type="server" provider-id="XWS_ServerProvider" class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="debug" value="false"></property>
</provider-config>
<provider-config provider-type="server" provider-id="ServerProvider" class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="debug" value="false"></property>
<property name="security.config" value="$

{com.sun.aas.instanceRoot}/config/wss-server-config-1.0.xml"></property>
</provider-config>
</message-security-config>
<message-security-config auth-layer="HttpServlet">
<provider-config provider-type="server" provider-id="GFConsoleAuthModule" class-name="org.glassfish.admingui.common.security.AdminConsoleAuthModule">
<request-policy auth-source="sender"></request-policy>
<response-policy></response-policy>
<property name="restAuthURL" value="http://localhost:${ADMIN_LISTENER_PORT}/management/sessions"></property>
<property name="loginPage" value="/login.jsf"></property>
<property name="loginErrorPage" value="/loginError.jsf"></property>
</provider-config>
</message-security-config>
<property name="default-digest-algorithm" value="SHA-256"></property>
</security-service>
<transaction-service tx-log-dir="${com.sun.aas.instanceRoot}

/logs"></transaction-service>
<java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" system-classpath="" classpath-suffix="">
<jvm-options>-XX:MaxPermSize=192m</jvm-options>
<jvm-options>-client</jvm-options>
<jvm-options>-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder</jvm-options>
<jvm-options>-XX:+UnlockDiagnosticVMOptions</jvm-options>
<jvm-options>-Djava.endorsed.dirs=$

{com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}

/lib/endorsed</jvm-options>
<jvm-options>-Djava.security.policy=$

{com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
<jvm-options>-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}

/config/login.conf</jvm-options>
<jvm-options>-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as</jvm-options>
<jvm-options>-Xmx512m</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStore=$

{com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}

/config/cacerts.jks</jvm-options>
<jvm-options>-Djava.ext.dirs=$

{com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}

/jre/lib/ext$

{path.separator}${com.sun.aas.instanceRoot}/lib/ext</jvm-options>
<jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
<jvm-options>-DANTLR_USE_DIRECT_CLASS_LOADING=true</jvm-options>
<jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
<jvm-options>-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command</jvm-options>
<jvm-options>-Dosgi.shell.telnet.port=6666</jvm-options>
<jvm-options>-Dosgi.shell.telnet.maxconn=1</jvm-options>
<jvm-options>-Dosgi.shell.telnet.ip=127.0.0.1</jvm-options>
<jvm-options>Dgosh.args=-nointeractive</jvm-options>
<jvm-options>-Dfelix.fileinstall.dir=${com.sun.aas.installRoot}/modules/autostart/</jvm-options>
<jvm-options>-Dfelix.fileinstall.poll=5000</jvm-options>
<jvm-options>-Dfelix.fileinstall.log.level=2</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.new.start=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.startTransient=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.disableConfigSave=false</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>
<jvm-options>-Dsun.reflect.noInflation=true</jvm-options>
</java-config>
<network-config>
<protocols>
<protocol name="http-listener-1">
<http default-virtual-server="server" max-connections="250">
<file-cache></file-cache>
</http>
</protocol>
<protocol security-enabled="true" name="http-listener-2">
<http default-virtual-server="server" max-connections="250">
<file-cache></file-cache>
</http>
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" ssl3-enabled="false" cert-nickname="s1as"></ssl>
</protocol>
<protocol name="admin-listener">
<http default-virtual-server="__asadmin" max-connections="250" encoded-slash-enabled="true">
<file-cache></file-cache>
</http>
</protocol>
</protocols>
<network-listeners>
<network-listener port="8080" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
<network-listener port="8181" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
<network-listener port="4848" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>
</network-listeners>
<transports>
<transport name="tcp"></transport>
</transports>
</network-config>
<thread-pools>
<thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
<thread-pool name="http-thread-pool"></thread-pool>
<thread-pool name="thread-pool-1" max-thread-pool-size="200"></thread-pool>
</thread-pools>
<monitoring-service>
<module-monitoring-levels></module-monitoring-levels>
</monitoring-service>
<group-management-service>
<failure-detection></failure-detection>
</group-management-service>
</config>
<config name="default-config">
<http-service>
<access-log></access-log>
<virtual-server id="server" network-listeners="http-listener-1, http-listener-2">
<property name="default-web-xml" value="${com.sun.aas.instanceRoot}/config/default-web.xml"></property>
</virtual-server>
<virtual-server id="__asadmin" network-listeners="admin-listener"></virtual-server>
</http-service>
<iiop-service>
<orb use-thread-pool-ids="thread-pool-1"></orb>
<iiop-listener port="${IIOP_LISTENER_PORT}" id="orb-listener-1" address="0.0.0.0"></iiop-listener>
<iiop-listener port="${IIOP_SSL_LISTENER_PORT}" id="SSL" address="0.0.0.0" security-enabled="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
</iiop-listener>
<iiop-listener port="${IIOP_SSL_MUTUALAUTH_PORT}" id="SSL_MUTUALAUTH" address="0.0.0.0" security-enabled="true">
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as" client-auth-enabled="true"></ssl>
</iiop-listener>
</iiop-service>
<admin-service system-jmx-connector-name="system">
<jmx-connector port="${JMX_SYSTEM_CONNECTOR_PORT}" address="0.0.0.0" security-enabled="false" auth-realm-name="admin-realm" name="system"></jmx-connector>
<property name="adminConsoleDownloadLocation" value="${com.sun.aas.installRoot}/lib/install/applications/admingui.war"></property>
<das-config></das-config>
</admin-service>
<web-container>
<session-config>
<session-manager>
<manager-properties></manager-properties>
<store-properties></store-properties>
</session-manager>
<session-properties></session-properties>
</session-config>
</web-container>
<ejb-container session-store="${com.sun.aas.instanceRoot}/session-store">
<ejb-timer-service></ejb-timer-service>
</ejb-container>
<mdb-container></mdb-container>
<jms-service addresslist-behavior="priority" default-jms-host="default_JMS_host" type="EMBEDDED">
<jms-host port="${JMS_PROVIDER_PORT}" host="localhost" name="default_JMS_host"></jms-host>
</jms-service>
<log-service log-rotation-limit-in-bytes="2000000" file="${com.sun.aas.instanceRoot}/logs/server.log">
<module-log-levels></module-log-levels>
</log-service>
<security-service>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="admin-realm">
<property name="file" value="${com.sun.aas.instanceRoot}/config/admin-keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
<property name="file" value="${com.sun.aas.instanceRoot}/config/keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
</auth-realm>
<auth-realm classname="com.sun.enterprise.security.auth.realm.certificate.CertificateRealm" name="certificate"></auth-realm>
<jacc-provider policy-provider="com.sun.enterprise.security.provider.PolicyWrapper" name="default" policy-configuration-factory-provider="com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl">
<property name="repository" value="${com.sun.aas.instanceRoot}/generated/policy"></property>
</jacc-provider>
<jacc-provider policy-provider="com.sun.enterprise.security.jacc.provider.SimplePolicyProvider" name="simple" policy-configuration-factory-provider="com.sun.enterprise.security.jacc.provider.SimplePolicyConfigurationFactory"></jacc-provider>
<audit-module classname="com.sun.enterprise.security.Audit" name="default">
<property name="auditOn" value="false"></property>
</audit-module>
<message-security-config auth-layer="SOAP">
<provider-config provider-type="client" provider-id="XWS_ClientProvider" class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="dynamic.username.password" value="false"></property>
<property name="debug" value="false"></property>
</provider-config>
<provider-config provider-type="client" provider-id="ClientProvider" class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="dynamic.username.password" value="false"></property>
<property name="debug" value="false"></property>
<property name="security.config" value="${com.sun.aas.instanceRoot}/config/wss-server-config-1.0.xml"></property>
</provider-config>
<provider-config provider-type="server" provider-id="XWS_ServerProvider" class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="debug" value="false"></property>
</provider-config>
<provider-config provider-type="server" provider-id="ServerProvider" class-name="com.sun.xml.wss.provider.ServerSecurityAuthModule">
<request-policy auth-source="content"></request-policy>
<response-policy auth-source="content"></response-policy>
<property name="encryption.key.alias" value="s1as"></property>
<property name="signature.key.alias" value="s1as"></property>
<property name="debug" value="false"></property>
<property name="security.config" value="${com.sun.aas.instanceRoot}/config/wss-server-config-1.0.xml"></property>
</provider-config>
</message-security-config>
</security-service>
<transaction-service tx-log-dir="${com.sun.aas.instanceRoot}/logs" automatic-recovery="true"></transaction-service>
<diagnostic-service></diagnostic-service>
<java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=${JAVA_DEBUGGER_PORT}" system-classpath="" classpath-suffix="">
<jvm-options>-XX:MaxPermSize=192m</jvm-options>
<jvm-options>-server</jvm-options>
<jvm-options>-XX:+UnlockDiagnosticVMOptions</jvm-options>
<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/modules/endorsed${path.separator}

$

{com.sun.aas.installRoot}/lib/endorsed</jvm-options>
<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
<jvm-options>-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
<jvm-options>-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>
<jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext</jvm-options>
<jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
<jvm-options>-DANTLR_USE_DIRECT_CLASS_LOADING=true</jvm-options>
<jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>
<jvm-options>-Xmx512m</jvm-options>
<jvm-options>-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command</jvm-options>
<jvm-options>-Dosgi.shell.telnet.port=${OSGI_SHELL_TELNET_PORT}</jvm-options>
<jvm-options>-Dosgi.shell.telnet.maxconn=1</jvm-options>
<jvm-options>-Dosgi.shell.telnet.ip=127.0.0.1</jvm-options>
<jvm-options>Dgosh.args=-noshutdown -c noop=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.dir=${com.sun.aas.installRoot}

/modules/autostart/</jvm-options>
<jvm-options>-Dfelix.fileinstall.poll=5000</jvm-options>
<jvm-options>-Dfelix.fileinstall.log.level=3</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.new.start=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.bundles.startTransient=true</jvm-options>
<jvm-options>-Dfelix.fileinstall.disableConfigSave=false</jvm-options>
</java-config>
<availability-service>
<web-container-availability></web-container-availability>
<ejb-container-availability sfsb-store-pool-name="jdbc/hastore"></ejb-container-availability>
<jms-availability></jms-availability>
</availability-service>
<network-config>
<protocols>
<protocol name="http-listener-1">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
</protocol>
<protocol security-enabled="true" name="http-listener-2">
<http default-virtual-server="server">
<file-cache></file-cache>
</http>
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" ssl3-enabled="false" cert-nickname="s1as"></ssl>
</protocol>
<protocol name="admin-listener">
<http default-virtual-server="__asadmin" max-connections="250">
<file-cache></file-cache>
</http>
</protocol>
</protocols>
<network-listeners>
<network-listener port="$

{HTTP_LISTENER_PORT}

" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
<network-listener port="$

{HTTP_SSL_LISTENER_PORT}

" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
<network-listener port="$

{ASADMIN_LISTENER_PORT}

" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>
</network-listeners>
<transports>
<transport name="tcp"></transport>
</transports>
</network-config>
<thread-pools>
<thread-pool name="http-thread-pool"></thread-pool>
<thread-pool max-thread-pool-size="200" name="thread-pool-1"></thread-pool>
<thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
</thread-pools>
<group-management-service>
<failure-detection></failure-detection>
</group-management-service>
<management-rules></management-rules>
<system-property name="ASADMIN_LISTENER_PORT" value="24848"></system-property>
<system-property name="HTTP_LISTENER_PORT" value="28080"></system-property>
<system-property name="HTTP_SSL_LISTENER_PORT" value="28181"></system-property>
<system-property name="JMS_PROVIDER_PORT" value="27676"></system-property>
<system-property name="IIOP_LISTENER_PORT" value="23700"></system-property>
<system-property name="IIOP_SSL_LISTENER_PORT" value="23820"></system-property>
<system-property name="IIOP_SSL_MUTUALAUTH_PORT" value="23920"></system-property>
<system-property name="JMX_SYSTEM_CONNECTOR_PORT" value="28686"></system-property>
<system-property name="OSGI_SHELL_TELNET_PORT" value="26666"></system-property>
<system-property name="JAVA_DEBUGGER_PORT" value="29009"></system-property>
<monitoring-service>
<module-monitoring-levels></module-monitoring-levels>
</monitoring-service>
<connector-service></connector-service>
</config>
</configs>
<property name="administrative.domain.name" value="domain1"></property>
<load-balancers></load-balancers>
<lb-configs></lb-configs>
<clusters></clusters>
</domain>

Comment by Shing Wai Chan [ 26/Apr/11 ]

After setting the jvm option, you have to restart the server.
Also, please force GC before measuring the memory in the perm gen.
Furthermore, please double check the number of classes loaded in the perm gen.

Even without jvm option specified above, the perm gen should be stable after 10 access of admin console.

Comment by jhasenbe [ 02/May/11 ]

We wrote some more tests and I can confirm that perm gen increases only by a few bytes after the first 10 accesses.
More so: with Java 1.6 perm gen gets garbage collected as well (whereas in Java 1.5, it was not).

The issue we encounter are more likely in our application using CDI (i.e. Weld).

Thanks for your help!





[GLASSFISH-16113] Glassfish Eclipse Plugin won't create WAR dependencies properly Created: 01/Mar/11  Updated: 03/Jun/11  Resolved: 03/Jun/11

Status: Closed
Project: glassfish
Component/s: ide-integration
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b06

Type: Bug Priority: Blocker
Reporter: drivera Assignee: ludo
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.10 x86, Eclipse 3.6.1 Helios for JEE, Glassfish Plugin v1.7.0.201101121059



 Description   

I have a WAR project that references other projects as dependencies. When attempting to deploy the WAR to a Glassfish 3.1 instance, the dependencies in $/WEB-INF/lib are created as directories instead of JARs.

As a result, the application fails to deploy because it (rightly) doesn't find the necessary classes.

No such problem with Glassfish 3.0.1.



 Comments   
Comment by drivera [ 10/Mar/11 ]

This issue seems to be a duplicate of GLASSFISHPLUGINS-324

Comment by vince kraemer [ 03/Jun/11 ]

reassigning to ludo. He is working on the Eclipse integration

Comment by ludo [ 03/Jun/11 ]

This is an issue in the GlassFish 3.1 runtime that has been fixed in the 3.1.1 code line...
Either you move to a promoted 3.1.1 build, or edit the server properties in Eclipse, and check the checkbox that tells to deploy projects as archives...

Comment by scatari [ 03/Jun/11 ]

Marking it as fixed in B06 though the exact check-in date is unknown.

Comment by ludo [ 03/Jun/11 ]

I think it was glassfish issue 16216
checkin revision
45566

Project: glassfish
Repository: svn
Revision: 45566
Author: hzhang_jn
Date: 2011-03-15 16:24:13 UTC

Comment by ludo [ 03/Jun/11 ]

dup of 16216





[GLASSFISH-17341] JWS deployement fail Created: 25/Sep/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1.1_b12
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: isoman Assignee: Tim Quinn
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu server 11.10 on a virtualbox machine
windows 7 (real machine)


Attachments: File e.ear     File s.ear     Zip Archive Sources.zip    
Tags: deployment, jws

 Description   

Hello,
Steps to reproduce the problem:
1-deploy s.ear
2-deploy e.ear
3-download the jnlp file .
4-launch it.

exception :

com.sun.deploy.net.FailedDownloadException: Impossible de charger la ressource : http://127.0.0.1:8080/___JWSappclient/___system/___dyn/___system_s1as.jnlp
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCachedFile(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The ejb parts contains one remote ejb with one method .
The client call this method.
To make this work i have to undeploy e.ear (client) and redploy it until it works .

Thanks.



 Comments   
Comment by isoman [ 25/Sep/11 ]

same problem with ubuntu 11.04 .

Comment by Tim Quinn [ 25/Sep/11 ]

Changing the component to standalone-client (since this is Java EE app client related) and assigning it to me.

Comment by Tim Quinn [ 25/Sep/11 ]

Thank you for the sample, but I cannot reproduce the problem.

Please tell us exactly how you are downloading and launching the JNLP file.

Normally, you would do both at once using a command like this:

javaws "http://localhost:8080/e/ee"

In fact, when I try that with your sample I get this in the Java Web Start trace file and console output:

creation contexte
fin creation contexte
debut lookup
gotcha hmd:11

What output do you expect?
I do not see the error you described.

(Edited to correct the URL I used to launch the client - I mistyped it in my original note.)

Comment by isoman [ 27/Sep/11 ]

Thank you for your reply,

It's the correct output.
that's really strange, i'll try to reproduce the bug with a fresh installation .

I'll keep you in touch .

Comment by Hong Zhang [ 27/Sep/11 ]

assign to tim

Comment by isoman [ 30/Sep/11 ]

Hello,

I have isolated the problem more precisely.

It usually happens when I deploy the client appplication and reboot the server (ubuntu ).
After the restart , when I try to download the .Jnlp I get a 404 error .
I tested with jdk jre 7 and 6.
I have added the PostgreSQL driver in the directory domain /lib/ext to use the security realm with postgresql.

Thank you.

Comment by Tim Quinn [ 10/Nov/11 ]

When you get the error, are you trying to launch the app from the same Ubuntu system where the server is running, or from another system?

If you are trying this remotely, can you try launching from the same system as an experiment?

I have still been unable to reproduce this error myself. I am suspicious about the 127.0.0.1 address that is reported in the error. Can you attach the domain.xml file your domain is using?

It seems as if the first JNLP document is accessed successfully. That JNLP refers to the system JNLP that is mentioned in the error. If the first JNLP refers (perhaps incorrectly depending on your setup) to localhost or 127.0.0.1 then that might reflect a problem in the domain.xml setup.

Comment by Tim Quinn [ 14/Nov/11 ]

I am going to mark this as "cannot reproduce."

Please re-open this if you discover anything else that would help us create the problem.





[GLASSFISH-17058] JAXBContext.newInstance(Class...) throwing java.lang.InternalError Created: 18/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Closed
Project: glassfish
Component/s: classloader, standalone_client
Affects Version/s: 3.1, 3.1.1_b11
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mkarg Assignee: Sanjeeb Sahoo
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE, JDK 1.6.0_26


Attachments: File SuperSimpleJaxbCrash.ear    

 Description   

JAXBContext.newInstance(Class...) is throwing a java.lang.InternalError when running inside GFv3.1.1_b11's (and GFv3.1's) ACC. According to the JavaDocs of that method, this is not allowed. So I would rate that as a showstopper.

Attached is an EAR that proofs the behaviour. It consists of a client that does nothing but this:

public class ExplorerLoader {
public static void main(String[] arguments) throws Exception

{ Class c = Class.forName("de.quipsy.entities.ControlPlan"); System.out.println("Loaded Class: " + c); JAXBContext j = JAXBContext.newInstance(c); System.out.println("Created Context: " + j); }

}

Deploy it using:

asadmin deploy --retrieve . SuperSimpleJaxbCrash.ear

Then start the client using:

appclient -client SuperSimpleJaxbCrashClient.jar

...and you will get this output:

Loaded Class: class de.quipsy.entities.ControlPlan
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
Caused by: java.lang.InternalError
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getClassValue(RuntimeInlineAnnotationReader.java:1
43)
at com.sun.xml.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getClassValue(RuntimeInlineAnnotationReader.java:5
7)
at com.sun.xml.bind.v2.model.impl.PropertyInfoImpl.isApplicable(PropertyInfoImpl.java:216)
at com.sun.xml.bind.v2.model.impl.PropertyInfoImpl.getApplicableAdapter(PropertyInfoImpl.java:227)
at com.sun.xml.bind.v2.model.impl.PropertyInfoImpl.<init>(PropertyInfoImpl.java:126)
at com.sun.xml.bind.v2.model.impl.SingleTypePropertyInfoImpl.<init>(SingleTypePropertyInfoImpl.java:75)
at com.sun.xml.bind.v2.model.impl.AttributePropertyInfoImpl.<init>(AttributePropertyInfoImpl.java:63)
at com.sun.xml.bind.v2.model.impl.RuntimeAttributePropertyInfoImpl.<init>(RuntimeAttributePropertyInfoImpl.java:58)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.createAttributeProperty(RuntimeClassInfoImpl.java:165)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.addProperty(ClassInfoImpl.java:873)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.findFieldProperties(ClassInfoImpl.java:409)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getProperties(ClassInfoImpl.java:312)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.getProperties(RuntimeClassInfoImpl.java:186)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:247)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:104)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:85)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:213)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:99)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:85)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:319)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:334)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:460)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:298)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:141)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1157)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:263)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:250)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:447)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:652)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:599)
at de.quipsy.application.explorer.ExplorerLoader.main(ExplorerLoader.java:9)
... 7 more

Actually it seems as if it is not really a GF problem but possibly more a general bug in JAXB 2.x, as the following test proofs:

cd SuperSimpleJaxbCrashClient
java -cp FAKE.jar;quipsy5-ejbInterfaces.jar de.quipsy.application.explorer.ExplorerLoader

...and it will also throw an InternalError at at com.sun.xml.internal.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getClassValue(Unknown Source)!

So it seems there is some very severe bug in the latest JAXB implementation, and GF at least does not provide an improve version. Otherwise I absolutely cannot explain this. More weird: When running the same code inside of Eclipse Helios, this is working pretty well...!

Nevertheless, independent of whether the problem is in the JDK or GF: It prevents people from running their software inside of GF, so there must be a workaround before publishing GFv3.1.1-GA.



 Comments   
Comment by mkarg [ 18/Jul/11 ]

I have found the cause, and as I already wrote it definitively is a bug in JAXB.

The cause that makes the failure occur is that the class provided to newInstance(c) is using the @XmlJavaTypeAdapter annotation, and this annotation has a parameter (a class) and THAT class is missing in the classpath.

The actual bug in JAXB is that it must not say "InternalError" but simply "ClassNotFound: THAT class", so people understand what the problem is actually.

I want to propose that this bug gets closed as INVALID since there is nothing wrong with GF and everything works fine if the EAR is complete. I will open a similar one with the JAXB project's issue tracker.

Comment by mkarg [ 18/Jul/11 ]

See http://java.net/jira/browse/JAXB-846

Comment by kumara [ 22/Jul/11 ]

Closing as "Won't Fix" in glassfish issue tracker. Please refer to the JAXB issue in the previous comment for resolution.

Comment by mkarg [ 22/Jul/11 ]

I do not understand why the resolution is "Won't fix"? The JAXB guys definitively will fix it, and JAXB is a mandatory part of Java EE, and GF is the RI of Java EE. So the resolution should be not "Won't fix" but something like "As soon as JAXB guys provide the fix, we will integrate it into GF". Or is there a different list for such external dependencies?

Comment by kumara [ 22/Jul/11 ]

JAXB is integrated in GlassFish through Metro. Each integration is tracked as a single issue with multiple issues fixed in Metro project. "Won't Fix" may not be the best option but there is nothing more appropriate in the issue tracker to mark this. If you want it marked some other way let us know.

Comment by mkarg [ 25/Jul/11 ]

I want to ask you to change the resolution policy. Unless the problem is resolved (and this one obviously is not fixed so far unless a JAXB bug fix is contained in either GF or JRE) the resolution must clearly indicate that the bug still is existing in trunk. Otherwise people checking for this bug report will file a regression as they still detect the problem.

Comment by kumara [ 25/Jul/11 ]

Reopen to close as duplicate

Comment by kumara [ 25/Jul/11 ]

Duplicate of http://java.net/jira/browse/JAXB-846





[GLASSFISH-17054] Can use custom JAX-RS methods like SEARCH in EAR, but not in standalone WAR Created: 15/Jul/11  Updated: 22/Jul/11  Resolved: 22/Jul/11

Status: Closed
Project: glassfish
Component/s: jax-rs
Affects Version/s: 3.1.1_b11
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mkarg Assignee: Jakub Podlesak
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE


Attachments: File QUIPSY.war    

 Description   

Attached web module deployed inside an EAR reacts to custom requests like SEARCH, but when deployed as a standalone module GF says

HTTP/1.1 501 Method SEARCH is not defined in RFC 2068 and is not supported by the Servlet API
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.1-b11 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1.1-b11

It seems that the request is not forwarded to Jersey but handled directly by the servlet container in that case?

Despite this fact, it is questionable whether the servlet API is really limited to RFC 2068? I mean, there can be servlets other than HttpServlets, obviously.



 Comments   
Comment by mkarg [ 15/Jul/11 ]

Sample used to reproduce the bug. Source Code:

@Path("quipsy") public class QuipsyResource {
@SEARCH public final Response search(final QuerySchemaDiscovery querySchemaDiscovery)

{ final HRef hRef = ((BasicSearch) querySchemaDiscovery.getAny().get(0)).getFrom().getScopes().get(0).getHRef(); final Response response = new Response(hRef, new Status((StatusType) OK), new QuerySchema(new BasicSearchSchema(new Properties(), new Operators())), null); return response; }

}

Comment by mkarg [ 15/Jul/11 ]

Seems it has nothing to do with EAR vs WAR: The same WAR now is not working anymore in the EAR, too. There must be something different broken is GF?

Comment by mkarg [ 15/Jul/11 ]

Please mark this bug report as invalid.

Unfortunately "normale" users like me cannot reject their own bug reports (silly, but true).

The problem as described does not exist. The cause was that between deploying as EAR and deploying as WAR the servlet mapping was removed by incident, so obviously the intended path was not matched.

The functionality is working as expected, but close this issue.

Comment by kumara [ 22/Jul/11 ]

Closing per the previous comment.





[GLASSFISH-16980] Violation of JCA 1.5 specification chapter 17.2.0.4 Created: 07/Jul/11  Updated: 11/Jul/11  Resolved: 07/Jul/11

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur2, 3.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mkarg Assignee: Jagadish
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 Pro SP1 64 Bit de_DE



 Description   

For backwards compatibility, a Java EE 6 compliant container needs to still support older modules. I tested an EAR containing a JCA 1.5 compliant module.

At deployment both, GFv3.1 and the older GFv2ur2 proof a violation of the JCA 1.5 specification chapter 17.2.0.4.

That chapter says: "When a resource adapter RAR packaged within a J2EE application EAR is
deployed, the resource adapter must be made available only to the J2EE
application with which it is packaged."

Despite this unambiguous cite both, GF 3.1 and 2ur2, deploy the EAR-contained connector in a manner that makes is public to all applications, what is just WRONG.

GF 3.1 has a new facility, glassfish-resources.xml, which allows to create application-embedded resources, including connector pools. The specification-compliant way to use this would be that, according to 17.2.0.4, a connector contained in an EAR is automatically PRIVATE, UNLESS something different got configured by glassfish-resources.xml (e. g. using a new attribute like scope="global"). What GFv3.1 ACTUALLY does is, that a EAR-contained RAR is PUBLIC ALWAYS clearly violating 17.2.0.4 UNLESS it is configured in a proprietary way to be NOT.

As GF is the RI for JCA 1.5 still, this MUST GET FIXED ASAP or writing sentences like those into public specs is a hoax and good for nothing. Unless there is an errata 1.5.1 published that removes the above sentence, GF has to follow the spec WITHOUT configuration. If backwards compatibility is to be ensured (i. e. the bug must still be there), then THOSE users needed that bug, have to ENABLE that it explicitly. But the default MUST be that the bug is gone. Everything else is just ridiculous.



 Comments   
Comment by mkarg [ 07/Jul/11 ]

Side note: Latest specification JCA 1.6 chapter 20.2.0.4 is also violated, as the text is virtually unchanged:

"When a resource adapter RAR packaged within a Java EE application EAR is
deployed, the resource adapter must be made available only to the Java EE
application with which it is packaged."

It seems comfortable compatibility to users of old bugs is of higher priority to the GF team than fulfilling the role of being the RI for JCA 1.6? This foils the idea of an RI, actually.

Comment by Hong Zhang [ 07/Jul/11 ]

assign to jagadish for initial evaluation

Comment by Jagadish [ 07/Jul/11 ]

GlassFish (2.x or 3.x) does not expose embedded RARs to all applications.
It is available only to the modules of the .ear in which the .rar is bundled.

Try the following sample :
Follow section-2 in the README.txt that starts with :
"(2) TO CHECKOUT AND RUN A SPECIFIC TEST CASE "

http://java.net/projects/glassfish/sources/svn/content/trunk/v2/appserv-tests/devtests/connector/v3/README.txt

Instead of doing "svn co https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/embeddedweb",
use :
"svn co https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/embeddedConnector1.5"

cd embeddedConnector1.5
ant init-common build setup

Above will deploy the ear that has embedded rar and will create an admin object resource by global name "eis/testAdmin".

Deploy your sample .ear or .war that does lookup of the above resource.

eg:
try

{ InitialContext context = new InitialContext(); Object o = context.lookup("eis/testAdmin"); System.out.println("o = : " + o); }

catch (NamingException e)

{ e.printStackTrace(); }

}

You will find that the resource by name "eis/testAdmin" will not be available to the .war/.ear that does not have the .rar

If you see otherwise, provide a test-case.

Comment by Jagadish [ 07/Jul/11 ]

works for me.

Comment by mkarg [ 07/Jul/11 ]

I have to object. When I deploy the EAR containing the RAR, the RAR is visible in the admin GUI as if it would be a standalone one, and I can create a global pool and a global resource using that pool. When I then try to undeploy the EAR it fails since GlassFish fears other EARs still using that resource. So obviously GlassFish assumes that this is a global one. If you don't believe, I can provide a screencast showing you how it works.

Comment by Jagadish [ 07/Jul/11 ]

Visibility specified in the specification is not about resource being visible in the GUI/CLI.
It is about whether the resource artifacts (connector resource, pool, admin-object) or any of the classes of the embedded RAR is available to the other application or not.

Resources of embedded RAR shown in GUI are for tuning or testing (eg: ping-connection-pool) purposes.

The resources in GlassFish 2.x have always been global ie., they are available in global jndi namespace, but not usable by other applications in case of embedded RAR's resources.
GlassFish 3.x still supports this in addition to application scoped resources where resources are bound in application's namespace.

Comment by mkarg [ 09/Jul/11 ]

Sorry but you still miss the point.

If I deploy an EAR with a RAR in it, and then create a pool and a resource, and then want to undeploy the EAR, the undeploy will fail with the justification that it would mean the resource is no more usable. This is ridiculous as the resource can only be accessed by exactly that EAR (as the JCA spec says and as you confirmed above).

So it is just nonsense to prevent that undeploy.

Got it now?

Comment by Jagadish [ 09/Jul/11 ]

Your last comment and first comment (initial description of problem) about Spec violation are different. There is no spec. violation here. Raise a separate bug which will be looked into post 3.1.1.

Comment by mkarg [ 11/Jul/11 ]

I do not see a need for another bug report: The violation is that GlassFish fears to break other applications, while the spec says, this cannot be visible to other applications. So it is the same bug report.





[GLASSFISH-16936] Encountered an error when try to create a Backup Configuration in AdminConsole Created: 01/Jul/11  Updated: 21/Jul/11  Resolved: 06/Jul/11

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1.1_b09
Fix Version/s: 3.1.1_b11

Type: Bug Priority: Blocker
Reporter: sunny-gui Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: OEL 5 U5 x86
Bundle: ogs-3.1.1-b09-ml.zip
Java version: 1.6.0_26
Server Locale: ja_JP.UTF-8
Browser Locale: ja, zh_CN
Browser: IE 8.0


Attachments: JPEG File backup_exception.jpg     Text File server.log    
Tags: 3_1_1-approved, 3_1_1-scrubbed

 Description   

To reproduce:
1. Go to Domain after log in Admin Console.
2. Go to Backup Tab in the right panel.
3. Click on New button under Backup Configurations sub-tab.

There is exception, displayed as follows:

HTTP Status 500-
-------------------------------------------------------------------------------------
type Exception report
message description The server encountered an internal error() that prevented it from fulfiling this request.
exception
java.lang.IllegalStateException: PWC3991: getOutputStream() has already been called for thie response
note The full stack traces of the exception and its root causes are available in the Oracle GlassFish Server 3.1.1 logs.
--------------------------------------------------------------------------------------
Attached screen shot and server.log for your reference.



 Comments   
Comment by sirajg [ 01/Jul/11 ]

How did you install the value-add? Did you try any of the das recovery CLI commands?

Comment by sunny-gui [ 04/Jul/11 ]

Hi,
I did not execute any of the DAS recovery CLI commands. I just unzip the bundle ogs-3.1.1-b09-ml.zip or install the bundle ogs-3.1.1-b10-ml.sh

I tried in the following bundles, here are details.

Could not reproduce this issue in the bundle,
ogs-3.1.1-b06-ml.zip

This issue is reproducible in following bundles,
ogs-3.1.1-b07-ml.zip
ogs-3.1.1-b09-ml.zip
ogs-3.1.1-b10-ml.zip
ogs-3.1.1-b10.zip
ogs-3.1.1-b10-ml.sh

Comment by Anissa Lam [ 04/Jul/11 ]

Thanks for trying all the different versions.
This seems to be a regression in the REST code.

Try http://localhost:4848/management/domain/configs/config/server-config/backup-configs in b06, it works fine, and you see the following:

{"command":"Backup-config","exit_code":"SUCCESS","extraProperties":{"commands":[],"methods":[

{"name":"GET"}

,{"name":"POST","messageParameters":{"activeBackupEnabled":

{"acceptableValues":"","optional":"true","type":"boolean","defaultValue":"false"}

,"autoBackupEnabled":

{"acceptableValues":"","optional":"true","type":"boolean","defaultValue":"true"}

,"backupDir":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

,"configOnly":

{"acceptableValues":"","optional":"true","type":"boolean","defaultValue":"false"}

,"id":

{"acceptableValues":"","optional":"false","type":"string","defaultValue":""}

,"recycleLimit":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"25"}

,"schedule":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":"daily"}

}}],"childResources":{}}}

But if you do the same thing in b10, you will see:

{"message":"","command":"backup-configs","exit_code":"SUCCESS","extraProperties":{"commands":[],"methods":[

{"name":"GET"}

,{}],"childResources":

{"ThisIsAModelBug:NoKeyAttr":"http:\/\/bigtruck.us.oracle.com:4848\/management\/domain\/configs\/config\/server-config\/backup-configs\/ThisIsAModelBug:NoKeyAttr"}

}}

If you use the .html, you will see that instead of listing the child resource, it says:
ThisisAModelBug:NoKeyAttr

Assigning this to REST.
I am also changing this to P1 since this is a value add feature, and has to be fixed in 3.1.1
Without the fix, you cannot even list the available backup-config or create any in GUI, which defeats the whole purpose of value-add as far as GUI concerns.

Comment by scatari [ 05/Jul/11 ]

Regression in 3.1.1 in enabling support for a value-added feature? Adding "3_1_1-review" to be discussed in 07/05 bugswat.

Comment by Jason Lee [ 05/Jul/11 ]

Thanks to Ludo's on-vacation-work, we have a fix for this being tested. I have been able to create and delete both configurations and schedules. All REST and Console tests pass. Anissa is currently testing the fix on her end.

Comment by Jason Lee [ 05/Jul/11 ]
  • Why fix this issue in 3.1.1?
    Certain value add functionality is broken without out.
  • Which is the targeted build of 3.1.1 for this fix?
    RC1
  • Do regression tests exist for this issue?
    Not that I'm aware of. Value-add tests can't live in the public repo.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    REST and Console tests

Index: src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java
===================================================================
— src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java (revision 47854)
+++ src/main/java/org/glassfish/admin/rest/generator/ResourcesGeneratorBase.java (working copy)
@@ -110,7 +110,7 @@
ConfigModel childModel = node.getModel();
List<ConfigModel> subChildConfigModels = ResourceUtil.getRealChildConfigModels(childModel, domDocument);
for (ConfigModel subChildConfigModel : subChildConfigModels) {

  • if (ResourceUtil.isOnlyATag(subChildConfigModel)) {
    + if (ResourceUtil.isOnlyATag(subChildConfigModel) || subChildConfigModel.getAttributeNames().isEmpty()) {
    String childResourceClassName = getClassName(ResourceUtil.getUnqualifiedTypeName(subChildConfigModel.targetTypeName));
    String childPath = subChildConfigModel.getTagName();
    classWriter.createGetChildResource(childPath, childResourceClassName);
Comment by Jason Lee [ 06/Jul/11 ]

Fix committed to trunk and branch.

Comment by sunny-gui [ 21/Jul/11 ]

Verified and fixed in build 12, so close this issue. Here are details.

OS: OEL 5 u5 x86
Bundle: ogs-3.1.1-b12-ml.zip
Server Locale: ja_JP.UTF-8
Browser: FF 3.6 / ja & zh_CN ; IE 8.0 / ja





[GLASSFISH-16919] bad reference in javaee.jar manifest.mf Created: 27/Jun/11  Updated: 04/Jul/11  Resolved: 04/Jul/11

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 3.1.1_b11
Fix Version/s: 3.1.1_b11

Type: Bug Priority: Blocker
Reporter: vince kraemer Assignee: ludo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

solaris jdk 6 update 25


Tags: 3_1_1-approved

 Description   

The manifest.mf file has a reference to ../modules/mail.jar.

There isn't a mail.jar in the modules directory.

There is a javax.mail.jar in the modules directory.

This mismatch appears to be the root cause of http://netbeans.org/bugzilla/show_bug.cgi?id=199720, which is a P1 issue... hence the blocker priority.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 30/Jun/11 ]

Assigning to Ludo - javaee.jar manifest needs to be adjusted to point to new mail module jar name.

Comment by ludo [ 03/Jul/11 ]

Fixed first in trunk:
commit -m "Fix for http://java.net/jira/browse/GLASSFISH-16919" /Users/ludo/acvs/v3/extras/javaee/manifest-jar/src/main/resources/META-INF/MANIFEST.MF
Sending /Users/ludo/acvs/v3/extras/javaee/manifest-jar/src/main/resources/META-INF/MANIFEST.MF
Transmitting file data ...
Committed revision 47832.
Committed revision 47832.
Revision: 47832
Author : ludo
Date : Jul 3, 2011 2:01:06 PM
Fix for http://java.net/jira/browse/GLASSFISH-16919

Comment by ludo [ 03/Jul/11 ]

Why fix this issue in 3.1.1?
Blocker for NetBeans IDE
Which is the targeted build of 3.1.1 for this fix?
ready to commit now. Committed to Trunk todya
Do regression tests exist for this issue?
No. Fix is extremely simple: just put the correct jar name javax.mail.jar in the manifest file of the javaee.jar file

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Open the manifest of javaee.jar file from the lib directory and check all relative jar file names which should point to existing jar files.

Comment by ludo [ 03/Jul/11 ]

Just verified the existence of all the jars in the new manifest entry with this command executed from the location of the javaee.jar file:

ludo:lib ludo$ ls -l ../modules/javax.servlet.jar ../modules/endorsed/javax.annotation.jar ../modules/javax.ejb.jar ../modules/javax.transaction.jar ../modules/javax.enterprise.deploy.jar ../modules/javax.management.j2ee.jar ../modules/javax.resource.jar ../modules/javax.security.auth.message.jar ../modules/javax.security.jacc.jar ../modules/webservices-osgi.jar ../modules/jaxb-osgi.jar ../modules/endorsed/jaxb-api-osgi.jar ../modules/endorsed/webservices-api-osgi.jar ../modules/javax.mail.jar ../modules/jsf-api.jar ../modules/javax.servlet.jsp.jar ../modules/javax.servlet.jsp.jstl.jar ../modules/javax.persistence.jar ../modules/javax.jms.jar ../modules/bean-validator.jar ../modules/weld-osgi-bundle.jar ../../mq/lib/jaxm-api.jar ../modules/jersey-core.jar
rw-rr- 1 ludo 501 21868 May 20 13:56 ../../mq/lib/jaxm-api.jar
rw-rr- 1 ludo 501 387458 Jun 30 14:43 ../modules/bean-validator.jar
rw-rr- 1 ludo 501 22329 Jun 30 14:43 ../modules/endorsed/javax.annotation.jar
rw-rr- 1 ludo 501 107445 Jun 30 14:46 ../modules/endorsed/jaxb-api-osgi.jar
rw-rr- 1 ludo 501 55243 Jun 30 14:46 ../modules/endorsed/webservices-api-osgi.jar
rw-rr- 1 ludo 501 64223 Jun 30 14:43 ../modules/javax.ejb.jar
rw-rr- 1 ludo 501 36726 Jun 30 14:43 ../modules/javax.enterprise.deploy.jar
rw-rr- 1 ludo 501 42636 Jun 30 14:45 ../modules/javax.jms.jar
rw-rr- 1 ludo 501 495041 Jun 30 14:43 ../modules/javax.mail.jar
rw-rr- 1 ludo 501 27792 Jun 30 14:43 ../modules/javax.management.j2ee.jar
rw-rr- 1 ludo 501 126856 Jun 30 14:43 ../modules/javax.persistence.jar
rw-rr- 1 ludo 501 58087 Jun 30 14:43 ../modules/javax.resource.jar
rw-rr- 1 ludo 501 35877 Jun 30 14:43 ../modules/javax.security.auth.message.jar
rw-rr- 1 ludo 501 40813 Jun 30 14:43 ../modules/javax.security.jacc.jar
rw-rr- 1 ludo 501 83998 Jun 30 14:43 ../modules/javax.servlet.jar
rw-rr- 1 ludo 501 99562 Jun 30 14:44 ../modules/javax.servlet.jsp.jar
rw-rr- 1 ludo 501 45720 Jun 30 14:44 ../modules/javax.servlet.jsp.jstl.jar
rw-rr- 1 ludo 501 23756 Jun 30 14:43 ../modules/javax.transaction.jar
rw-rr- 1 ludo 501 5391515 Jun 30 14:46 ../modules/jaxb-osgi.jar
rw-rr- 1 ludo 501 458233 Jun 24 12:41 ../modules/jersey-core.jar
rw-rr- 1 ludo 501 626229 Jun 30 14:44 ../modules/jsf-api.jar
rw-rr- 1 ludo 501 10492795 Jun 30 14:46 ../modules/webservices-osgi.jar
rw-rr- 1 ludo 501 2660370 Jun 30 14:45 ../modules/weld-osgi-bundle.jar

All file references are good now.

Comment by ludo [ 04/Jul/11 ]

checked in for b11:
commit -m "Fix for http://java.net/jira/browse/GLASSFISH-16919..." /Users/ludo/acvs/a311/3.1.1/extras/javaee/manifest-jar/src/main/resources/META-INF/MANIFEST.MF
Sending /Users/ludo/acvs/a311/3.1.1/extras/javaee/manifest-jar/src/main/resources/META-INF/MANIFEST.MF
Transmitting file data ...
Committed revision 47833.
Committed revision 47833.
Revision: 47833
Author : ludo
Date : Jul 4, 2011 9:21:12 AM
Fix for http://java.net/jira/browse/GLASSFISH-16919
3.1.1 approved. Also in trunk





[GLASSFISH-17101] JMS Connection Factory lookup failed with clustered JMS Created: 25/Jul/11  Updated: 26/Jul/11  Resolved: 26/Jul/11

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

Type: Bug Priority: Blocker
Reporter: magnus12345678 Assignee: Satish Kumar
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 64 bit, Glassfish 3.1 in cluster



 Description   

JMS Connection Factory lookup failed
Environment:
Clustered Glassfish 3.1 with JMS cluster(built-in OpenMQ)
JMS cluster setup:
JMS Availability : shareddb
Mode(EMBEDDED/LOCAL/REMOTE): LOCAL

Source code to get ConnectionFactory:
javax.naming.InitialContext jndi = new javax.naming.InitialContext();
ConnectionFactory qFactory = (ConnectionFactory) jndi.lookup("jms/queueConnectionFactory");

It seems jms/queueConnectionFactory is not available in the context.



 Comments   
Comment by kumara [ 25/Jul/11 ]

Please provide detailed steps to reproduce including how JMS cluster was configured and where/how the code segment is being run.

Comment by Satish Kumar [ 26/Jul/11 ]

This is a duplicate of 17099. Hence closing this issue.





[GLASSFISH-16890] [Blocking] Console does not come up on AIX systems when sun-web-app_2_3-0.dtd cannot be fetched. Created: 21/Jun/11  Updated: 14/Jul/11  Resolved: 07/Jul/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1_b08
Fix Version/s: 3.1.1_b10

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

AIX, IBM JDK 6, both 32 and 64 versions, Glassfish build b04 - b08, first noticed on b08, now reproducible with earlier builds even though not seen before when those were tested.


Attachments: Text File server.log     XML File sun-web.xml     Java Source File XMLTest.java    
Tags: 3_1_1-approved, 3_1_1-verified

 Description   

Admin Console does not come up on some AIX systems. We are uncertain at this point what is causing the issue. It shows up with both 32 and 64 JDK installations, secure admin enabled and disabled, when Glassfish is installed as root and non root user. The exceptions are always the same:

[#|2011-06-21T17:57:01.574-0700|INFO|glassfish3.1|com.sun.grizzly.config.Grizzly
ServiceListener|_ThreadID=12;_ThreadName=Thread-8;|Listening to REST requests at
context: /management/domain|#]

[#|2011-06-21T17:58:10.555-0700|SEVERE|glassfish3.1|javax.enterprise.system.cont
ainer.web.com.sun.enterprise.glassfish.web|_ThreadID=11;_ThreadName=Thread-8;|ja
va.net.ConnectException: A remote host did not respond within the timeout period
.|#]

(...)

[#|2011-06-21T17:59:33.215-0700|SEVERE|glassfish3.1|javax.enterprise.resource.we
bcontainer.jsf.config|_ThreadID=11;_ThreadName=Thread-8;|Critical error during d
eployment:
com.sun.faces.config.ConfigurationException:
Source Document: jndi:/__asadmin/WEB-INF/faces-config.xml
Cause: Unable to find class 'com.sun.webui.jsf.faces.UIComponentELResolver'
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance
(AbstractConfigProcessor.java:273)
at com.sun.faces.config.processor.ApplicationConfigProcessor.addELResolv
er(ApplicationConfigProcessor.java:574)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(App
licationConfigProcessor.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(Abs
tractConfigProcessor.java:114)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(Lifec
ycleConfigProcessor.java:116)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(Abs
tractConfigProcessor.java:114)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(Factory
ConfigProcessor.java:222)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:360)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureLi
stener.java:225)
at org.apache.catalina.core.StandardContext.contextListenerStart(Standar
dContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:
531)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5
366)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:90
1)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1
997)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1
648)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:101)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.jav
a:294)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationL
ifecycle.java:462)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplicat
ion(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThr
ead.java:210)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThre
ad.java:108)
Caused by: java.lang.ClassNotFoundException: com.sun.webui.jsf.faces.UIComponent
ELResolver
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoade
r.java:1519)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoade
r.java:1369)
at com.sun.faces.util.Util.loadClass(Util.java:281)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(Abst
ractConfigProcessor.java:311)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance
(AbstractConfigProcessor.java:240)
... 25 more

#]

I'm logging this issue for tracking purposes.



 Comments   
Comment by Anissa Lam [ 22/Jun/11 ]

You mean on the same system, without any configuration change, using the same build, login to the system as the same person before, you were able to bring up the console. but now, the console failed to start ?
Something got to be changed to cause the error. This is really puzzling.

Comment by lidiam [ 22/Jun/11 ]

I've searched content of jars under glassfish/modules and glassfish/lib directories but cannot find a jar containing com.sun.webui.jsf.faces.UIComponentELResolver class. Where is it expected to reside?

Comment by lidiam [ 22/Jun/11 ]

It seems that once someone gets these exceptions, they are always displayed, even when moving back to Glassfish version that worked previously on the same system. I checked with IT and there have been no changes done to the AIX systems. Also, I compared PATH between a machine where Admin Console still works, with one that does not. I made changes to make the java settings identical, but that did not resolve the issue:

System where things still work:

bash-3.2# echo $PATH
/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java5/jre/bin:/usr/java5/bin

bash-3.2# ls -l /usr/bin/java
lrwxrwxrwx 1 root system 19 May 19 10:11 /usr/bin/java -> /usr/java6/bin/java

bash-3.2# which java
/usr/bin/java

bash-3.2# java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr9fp1-20110208_03(SR9 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 jvmap3260sr9-20110203_74623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT - r9_20101028_17488ifx3
GC - 20101027_AA)
JCL - 20110203_01

System where Admin Console does not come up:

bash-3.00# echo $PATH
/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/export/sqe/lidia/glassfish3/bin:/export/hudson/tools/ant-1.7.1/bin:.

bash-3.00# ls -l /usr/bin/java
lrwxrwxrwx 1 root system 19 Jun 22 13:28 /usr/bin/java -> /usr/java6/bin/java

bash-3.00# which java
/usr/bin/java

bash-3.00# java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr9fp1-20110208_03(SR9 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 jvmap3260sr9-20110203_74623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT - r9_20101028_17488ifx3
GC - 20101027_AA)
JCL - 20110203_01

Comment by lidiam [ 22/Jun/11 ]

Tried Oracle branded and open source versions of Glassfish, also tried rebooting machine. Console fails in all cases, once the initial exception encountered.

Comment by sirajg [ 22/Jun/11 ]

Can you try deploying other web applications on systems that are failing to load admin console?

Comment by Dhiru Pandey [ 22/Jun/11 ]

BTW the class exist in my install location in the following jar:
~/work/appserv/v3/3.1.1/aix-install/glassfish3/glassfish/lib/install/applications/__admingui/WEB-INF/lib/webui-jsf-4.0.2.7.jar

Comment by lidiam [ 22/Jun/11 ]

And even when the webui jar file was moved to glassfish3/glassfish/lib, console still did not come up with the same error.

Btw, deploying hello.was works fine (comes up no problem).

Comment by lidiam [ 22/Jun/11 ]

Raising to Blocker status per Sathyan's request.

Comment by Anissa Lam [ 23/Jun/11 ]

1. Jane pointed me to http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.1-aix-build/
It shows that QL was passing on Friday (build# 281), then, Sahoo integrated

GLASSFISH-16764: [osgi-http] request.getSession().getServletContext() should return the same OSGiServletContext that's used during setAttrbute().
GLASSFISH-16880: [osgi-http] NPE in Activator.stop() if start() has failed.

The above bugs are fixed by migrating to osgi-http version 1.0.4 from 1.0.2 (detail)

and then QL starts failing on build# 282, with the exact same stack trace we are all seeing.
Of course, this doesn't explain why build 04 which used to be working failed on the same machine without any configuration change.

2. Sahoo suggested adding the jvm option, "<jvm-options>-verbose:class</jvm-options>" in domain.xml to see if the class is really loaded and from where.

3. If we think this is related to JDK, we should try installing the IBM JDK on a Linux machine, that may isolate if it is due to the JDK or AIX or other factor.

Jane is also working with Sahoo now on this issue.

Comment by Sanjeeb Sahoo [ 23/Jun/11 ]

The offending code is in WarHandler.java:

public ClassLoader getClassLoader(ClassLoader parent, DeploymentContext context) {
WebappClassLoader cloader = new WebappClassLoader(parent);
try {
FileDirContext r = new FileDirContext();
File base = new File(context.getSource().getURI());
r.setDocBase(base.getAbsolutePath());

cloader.setResources(r);
cloader.addRepository("WEB-INF/classes/", new File(base, "WEB-INF/classes/"));
if (context.getScratchDir("ejb") != null)

{ cloader.addRepository(context.getScratchDir("ejb").toURI().toURL().toString().concat("/")); }

if (context.getScratchDir("jsp") != null)

{ cloader.setWorkDir(context.getScratchDir("jsp")); }

// add libraries referenced from manifest
for (URL url : getManifestLibraries(context))

{ cloader.addRepository(url.toString()); }

WebXmlParser webXmlParser = null;
if ((new File(base, GLASSFISH_WEB_XML)).exists())

{ webXmlParser = new GlassFishWebXmlParser(base.getAbsolutePath()); } else if ((new File(base, SUN_WEB_XML)).exists()) { webXmlParser = new SunWebXmlParser(base.getAbsolutePath()); } else if ((new File(base, WEBLOGIC_XML)).exists()) { webXmlParser = new WeblogicXmlParser(base.getAbsolutePath()); } else { webXmlParser = new GlassFishWebXmlParser(base.getAbsolutePath()); }

configureLoaderAttributes(cloader, webXmlParser, base);
configureLoaderProperties(cloader, webXmlParser, base);

} catch(MalformedURLException malex) {
logger.log(Level.SEVERE, malex.getMessage());
if (logger.isLoggable(Level.FINE))

{ logger.log(Level.FINE, malex.getMessage(), malex); }

} catch(XMLStreamException xse) {
logger.log(Level.SEVERE, xse.getMessage());
if (logger.isLoggable(Level.FINE))

{ logger.log(Level.FINE, xse.getMessage(), xse); }

} catch(FileNotFoundException fnfe) {
logger.log(Level.SEVERE, fnfe.getMessage());
if (logger.isLoggable(Level.FINE))

{ logger.log(Level.FINE, fnfe.getMessage(), fnfe); }

}

cloader.start();

return cloader;
}

If it gets an exception in creating SunWebXmlParser, then it does not add WEB-INF/lib/*.jar to search path of web app class loader. For some reason, it is going to intenet to fetch the dtd while creating the SunWebXmlParser and because of network configuration, it is not able to go to internet. So, it is failing with a ConnectException. Three things to do:

a) Set up the networking layer to use proxy. This will make the test pass.
b) Find out why we are going to internet to fetch the dtd instead of using local dtd store. If this is a recent change, that's the culprit.
c) Fix WarHandler to fail instead of continuing if SunWebXmlParser can't be created. We don't have time to debug such useless class loading issues.

Thanks to Jane for help in debugging the issue.

Comment by oleksiys [ 23/Jun/11 ]

The root problem is that during parsing
glassfish3/glassfish/lib/install/applications/__admingui/WEB-INF/sun-web.xml

the xml parser is trying to download dtd from
http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-0.dtd

and this fails (time out expires), because proxy is not set.

Comment by Tom Mueller [ 23/Jun/11 ]

More on fetching the DTD. Recently, the www.sun.com URL for the DTD was redirected to a www.oracle.com URL:

http://www.oracle.com/webfolder/technetwork/sun/software/dtd/appserver/sun-web-app_2_3-0.dtd

However, the lab systems within OWAN cannot connect to www.oracle.com without a proxy, and not only that, when they do try to connect, it takes a long time (we've seen 7.5 minutes on glassfish-x86-1) for the connection to fail and then it fails a "no route to host" message.

Comment by Alex Pineda [ 23/Jun/11 ]

Adding "blocking" to the bug synopsis for easy identification and upcoming bug swat meetings.

Comment by Anissa Lam [ 23/Jun/11 ]

Thanks everyone for helping to solve this issue.
So, this doesn't sound like a GUI specific problem, since any web application may specify this dtd and may end up failing mysteriously without knowing what maybe the cause.
I am transferring this to web-container to see if it is possible to log the error so its easer for user to debug the problem.
I am also downgrading this from 'blocker'.

Although the redirect should take care of the problem, we will also update the dtd URL to the oracle.com site so we don't rely on the redirect.

Comment by Anissa Lam [ 23/Jun/11 ]

Think Alex and I tried to update the issue at the same time, and mine removed his changes.
I will change the synopsis and put back the blocker priority since thats what QA thinks it should be.

Comment by Tom Mueller [ 23/Jun/11 ]

Anissa,
The redirect is not the problem. Lab machines are still able to get to www.sun.com just fine without a proxy. It is the access to www.oracle.com after the redirect that is the problem.

Comment by Alex Pineda [ 23/Jun/11 ]

I just tried by setting the proxy as a general environment setting on my setup as follows:

#Proxy Setup
http_proxy=http://www-proxy.us.oracle.com:80/
export http_proxy

but I still see the same problem and I'm not able to bring up the Admin Console. I believe it should come up with my setting if the proxy is the problem. I'm not clear on what the workaround to this problem. I think we still have a problem.

Comment by sirajg [ 23/Jun/11 ]

I tried using the workaround by specifying these in the domain.xml :
<jvm-options>-Dhttp.proxyHost=www-proxy.us.oracle.com</jvm-options>
<jvm-options>-Dhttp.proxyPort=80</jvm-options>
in <java-config> and the console comes up properly.

Comment by Sanjeeb Sahoo [ 23/Jun/11 ]

Few observations:

Alex,

Use -Dhttp.proxyHost=www-proxy.us.oracle.com in domain.xml. See [1].

Anissa/Tom,

File a bug against deployment/web container, whoever is responsible for creating *WebXmlParser, to not fetch the dtd from Internet. They should be able to match the dtd from glassfish/lib/dtds. We must NOT assume there is Internet connection available to use admin console or any web app for that matter.

Sahoo

[1] http://download.oracle.com/javase/6/docs/technotes/guides/net/proxies.html

Comment by Anissa Lam [ 23/Jun/11 ]

This bug is already under web container, assigned to oleksiys as I thought if the dtd cannot be fetched, error should be logged so user is informed what maybe the problem.
But Sahoo's suggestion about fixing the code so that it doesn't fetch the dtd from the internet is even better. GlassFish shouldn't require to have network access in order for any web application to work.

So, I will just leave this bug as it is for web container to fix it by not depending on the network, instead of opening up another bug.

thanks.

Comment by Alex Pineda [ 23/Jun/11 ]

Just to make sure I understand. Siraj and Sahoo's suggestion is only a workaround for this problem. The real solution will happen when the Web Container is fixed. Correct? Can someone confirm?

Comment by Anissa Lam [ 23/Jun/11 ]

Thats my expectation too.
After WebHandler is modified to fetch the dtd locally, instead of going through the network to get it from oracle.com, this bug will then be marked resolved.

Comment by Shing Wai Chan [ 23/Jun/11 ]

I think other DTDs will have the same issue, too. I think the deployment side should try to look at local first before going to internet.

Comment by Sanjeeb Sahoo [ 23/Jun/11 ]

There are two bugs here, so there should be two bugs filed in the system to track them:

a) web container should not allow the app to be deployed when WarHandler failed to parse sun-web.xml.
b) web container and/or deployment backend must not rely on Internet connectivity.

#a & #b are independent of each other.

Comment by oleksiys [ 24/Jun/11 ]

sorry guys,
I'm not looking into this issue
reassigning to Shing Wai (as web container owner), so he can dispatch it properly.

Comment by Tim Quinn [ 24/Jun/11 ]

Shing Wai and Sahoo,

The deployment code which parses descriptors already reads DTDs and schemas from the local copies if local copies exist. (See deployment/dol SaxParserHandler.java).

The only time this will not happen is if the XML document refers to a DTD or schema for which GlassFish does not have a local copy. Then it will try to find the DTD or schema over the network. (In the past the usual cause for this we have seen is if the descriptor contains a misspelling of the system ID or public ID or the schema path.)

It looks as if the parsers in WarHandler might need to invoke setXMLResolver (with a suitable resolver implementation) on the factory before creating the XML reader.

If someone can document a case where deployment's parsing is failing to find a local copy that exists please open a separate issue.

Comment by Sanjeeb Sahoo [ 24/Jun/11 ]

Tim,

That's what I have been saying. *WebXmlParser in WarHandler does not set the resolver to first search local store for dtds. You can see the code for these classes in WarHandler.java. That's why I asked Anissa & team to file a separate bug for fixing the dtd resolver issue.

Sahoo

Comment by Tim Quinn [ 24/Jun/11 ]

Sahoo,

You also said "web container and/or deployment backend must not rely on Internet connectivity." Plus Shing-wai earlier said "the deployment side should try to look at local first."

Deployment does not seem to be implicated in this issue, plus its XML parsing does not access the network - unless the requested DTD or schema is not in the local set. I wanted to eliminate any potential confusion your and Shing Wai's comments might have caused so no one was expecting a fix from deployment for this issue.

Comment by Sanjeeb Sahoo [ 24/Jun/11 ]

Tim,

Did you look at SunWebXmlParser in WarHandler.java? None of those Sun/GlassFish/WebLogicWebXmlParsers instruct the XmlParser to search the local DTD store. Now, deployment or web container team has to figure out who owns that piece of code.

Sahoo

Comment by Tim Quinn [ 24/Jun/11 ]

Sahoo,

I had already looked at the code, as indicated by my earlier comment.

Given that WarHandler is in the web/war-util module and looking at the svn check-in annotations for those lines in the class, the web container team clearly should own this issue. Your and Shing Wai's mention of deployment added confusion I wanted to clear up.

Comment by Shing Wai Chan [ 24/Jun/11 ]

In WarHandler.java, we have
xmlIf.setProperty(XMLInputFactory.SUPPORT_DTD, false);

With Oracle JDK, it will not go to access the dtd. This is not the case for IBM JDK in AIX and Linux.
I have illustrated this in the attached standalone java program XMLTest.java. The usage is as follows:

java XMLTest sun-web.xml
where sun-web.xml has a DTD.

So, if a proxy is needed to be set in a machine, then one will see an exception as follows:

Exception in thread "main" javax.xml.stream.XMLStreamException: java.net.ConnectException: A remote host did not respond within the timeout period.
at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwXMLStreamException(StAXMessageProvider.java:64)
at com.ibm.xml.xlxp.api.stax.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:539)
at com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl$XMLStreamReaderProxy.next(XMLInputFactoryImpl.java:180)

Comment by Shing Wai Chan [ 24/Jun/11 ]

Note that there are several different places using XMLInputFactory, for instance, deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java

So, there may be similar issue with IBM JDK.

Comment by Shing Wai Chan [ 27/Jun/11 ]

According to http://www.ibm.com/developerworks/java/jdk/aix/j664/sdkguide.aix64.html , XMLInputFactory.SUPPORT_DTD will work only when an additional system property (jvm-option) com.ibm.xml.xlxp.support.dtd.compat.mode = false.

If the above ibm specific property is set, then the attached standalone program and the admin console can be started.

Comment by scatari [ 27/Jun/11 ]

Another AIX specific VM config requirement? Should we then put this in an AIX specific template?

Comment by Sanjeeb Sahoo [ 27/Jun/11 ]

Switching off dtd validation is not a desirable solution. As Tim said, we should use a XMLReoslver [1] to ensure that we can resolve the dtd reference from a local repository.

[1] http://download.oracle.com/javase/6/docs/api/javax/xml/stream/XMLResolver.html

Comment by Shing Wai Chan [ 27/Jun/11 ]

The parser in WarHandler is intended to parse a subset of information quickly. Turning off dtd support at that point is for performance reason.
Note that the deployment backend will parse the deployment descriptor in details later.

Comment by scatari [ 28/Jun/11 ]

I have added a new template file for AIX(domain-aix.xml) under packager/nucleus-base/lib/templates. Please update this file to add any AIX specific VM arguments or domain config elements. This file will be automatically picked up during AIX packaging/bundle generation process and will be ignored during non-AIX builds.

Comment by Shing Wai Chan [ 28/Jun/11 ]

Adding a new template is difficult to maintain.
Should we have a way to transform a general template to AIX specific one, for instance using xslt?

Comment by scatari [ 28/Jun/11 ]

Are you worried about having to maintain two different templates of domain.xml? Remember we are not supposed to change the domain.xml in a minor release. This is just a one off exercise we are doing till the underlying issues are resolved. This has to be fixed before COB 06/29 in time for HCF build(b10). If you can think of another way to resolve this without introducing additional template, that would be really great and please do share the implementation details here.

Comment by Shing Wai Chan [ 28/Jun/11 ]

I have a xslt ready in my workspace.
Please update the packager if necessary so that it will invoke a xslt for ibm jdk.
Note that there is already one xslt file in template directory.

Comment by Snjezana Sevo-Zenzerovic [ 28/Jun/11 ]

Shing Wai, please go ahead and tweak packager/nucleus-base/build.xml to invoke xslt if AIX platform is detected at build time.

Comment by Shing Wai Chan [ 30/Jun/11 ]

fix in 3.1.1
Sending packager/nucleus-base/build.xml
Adding packager/nucleus-base/lib/templates/domain.xml.aix.xsl
Sending packager/nucleus-base/pom.xml
Transmitting file data ...
Committed revision 47796.

Sending packager/nucleus-base/build.xml
Adding packager/nucleus-base/lib/templates/domain.xml.aix.xsl
Sending packager/nucleus-base/pom.xml
Transmitting file data ...
Committed revision 47797.

Comment by Alex Pineda [ 05/Jul/11 ]

Did this fix make into build 10. I'm trying to install and the Admin Console does not come up. Do I have to add the workaround as jvm-config option in domain.xml such as,

<jvm-options>-Dhttp.proxyHost=www-proxy.us.oracle.com</jvm-options>
<jvm-options>-Dhttp.proxyPort=80</jvm-options>
in <java-config>

Please advise.

Comment by scatari [ 05/Jul/11 ]

Yes, it did and the fix should be visible out of the box(no workarounds needed).

Comment by Shing Wai Chan [ 05/Jul/11 ]

Please make sure that IBM JDK is Service Refresh 2 or later.

Comment by lidiam [ 05/Jul/11 ]

I tried promoted build b10 and the issue still exists. The jdk on the machine is:

/export/sqe/lidia/glassfish3/glassfish/domains/domain1/logs % java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap6460sr9fp1-20110208_03(SR9 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460sr9-20110203_74623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT - r9_20101028_17488ifx3
GC - 20101027_AA)
JCL - 20110203_01

I presume SR9 stands for Service Refresh 9.

Comment by lidiam [ 05/Jul/11 ]

Fix was not present in promoted build b10. Verified in latest nightly build ogs-3.1.1-b11-07_04_2011-aix.zip and workaround is not needed.

Comment by Shing Wai Chan [ 06/Jul/11 ]

additional fix for issue http://java.net/jira/browse/GLASSFISH-16890
("[Blocking] Console does not come up on AIX systems when
sun-web-app_2_3-0.dtd cannot be fetched.)

  • revert the previous fix of adding IBM specified jvm option in domain.xml
    since this will introduce the dependency of server on jvm option
  • refactoring *arHandler in deployment so that the XMLInputFactory
    is created in the base class
  • add an zero-byte XMLResolver (in addition to existing SUPPORT_DTD=false)
    this will be invoked when IBM jdk is used without the required jvm option

fix in trunk:
Sending deployment/common/src/main/java/com/sun/enterprise/deploy/jar/JarHandler.java
Sending deployment/common/src/main/java/com/sun/enterprise/deploy/shared/AbstractArchiveHandler.java
Sending deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
Sending packager/nucleus-base/build.xml
Deleting packager/nucleus-base/lib/templates/domain.xml.aix.xsl
Sending packager/nucleus-base/pom.xml
Sending web/war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java
Transmitting file data ......
Committed revision 47879.

fix in 3.1.1:
Sending deployment/common/src/main/java/com/sun/enterprise/deploy/jar/JarHandler.java
Sending deployment/common/src/main/java/com/sun/enterprise/deploy/shared/AbstractArchiveHandler.java
Sending deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
Sending packager/nucleus-base/build.xml
Deleting packager/nucleus-base/lib/templates/domain.xml.aix.xsl
Sending packager/nucleus-base/pom.xml
Sending web/war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java
Transmitting file data ......
Committed revision 47880.

Comment by lidiam [ 07/Jul/11 ]

Reopening, since the new fix will have to be tested again.

Comment by lidiam [ 07/Jul/11 ]

This issue is resolved. I'll test the fix in the next build available.

Comment by scatari [ 08/Jul/11 ]

Are we hitting a similar issue here http://java.net/jira/browse/JAX_WS-951 ?

Comment by lidiam [ 08/Jul/11 ]

Verified in build ogs-3.1.1-b11-07_07_2011-aix.zip.

Comment by lidiam [ 14/Jul/11 ]

Also verified on promoted build ogs-3.1.1-b11-aix.zip.





JSessionID from url dropped in case of http/ https redirect cycle (GLASSFISH-17131)

[GLASSFISH-17191] jsessionId is lost while redirecting from https to http Created: 15/Aug/11  Updated: 26/Aug/11  Resolved: 26/Aug/11

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

Type: Sub-task Priority: Blocker
Reporter: KBachl Assignee: Shing Wai Chan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all, tested with GlassFish Server Open Source Edition 3.2-SNAPSHOT (re-continuous), Build #9159 (14.08.2011 23:30:35), Revision: 48776



 Description   

fix in GLASSFISH-17131 made now HTTP->HTTPS ccle working, but in HTTPS->HTTP traversal jsessionId is still lost; Can be viewed by the example app in GLASSFISH-17131;



 Comments   
Comment by Shing Wai Chan [ 19/Aug/11 ]

Per discussion in http://java.net/jira/browse/GLASSFISH-17131 and the original description, I think you mean the scenario of http to https.

For https to http, there is a concern of exposing the cookies through url. That is why I do not encode the jsessionId in this case.

Comment by KBachl [ 20/Aug/11 ]

Hello Shing Wai,

you need to differ if the session was created in HTTP (1 = insecure session) or HTTPS (2 = secure session).

In case of HTTP created session (1):

-> user gets jsessionId, he may move on to https and also leave https to http side without loosing the session

In case of HTTPS created session (2):

-> user gets jsessionId, he may not leave from HTTPS and will loose his session there;

Currently any session traversal from HTTPS to HTTP will loose, independent of when it was created. The above described behaviour is also implemented exactly that way in other containers like Tomcat, Jetty and JBOSS as it immitates the behaviour from browser cookies. Those are only marked secure in case they were created within HTTPS space.

Currently one can't rely on glassfish URL rewriting as it will loose any insecure sessions in case of a HTTPS->HTTP traversal.

If you have any questions left or don't think that my arguments are valid just tell me

Best

Comment by Shing Wai Chan [ 24/Aug/11 ]

I have considered this scenario before. The question is how we know whether a session is secure (from https) or not. The information is not exposed from HttpSession.
One may require an interface change, at least the internal one, in order to achieve this.
Need further investigation.

Comment by KBachl [ 24/Aug/11 ]

Hello Shing Wai,

regarding the differentation. Why don't you introduce a flag within the session, stating "boolean isSecureSession = false" and only set this true when session is created within HTTPS space. Then in case of HTTPS -> HTTP change you only look if the session is Secure and act accordingly.

Comment by Shing Wai Chan [ 24/Aug/11 ]

This will workaround the issue. But then user can modified the flag in session.

Comment by Shing Wai Chan [ 26/Aug/11 ]

The https issue can be resolved by adding secure attribute in internal Session interface.
Then we will face the issue as in GLASSFISH-17131.
In that case, a different port number (with same or different schema) is not enough to tell whether it is a redirect within the same server. In fact, it may be different server.

We will mark this as a duplicate of GLASSFISH-17131.





[GLASSFISH-16672] [BLOCKING] AIX: Too many open files exception Created: 17/May/11  Updated: 04/Jan/12  Resolved: 04/Jan/12

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b10, 3.1.2

Type: Bug Priority: Blocker
Reporter: lidiam Assignee: sirajg
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish server 3.1.1 b4 and b5 on AIX 6.1


Attachments: File console-common.diff     Text File domain1.server.log     File netstat.aixas12.out     Text File netstat.all.domain1-actions.txt     JPEG File openfiles_exception.JPG     File server.log.exception    
Issue Links:
Dependency
depends on JERSEY-725 Run out of sockets on AIX Resolved
Tags: 3_1_1-approved, 3_1_1-verified, 3_1_2-review

 Description   

This may be a matter of documenting tuning of AIX for Glassfish application server, however, I'm logging it first under Admin GUI component to verify that we are not leaking file descriptors.

Here is the issue I encountered:

After clicking Launch link on Applications page got the following exception was displayed in new window:

HTTP Status 500 -

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'page1'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'page1'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.RuntimeException: com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Connection reset

root cause

com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Connection reset

root cause

java.net.SocketException: Connection reset

The server.log had an additional exception:

[#|2011-05-17T15:09:59.672-0700|WARNING|oracle-glassfish3.1|com.sun.grizzly.conf
ig.GrizzlyServiceListener|_ThreadID=5;_ThreadName=Thread-6;|GRIZZLY0006: Excepti
on accepting channel
java.io.IOException: Too many open files

I still clicked around Administration Console and after clicking Applications link, got the following exception in the Admin Console window, right frame:

HTTP Status 500 -

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event157'.

root cause

java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event157'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeEncode' event for 'event157'.

root cause

java.lang.reflect.InvocationTargetException

root cause

com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Too many open files

root cause

java.net.SocketException: Too many open files

I found the following information on tuning AIX (at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tuneaix.html):

  1. AIX file descriptors (ulimit)
  • Description: Specifies the various restrictions on resource usage on the user account. The ulimit -a command displays all the ulimit limits. The ulimit -a command specifies only the number of open files that are permitted. The default number of open files setting (2000) is typically sufficient for most applications. If the value set for this parameter is too low, errors might occur when opening files or establishing connections. Because this value limits the number of file descriptors that a server process might open, a value that is too low prevents optimum performance.
  • How to view or set: Perform the following steps to change the open file limit to 10,000 files:
    1. Open the command window.
    1. Edit the /etc/security/limits file. Add the following lines to the user account that the WebSphere Application Server process runs on:

nofiles = 10000
nofiles_hard = 10000

2. Save the changes.
3. Restart your AIX system.
4. To verify the result, type the ulimit -a command on the command line. For example, type # ulimit -a.

  • Default value: For the AIX operating system, the default setting is 2000.
  • Recommended value: The value is application dependent and applies exclusively to application program data and the application stack.

Increasing the ulimit file descriptor limits might improve performance. Increasing some of the other limits might be needed depending on your application. Any changes to the data or stack ulimits should ensure that data+stack < 256MB (for 32-bit WebSphere Application Server only).

It is recommended that you change the ulimit for data to "unlimited".

Some of the above may be applicable to Glassfish.



 Comments   
Comment by sirajg [ 18/May/11 ]

Cannot reproduce this issue.

Comment by Anissa Lam [ 18/May/11 ]

Paste email discussion so it won't get lost.
We don't know what exact sequence will reproduce this problem, and how does it help user on documenting this.
Transfer this back to Lidia, she can close this as not-reproducible, or transfer to doc with what she believes should be documented.

On 5/18/11 1:07 PM, Lidia Marchioni wrote:
> Hi Siraj
>
> What are different actions that can cause this? I restarted domain2, and I'm guessing that the issue is no longer seen because of this. Any idea how I can reproduce this condition? It was not pretty once it happened.

I don't know what specific sequence you need to go through to reproduce this. In general, going through OS settings and documentation should give an idea on the file descriptor limit.

> I think that in the least we should document changing the file descriptor limit as mentioned in the web sphere doc. Do you agree?
>
May be. I don't have a lot of experience with AIX.
> Lidia
>
>
> On 5/18/2011 9:40 AM, Siraj Ghaffar wrote:
>> Hi Lidia,
>> I cannot reproduce the issue. Things work fine on the machine you pointed me to. In general, the behavior you saw might be caused by different factors, not necessary related to the sequence you reported in the issue.
>>
>> Thanks
>> --Siraj

Comment by lidiam [ 23/May/11 ]

I am again seeing this issue. I have 2 domains on the machine with the following processes running since Friday afternoon:

1. domain1
a. DAS
b. standalone instance
c. cluster with 2 instances

2. domain2
a. DAS
b. cluster with 2 instances

I brought up Admin Console for domain1. Clicked Standalone Instances, in1 and got the following error displayed:

HTTP Status 500 -

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event155'.

root cause

java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event155'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeEncode' event for 'event155'.

root cause

java.lang.reflect.InvocationTargetException

root cause

com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Too many open files

root cause

java.net.SocketException: Too many open files

note The full stack traces of the exception and its root causes are available in the Oracle GlassFish Server 3.1.1 logs.

It seems to me that in order to reproduce this issue, one needs to start a few Glassfish server instances, preferably on two domains, deploy a couple of apps and leave the system running for a day. However, I cannot determine why we are getting into this situation. It would be great to talk to an AIX expert regarding this issue. Following is information I gathered.

I checked Glassfish processes and number of file descriptors they use (via ls /proc/<pid>/fd), here is the output:

1. domain1

a. DAS
bash-3.2# ls -l /proc/266422/fd | wc
1946 17507 121462

b. in1
bash-3.2# ls -l /proc/327882/fd | wc
526 4727 32453

c. cl1in1
bash-3.2# ls -l /proc/331950/fd | wc
527 4736 32515

d. cl1in2
bash-3.2# ls -l /proc/323772/fd | wc
527 4736 32515

2. domain2

a. DAS
bash-3.2# ls -l /proc/290972/fd | wc
1573 14150 97968

b. cl1in1
bash-3.2# ls -l /proc/307386/fd | wc
527 4736 32515

c. cl1in2
bash-3.2# ls -l /proc/311488/fd | wc
527 4736 32515

I've researched it a little further and we are running out of TCP sockets and not file handles:

Caused by: com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Too many open files
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle
(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:45
9)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:668)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java
:185)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(Re
stApiHandlers.java:210)
... 50 more
Caused by: java.net.SocketException: Too many open files
at java.net.Socket.createImpl(Socket.java:407)
at java.net.Socket.connect(Socket.java:537)
at java.net.Socket.connect(Socket.java:488)
at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:407)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:542)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:246)
at sun.net.www.http.HttpClient.New(HttpClient.java:319)
at sun.net.www.http.HttpClient.New(HttpClient.java:336)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLC
onnection.java:980)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConne
ction.java:865)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection
.java:846)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLCon
nection.java:1182)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390
)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invok
e(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle
(URLConnectionClientHandler.java:129)
... 57 more

I looked at port use on the system and found the following:

total for localhost:
bash-3.2# netstat -a | grep localhost | wc
350 2100 27294

total in close wait state:
bash-3.2# netstat -a | grep CLOSE_WAIT | wc
346 2076 26988

total for DAS2 (port 5858):
bash-3.2# netstat -a | grep 5858 |wc
311 1866 24254

Out of the above domain2 DAS ports, 310 are in CLOSE_WAIT state:
bash-3.2# netstat -a | grep 5858 | grep CLOSE_WAIT |wc
310 1860 24180

Thus, it looks to me that in order to reproduce this issue, it should be enough to create a second domain and start it. Not certain if accessing it via Admin Console is needed. I'll attach file with netstat output.

Comment by lidiam [ 23/May/11 ]

After restarting domain2, all CLOSE_WAIT ports got released and only one was in use, as expected:

bash-3.2# netstat -a | grep 5858
tcp 0 0 .5858 *. LISTEN

Loading Admin Console for domain2 from a Windows XP machine:

bash-3.2# netstat -a | grep 5858
tcp4 0 0 aixas12.us.oracl.5858 aixas12.us.oracl.40176 ESTABLISHED
tcp 0 0 aixas12.us.oracl.40176 aixas12.us.oracl.5858 ESTABLISHED
tcp 0 0 .5858 *. LISTEN
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.semap ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.cpqrp ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.cpqrp ESTABLISHED

After Admin Console is loaded:

bash-3.2# netstat -a | grep 5858
tcp4 0 0 localhost.5858 localhost.40196 ESTABLISHED
tcp 0 0 localhost.40196 localhost.5858 ESTABLISHED
tcp 0 0 .5858 *. LISTEN
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.semap ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.cpqrp ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.cpqrp ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.msft- ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.veris ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.csoft ESTABLISHED

From here on the use of sockets goes up quickly: a couple clicks in Admin Console:

bash-3.2# netstat -a | grep 5858
tcp4 0 0 localhost.5858 localhost.40196 FIN_WAIT_2
tcp 0 0 localhost.40196 localhost.5858 CLOSE_WAIT
tcp4 0 0 localhost.5858 localhost.40223 ESTABLISHED
tcp 0 0 localhost.40223 localhost.5858 ESTABLISHED
tcp4 0 0 localhost.5858 localhost.40224 ESTABLISHED
tcp 0 0 localhost.40224 localhost.5858 ESTABLISHED
tcp4 0 0 localhost.5858 localhost.40225 ESTABLISHED
tcp 0 0 localhost.40225 localhost.5858 ESTABLISHED
tcp4 0 0 localhost.5858 localhost.40227 ESTABLISHED
tcp 0 0 localhost.40227 localhost.5858 ESTABLISHED
tcp 0 0 localhost.40228 localhost.5858 TIME_WAIT
tcp 0 0 .5858 *. LISTEN
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.aicc- ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.vnsst ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.3322 ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.3323 ESTABLISHED
tcp4 0 0 aixas12.us.oracl.5858 jed-asqe-42.us.o.3324 ESTABLISHED

here is the count for the above:

bash-3.2# netstat -a | grep 5858 | wc
11 66 854

Now, I expanded Standalone Instances icon (nothing loaded) and clicked on standalone instance name (new page loaded). The count increased to 21:

bash-3.2# netstat -a | grep 5858 | wc
21 126 1644

This does not happen for domain1. Here are sockets open during Admin Console loading for domain1:

bash-3.2# netstat -a | grep 4848
tcp 0 0 .24848 *. LISTEN
bash-3.2#

during loading of Applications page:

bash-3.2# netstat -a | grep 4848
tcp 0 0 .24848 *. LISTEN
tcp4 0 0 localhost.24848 localhost.40549 ESTABLISHED
tcp 0 0 localhost.40549 localhost.24848 ESTABLISHED

once the page is loaded:

bash-3.2# netstat -a | grep 4848
tcp 0 0 .24848 *. LISTEN
bash-3.2#

loading standalone instance page:

bash-3.2# netstat -a | grep 4848
tcp 0 0 .24848 *. LISTEN
tcp 0 0 localhost.40618 localhost.24848 TIME_WAIT

loading done:

bash-3.2# netstat -a | grep 4848
tcp 0 0 .24848 *. LISTEN
bash-3.2#

In the meantime (after some 10 - 15 minutes of idle time for Admin Console on domain2) the following sockets are still in use by domain2:

bash-3.2# netstat -a | grep 5858
tcp 0 0 localhost.40196 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40223 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40224 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40225 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40227 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40263 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40265 localhost.5858 CLOSE_WAIT
tcp 0 0 .5858 *. LISTEN
bash-3.2#

One more note, after restarting domain2, I still could not get Admin Console working properly for domain1 - it was still displaying Too many files exception for every screen I clicked. This issue only went away after I restarted domain1 as well.

Comment by lidiam [ 23/May/11 ]

Anissa, I'm reassigning this issue to you for investigation. Ports are not released after Admin Console is accessed for domain2. Consequently user runs out of file descriptors on the AIX system, if another non default domain is in use.

I tried also CLI, list applications command, but it did not increase socket use like Admin Console:

before making call to asadmin:

bash-3.2# netstat -a | grep 5858 | wc
8 48 620

Executed:
bash-3.2# asadmin --port 5858 list-applications
hello <web>
clusterjsp <ear, web>
Command list-applications executed successfully.

Now netstat shows:
bash-3.2# netstat -a | grep 5858 | wc
9 54 697

and shortly after:
bash-3.2# netstat -a | grep 5858 |wc
8 48 620

So the additional socket got released properly.

Comment by Anissa Lam [ 23/May/11 ]

Thanks Lidia for providing all the data and inform.
Let me seek help from Siraj again. Maybe we need the admin team to take a look too.

Comment by sirajg [ 23/May/11 ]

Are you able to reproduce this by running other web applications?

Comment by lidiam [ 23/May/11 ]

I'm not sure I understand the question. I did not see excessive socket use reported by netstat for any other port number but 5858, domain2 DAS. I have applications (was, ear) deployed to both, instances/clusters on domain1 and domain2. The only port that had hundreds of CLOSE_WAIT connections open was 5858.

I have just reloaded Admin Console for domain2 and went to Standalone Instance page, Applicaions, page: Targets and General page. I checked netstat and socket use is already at 88:

bash-3.2# netstat -a | grep 5858 |wc
88 528 6940

Now I clicked Launch button for hello.war and checked socket use, it went up to 138:

bash-3.2# netstat -a | grep 5858 |wc
138 828 10766

In the meantime I'm checking standalone instance socket use, where hello.war is deployed:

bash-3.2# netstat -a | grep 28083
tcp 0 0 .28083 *. LISTEN

After accessing the hello app on this instance:

bash-3.2# netstat -a | grep 28083
tcp 0 0 .28083 *. LISTEN
tcp4 0 0 aixas12.us.oracl.28083 jed-asqe-42.us.o.sf-lm ESTABLISHED
bash-3.2#

after playing with the app:

bash-3.2# netstat -a | grep 28083
tcp 0 0 .28083 *. LISTEN
tcp4 0 0 aixas12.us.oracl.28083 jed-asqe-42.us.o.sf-lm ESTABLISHED

A couple minutes later:

bash-3.2# netstat -a | grep 28083
tcp 0 0 .28083 *. LISTEN

Thus it looks like Admin Console is doing something special. I'll send you an email with connection information, so you can debug this issue.

Comment by lidiam [ 23/May/11 ]

I tried it also on a solaris system. Here is the use of sockets during Admin Console load time:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
.5858 *. 0 0 49152 0 LISTEN
biffy.5858 jed-asqe-42.us.oracle.com.2051 65078 0 49640 0 ESTABLISHED
localhost.52226 localhost.5858 49152 0 49152 0 ESTABLISHED
localhost.5858 localhost.52226 49152 0 49322 0 ESTABLISHED
biffy.5858 jed-asqe-42.us.oracle.com.2052 65535 113 49640 0 ESTABLISHED

Most of them are released later:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
.5858 *. 0 0 49152 0 LISTEN
localhost.52229 localhost.5858 49152 0 49152 0 CLOSE_WAIT

When clicking around Admin Console of domain2 on solaris, socket use also increases:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
biffy.5858 jed-asqe-42.us.oracle.com.2682 65535 0 49640 0 ESTABLISHED
localhost.52394 localhost.5858 49152 0 49152 0 TIME_WAIT
biffy.5858 jed-asqe-42.us.oracle.com.2684 65535 0 49640 0 ESTABLISHED
biffy.5858 jed-asqe-42.us.oracle.com.2685 65535 0 49640 0 ESTABLISHED
biffy.5858 jed-asqe-42.us.oracle.com.2686 65535 0 49640 0 ESTABLISHED
biffy.5858 jed-asqe-42.us.oracle.com.2687 64508 0 49640 0 ESTABLISHED
biffy.5858 jed-asqe-42.us.oracle.com.2688 65535 0 49640 0 ESTABLISHED
localhost.52395 localhost.5858 49152 0 49152 0 TIME_WAIT
localhost.52398 localhost.5858 49152 0 49152 0 TIME_WAIT
localhost.52399 localhost.5858 49152 0 49152 0 TIME_WAIT
localhost.52400 localhost.5858 49152 0 49152 0 TIME_WAIT
localhost.52401 localhost.5858 49152 0 49152 0 TIME_WAIT
localhost.52403 localhost.5858 49152 0 49152 0 ESTABLISHED
localhost.5858 localhost.52403 49152 0 49152 0 ESTABLISHED
.5858 *. 0 0 49152 0 LISTEN
localhost.52229 localhost.5858 49152 0 49152 0 CLOSE_WAIT

Clicking around domain1 Admin Console also uses many sockets:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 4848
.4848 *. 0 0 49152 0 LISTEN
biffy.4848 jed-asqe-42.us.oracle.com.2674 64898 0 49640 0 TIME_WAIT
localhost.52389 localhost.4848 49152 0 49152 0 TIME_WAIT
biffy.4848 jed-asqe-42.us.oracle.com.2675 64194 0 49640 0 TIME_WAIT
biffy.4848 jed-asqe-42.us.oracle.com.2676 65535 0 49640 0 TIME_WAIT
biffy.4848 jed-asqe-42.us.oracle.com.2677 65535 0 49640 0 TIME_WAIT
biffy.4848 jed-asqe-42.us.oracle.com.2678 64194 0 49640 0 TIME_WAIT
localhost.52390 localhost.4848 49152 0 49152 0 TIME_WAIT
localhost.52391 localhost.24848 49152 0 49152 0 TIME_WAIT
biffy.4848 jed-asqe-42.us.oracle.com.2699 64194 0 49640 0 ESTABLISHED
localhost.52406 localhost.4848 49152 0 49152 0 ESTABLISHED
localhost.4848 localhost.52406 49152 0 49152 0 ESTABLISHED
biffy.4848 jed-asqe-42.us.oracle.com.2700 64194 0 49640 0 ESTABLISHED
biffy.4848 jed-asqe-42.us.oracle.com.2701 65535 0 49640 0 ESTABLISHED
biffy.4848 jed-asqe-42.us.oracle.com.2702 65535 0 49640 0 ESTABLISHED
localhost.52407 localhost.4848 49152 0 49152 0 TIME_WAIT
localhost.52408 localhost.24848 49152 0 49152 0 ESTABLISHED
localhost.24848 localhost.52408 49152 0 49152 0 ESTABLISHED
.24848 *. 0 0 49152 0 LISTEN

However, after a minute or two of inactivity, domain2 sockets are mostly released:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
.5858 *. 0 0 49152 0 LISTEN
localhost.52229 localhost.5858 49152 0 49152 0 CLOSE_WAIT
biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains#

and domain1:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 4848
.4848 *. 0 0 49152 0 LISTEN
.24848 *. 0 0 49152 0 LISTEN
biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains#

Here is the socket use before and after clicking Launch link for hello.war application on the solaris system:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858 |wc
47 329 3747
biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858 |wc
110 770 8777

A couple minutes later the use goes down to 33:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858 |wc
33 231 2573

and most of them are in TIME_WAIT state:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
localhost.52491 localhost.5858 49152 0 49152 0 CLOSE_WAIT
localhost.5858 localhost.52491 49152 0 49152 0 FIN_WAIT_2
localhost.5858 localhost.52560 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52561 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52562 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52563 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52564 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52565 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52566 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52567 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52568 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52569 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52570 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52571 49152 0 49152 0 TIME_WAIT
localhost.5858 localhost.52572 49152 0 49152 0 TIME_WAIT
...
.5858 *. 0 0 49152 0 LISTEN

A couple more minutes of inactivity on solaris frees most of the sockets:

biffy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains# netstat -a | grep 5858
localhost.52491 localhost.5858 49152 0 49152 0 CLOSE_WAIT
localhost.5858 localhost.52491 49152 0 49152 0 FIN_WAIT_2
.5858 *. 0 0 49152 0 LISTEN

while on AIX, that has been idle for an hour now, there are still 103 sockets in use, most of them in CLOSE_WAIT state:

bash-3.2# netstat -a | grep 5858 |wc
103 618 8030

bash-3.2# netstat -a | grep 5858
tcp 0 0 localhost.40196 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40223 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40224 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40225 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40227 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.40263 localhost.5858 CLOSE_WAIT
...
tcp 0 0 localhost.40967 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.41162 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.41165 localhost.5858 CLOSE_WAIT
tcp 0 0 localhost.41166 localhost.5858 CLOSE_WAIT
tcp 0 0 .5858 *. LISTEN
tcp 0 0 localhost.41224 localhost.5858 CLOSE_WAIT

Comment by lidiam [ 23/May/11 ]

I have just gotten the "Too many files" exception in Admin Console, accessing domain1 only (domain2 was still running but I was not accessing it through Admin Console). I was basically going through many different screens of Admin Console and at the end of my testing got this exception:

HTTP Status 500 -
type Exception report
message
descriptionThe server encountered an internal error () that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event138'.
root cause
java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'beforeEncode' event for 'event138'.
root cause
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeEncode' event for 'event138'.
root cause
java.lang.reflect.InvocationTargetException
root cause
com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Too many open files
root cause
java.net.SocketException: Too many open files

This time majority of the CLOSE_WAIT sockets are:

tcp 0 0 localhost.40551 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40552 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40553 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40554 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40555 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40556 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40557 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40558 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40559 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40560 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40561 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40562 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40563 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40564 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40565 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40566 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.40567 localhost.appserv- CLOSE_WAIT

I have never seen this problem when Glassfish was running on a different OS. I'll attach netstat.all.domain1-actions file with the full netstat output.

Comment by sirajg [ 24/May/11 ]

The connection for admin port is probably not getting closed probably. Seeking input from web container team.

Comment by lidiam [ 24/May/11 ]

I have tried this with a brand new domain1 (removed previous Glassfish and unzipped the distribution again). After starting domain1 and accessing Admin Console without creating server instances of any sort, I still saw the issue of sockets not released and remaining in CLOSE_WAIT state. There are no exceptions in server.log (I'll attach it as domain1.server.log).

Below are some details of my testing. I would like to note that netstat was often very slow. I had to wait a minute or so for the output, so it was slowing down the testing.

1. After loading of Admin Console:

bash-3.2# netstat -a | wc
112 588 7739

bash-3.2# netstat -a | grep appserv
tcp4 0 0 localhost.appserv- localhost.63000 FIN_WAIT_2
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63001 FIN_WAIT_2
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp 0 0 .appserv- *. LISTEN

2. click on server (Admin Server)

bash-3.2# netstat -a | wc
131 702 9216

bash-3.2# netstat -a | grep appserv
tcp4 0 0 localhost.appserv- localhost.63000 FIN_WAIT_2
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63001 FIN_WAIT_2
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63248 ESTABLISHED
tcp 0 0 localhost.63248 localhost.appserv- ESTABLISHED
tcp4 0 0 localhost.appserv- localhost.63249 ESTABLISHED
tcp 0 0 localhost.63249 localhost.appserv- ESTABLISHED
tcp4 0 0 localhost.appserv- localhost.63250 ESTABLISHED
tcp 0 0 localhost.63250 localhost.appserv- ESTABLISHED
tcp 0 0 .appserv- *. LISTEN

3. Click on Standalone Instances (wait), click on Clusters (wait), click on New button on Clusters screen:

bash-3.2# netstat -a | wc
146 779 10256

bash-3.2# netstat -a | grep appserv
tcp4 0 0 localhost.appserv- localhost.63000 FIN_WAIT_2
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63001 FIN_WAIT_2
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63248 FIN_WAIT_2
tcp 0 0 localhost.63248 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63249 FIN_WAIT_2
tcp 0 0 localhost.63249 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63410 FIN_WAIT_2
tcp 0 0 localhost.63410 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63411 FIN_WAIT_2
tcp 0 0 localhost.63411 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63412 FIN_WAIT_2
tcp 0 0 localhost.63412 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63467 FIN_WAIT_2
tcp 0 0 localhost.63467 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63468 FIN_WAIT_2
tcp 0 0 localhost.63468 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63469 FIN_WAIT_2
tcp 0 0 localhost.63469 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63544 ESTABLISHED
tcp 0 0 localhost.63544 localhost.appserv- ESTABLISHED
tcp4 0 0 localhost.appserv- localhost.63545 ESTABLISHED
tcp 0 0 localhost.63545 localhost.appserv- ESTABLISHED
tcp 0 0 .appserv- *. LISTEN

4. Click on Applications (wait), click on Lifecycle Modules:

bash-3.2# netstat -a | wc
151 809 10643

bash-3.2# netstat -a | grep appserv
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63248 FIN_WAIT_2
tcp 0 0 localhost.63248 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63249 FIN_WAIT_2
tcp 0 0 localhost.63249 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63410 FIN_WAIT_2
tcp 0 0 localhost.63410 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63411 FIN_WAIT_2
tcp 0 0 localhost.63411 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63412 FIN_WAIT_2
tcp 0 0 localhost.63412 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63467 FIN_WAIT_2
tcp 0 0 localhost.63467 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63468 FIN_WAIT_2
tcp 0 0 localhost.63468 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63469 FIN_WAIT_2
tcp 0 0 localhost.63469 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63544 FIN_WAIT_2
tcp 0 0 localhost.63544 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63545 FIN_WAIT_2
tcp 0 0 localhost.63545 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63587 FIN_WAIT_2
tcp 0 0 localhost.63587 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63588 FIN_WAIT_2
tcp 0 0 localhost.63588 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.63671 ESTABLISHED
tcp 0 0 localhost.63671 localhost.appserv- ESTABLISHED
tcp4 0 0 localhost.appserv- localhost.63672 ESTABLISHED
tcp 0 0 localhost.63672 localhost.appserv- ESTABLISHED
tcp 0 0 localhost.63673 localhost.appserv- TIME_WAIT
tcp 0 0 .appserv- *. LISTEN

You can see in the above output, that we have two CLOSE_WAIT sockets (at the top of the listing) that are not released. These only grew during further testing. I'll skip more details, that seem irrelevant (I deployed and accessed application, looked at Logger Settings screen, created an Instance Property for Admin Server etc. but still did not create any instances nor resources). At the end I had the following:

bash-3.2# netstat -a | wc
251 1409 18444

bash-3.2# netstat -a | grep appserv |wc
127 762 9901

bash-3.2# netstat -a | grep appserv
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63248 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63249 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63410 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63411 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63412 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63467 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63468 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63469 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63544 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63545 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63587 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63588 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63671 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63672 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64033 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64034 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64276 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64277 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64278 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64279 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64280 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64334 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64339 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64341 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64342 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64343 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64344 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64345 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64346 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64347 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64440 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64441 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64442 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64443 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64444 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64445 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64446 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64447 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64448 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64449 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64450 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64451 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64494 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64495 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64496 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64497 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64498 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64499 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64500 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64501 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64502 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64503 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64504 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64505 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64506 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64507 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64508 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64651 FIN_WAIT_2
tcp 0 0 localhost.64651 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64652 FIN_WAIT_2
tcp 0 0 localhost.64652 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64653 FIN_WAIT_2
tcp 0 0 localhost.64653 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64654 FIN_WAIT_2
tcp 0 0 localhost.64654 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64655 FIN_WAIT_2
tcp 0 0 localhost.64655 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64656 FIN_WAIT_2
tcp 0 0 localhost.64656 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64657 FIN_WAIT_2
tcp 0 0 localhost.64657 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64658 FIN_WAIT_2
tcp 0 0 localhost.64658 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64659 FIN_WAIT_2
tcp 0 0 localhost.64659 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64660 FIN_WAIT_2
tcp 0 0 localhost.64660 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64661 FIN_WAIT_2
tcp 0 0 localhost.64661 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64662 FIN_WAIT_2
tcp 0 0 localhost.64662 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64663 FIN_WAIT_2
tcp 0 0 localhost.64663 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64664 FIN_WAIT_2
tcp 0 0 localhost.64664 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64665 FIN_WAIT_2
tcp 0 0 localhost.64665 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64666 FIN_WAIT_2
tcp 0 0 localhost.64666 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64667 FIN_WAIT_2
tcp 0 0 localhost.64667 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64668 FIN_WAIT_2
tcp 0 0 localhost.64668 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64669 FIN_WAIT_2
tcp 0 0 localhost.64669 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64670 FIN_WAIT_2
tcp 0 0 localhost.64670 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64671 FIN_WAIT_2
tcp 0 0 localhost.64671 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64672 FIN_WAIT_2
tcp 0 0 localhost.64672 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64673 FIN_WAIT_2
tcp 0 0 localhost.64673 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64732 FIN_WAIT_2
tcp 0 0 localhost.64732 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64733 FIN_WAIT_2
tcp 0 0 localhost.64733 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64734 FIN_WAIT_2
tcp 0 0 localhost.64734 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64735 FIN_WAIT_2
tcp 0 0 localhost.64735 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64736 FIN_WAIT_2
tcp 0 0 localhost.64736 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64785 FIN_WAIT_2
tcp 0 0 localhost.64785 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64786 FIN_WAIT_2
tcp 0 0 localhost.64786 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64787 FIN_WAIT_2
tcp 0 0 localhost.64787 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64837 FIN_WAIT_2
tcp 0 0 localhost.64837 localhost.appserv- CLOSE_WAIT
tcp4 0 0 localhost.appserv- localhost.64838 FIN_WAIT_2
tcp 0 0 localhost.64838 localhost.appserv- CLOSE_WAIT
tcp 0 0 .appserv- *. LISTEN

There are 59 sockets in CLOSE_WAIT state. I checked again after typing this comment and see the following:

bash-3.2# netstat -a | grep appserv
tcp 0 0 localhost.63000 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63001 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63248 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63249 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63410 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63411 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63412 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63467 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63468 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63469 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63544 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63545 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63587 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63588 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63671 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.63672 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64033 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64034 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64276 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64277 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64278 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64279 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64280 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64334 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64339 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64341 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64342 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64343 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64344 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64345 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64346 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64347 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64440 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64441 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64442 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64443 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64444 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64445 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64446 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64447 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64448 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64449 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64450 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64451 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64494 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64495 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64496 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64497 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64498 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64499 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64500 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64501 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64502 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64503 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64504 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64505 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64506 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64507 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64508 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64651 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64652 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64653 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64654 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64655 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64656 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64657 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64658 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64659 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64660 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64661 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64662 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64663 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64664 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64665 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64666 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64667 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64668 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64669 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64670 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64671 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64672 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64673 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64732 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64733 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64734 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64735 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64736 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64785 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64786 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64787 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64837 localhost.appserv- CLOSE_WAIT
tcp 0 0 localhost.64838 localhost.appserv- CLOSE_WAIT
tcp 0 0 .appserv- *. LISTEN

That's:

bash-3.2# netstat -a | grep appserv |wc
93 558 7250

93 sockets that are not released.

Comment by lidiam [ 24/May/11 ]

One more observation: just clicking on the same 2 pages in round robin fashion, increases number of used sockets quite a bit. I was clicking on Standalone Instances and Clusters, and within a minute got from 93 to 182 open sockets for appserver:

bash-3.2# netstat -a | grep appserv |wc
189 1134 14738

After about 10 minutes and the output changed to:

bash-3.2# netstat -a | grep appserv |wc
141 846 10994

which is bad news, because we started with 93. This means that just going through the same pages over and over will also cause the "Too many files" exception, given enough time, since sockets are allocated every time a page is visited (even for consecutive visits) and not properly released. I have just checked that all 140 sockets are now in CLOSE_WAIT state:

bash-3.2# netstat -a | grep appserv | grep CLOSE_WAIT | wc
140 840 10920

Comment by lidiam [ 24/May/11 ]

I also tested clusterjsp.ear application. Accessed it many times, restarted session, etc. While socket use went up, after a while it was going down to previous level again.

Also, restarting browser did not cause the connections to disappear. In the end I have the following number of appserv connections:

bash-3.2# netstat -a | grep appserv | wc
189 1134 14738

5 of which are in FIN_WAIT_2 state.

Comment by kumara [ 24/May/11 ]

Best guess - this is related to use of REST API to render admin console pages. How does admin console connect to REST API? Do we have a pool of HttpURLConnection or do we create a new HttpURLConnection per operation?

If Jersey client API is being used, HttpURLConnection will map to com.sun.jersey.api.client.Client. It will be advisable to use a pool of Client objects to keep the number of client connections in check (and will also perform better because same HTTP connection will be reused)

If it is possible to avoid network traffic altogether by using some internal APIs from Jersey, that will be even better, no pool to maintain and no internal network connection for operations in admin console.

Comment by Shing Wai Chan [ 25/May/11 ]

I have deployed a simple war file and accessing the web page. I do not see the CLOSE_WAIT issue there.

Per discussion with Anissa, clicking the "Cluster" page invokes the following rest api:
http://<aixhost>:50370/management/domain/clusters/cluster

and clicking "Standalone instance" page invokes the following rest api:
http://<aixhost>:50370/management/domain/list-instances
http://<aixhost>:50370/management/domain/servers

I have invoked the above rest API individually. I do not see the CLOSE_WAIT issue above.

But if I access the "Cluster" page and then "Standalone instance" page, after a while, I see the following result from "netstat -a | grep 50370" where 50370 is the admin port:

tcp 0 0 .50370 *. LISTEN
tcp4 0 0 localhost.50370 localhost.62629 FIN_WAIT_2
tcp 0 0 localhost.62629 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62902 FIN_WAIT_2
tcp 0 0 localhost.62902 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62903 FIN_WAIT_2
tcp 0 0 localhost.62903 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62904 FIN_WAIT_2
tcp 0 0 localhost.62904 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62905 FIN_WAIT_2
tcp 0 0 localhost.62905 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62906 FIN_WAIT_2
tcp 0 0 localhost.62906 localhost.50370 CLOSE_WAIT
tcp4 0 0 localhost.50370 localhost.62907 FIN_WAIT_2
tcp 0 0 localhost.62907 localhost.50370 CLOSE_WAIT

If I let the server running over night, then I see the following:
tcp 0 0 .50370 *. LISTEN
tcp 0 0 localhost.62629 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62902 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62903 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62904 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62905 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62906 localhost.50370 CLOSE_WAIT
tcp 0 0 localhost.62907 localhost.50370 CLOSE_WAIT

So, it seems that there is an issue that is specific to admin console access.

Comment by Shing Wai Chan [ 26/May/11 ]

Note that the above direct accesses of rest API only indicate that the server side is ok. One may still need to check whether the client API has no issue.

Comment by sirajg [ 26/May/11 ]

A modification in the way console interacts with jersey seems to have fixed the issue, but it needs to be tested.

Comment by sirajg [ 31/May/11 ]

Filed issue JERSEY-725, the fix in console did not work.

Comment by scatari [ 07/Jun/11 ]

Pre-approving for 3.1.1 as this is a test blocker.

Comment by sirajg [ 10/Jun/11 ]

Tried a basic test that opens a HttpURLConnection many times on AIX - couldn't reproduce the problem. Tried a simple jsf application and opened HttpURLConnection while accessing that application many times, but could not reproduce the problem with the test cases.

Comment by Dhiru Pandey [ 16/Jun/11 ]

What is the value of TCP_TIMEWAIT on the AIX system ? See link below:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tprf_tuneaix.html

Another thing to check how differently is the Admin Adaptor configured as compared to the REST Adaptor. As I understand both of them use Grizzly Adaptor and since one shows a different behavior than the other its possible that their configuration/initialization may have something to do with this

Comment by sirajg [ 23/Jun/11 ]

Transfering to Alexey since he is looking into the issue

Comment by sirajg [ 28/Jun/11 ]

After specifying linger="0", in domain.xml the problem cannot be reproduced :

<transports>
<transport linger="0" name="tcp"></transport>
</transports>

The setting could be made specific to the admin-listener by modifying the transport setting for that particular listener.

Comment by scatari [ 28/Jun/11 ]

I have added a new template file for AIX(domain-aix.xml) under packager/nucleus-base/lib/templates. Please update this file to add any AIX specific VM arguments or domain config elements. This file will be automatically picked up during AIX packaging/bundle generation process and will be ignored during non-AIX builds.

Comment by lidiam [ 28/Jun/11 ]

The following workaround worked on build b09:

changed:
<network-listener port="4848" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>

to:
<network-listener port="4848" protocol="admin-listener" transport="tcp
-admin-listener" name="admin-listener" thread-pool="admin-thread-pool"></network
-listener>

and added:

<transport linger="0" name="tcp-admin-listener"></transport>

After restarting the domain, accessed Admin Console and verified via "netstat -a | grep appserv" that all sockets were released.

Comment by oleksiys [ 30/Jun/11 ]

looks like the issue is in admingui, which doesn't close RestResponse properly.
Attaching the diff., which has to fix admingui.

Comment by oleksiys [ 30/Jun/11 ]

fix for the admingui module

Comment by oleksiys [ 30/Jun/11 ]

BTW, this issue in not just AIX related.

Comment by sirajg [ 30/Jun/11 ]

Checked in the patch provided by Oleksiy.

Comment by scatari [ 02/Jul/11 ]

Reopening to update fix in version to the correct build#.

Comment by lidiam [ 05/Jul/11 ]

Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip.

Comment by bthalmayr [ 07/Nov/11 ]

Can you please reopen this bug again?

I'm still seeing it in 'GlassFish Server Open Source Edition 3.1.1 (build 12)' on RHEL 6.

It's also seen when clicking on 'resource configurations' etc.

No click within console for some time

  1. netstat -a | grep -c appserv
    1

Click within console on 'resources -> connectors -> connector-resources -> resources'

  1. netstat -a | grep -c appserv
    172

Exception from Log..

[#|2011-11-07T12:09:14.291+0100|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=11609;_ThreadName=Thread-2;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'beforeCreate' event for 'propertyContentPage'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:590)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:247)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:232)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'propertyContentPage'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:464)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Zu viele offene Dateien
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:149)
at com.sun.jersey.api.client.Client.handle(Client.java:648)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:503)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:711)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:190)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:216)
... 51 more
Caused by: java.net.SocketException: Zu viele offene Dateien
at java.net.Socket.createImpl(Socket.java:447)
at java.net.Socket.connect(Socket.java:577)
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:607)
at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:160)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:388)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:483)
at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:278)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:335)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:928)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1296)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:240)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:147)
... 58 more

#]
Comment by bthalmayr [ 07/Nov/11 ]

I tried to apply the mentioned workaround but I still get the same error

Listener configuration (obtained via 'asadmin')

server-config.network-config.network-listeners.network-listener.admin-listener.transport=tcp-admin-listener
server-config.network-config.transports.transport.tcp-admin-listener.linger=0

Comment by oleksiys [ 07/Nov/11 ]

reopen to let webgui team check the latest report

Comment by Anissa Lam [ 08/Nov/11 ]

Lidia says:
"Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip."

and bthalmayr reopened the bug as:
"I'm still seeing it in 'GlassFish Server Open Source Edition 3.1.1 (build 12)' on RHEL 6."

I don't think we make changes between b11 and b12.
bthalmayr, can you run with the version that Lidia has verified and see what you get ? Just want to iron out if there is any configuration issue.
thanks.

Comment by Anissa Lam [ 18/Nov/11 ]

Add tag and Fix version to indicate we want to address this for 3.1.2

Comment by bthalmayr [ 25/Nov/11 ]

I'm using GF 3.1.1 build 12 and the issue is still seen, making the console almost unusable.

Setting 'linger' to '0' does not help at all.

OS: RHEL 6

Comment by sirajg [ 04/Jan/12 ]

Opened issue GLASSFISH-18117 for RHEL. Closing this issue, as the original issue reported in this bug was fixed.





[GLASSFISH-16671] [Blocking] LB plugin doesn't work on AIX 6.1 Created: 17/May/11  Updated: 18/May/11  Resolved: 18/May/11

Status: Closed
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1.1_b05
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mzh777 Assignee: kshitiz_saxena
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

AIX 6.1, JDK 1.6.0


Attachments: PNG File Bug01.png    
Tags: 3_1_1-approved

 Description   

Missing installation screens for input WebServer choice and plugin location.

Please see the attached screen shot for error message.

bash-3.2# java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr9fp1-20110208_03(SR9 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 jvmap3260sr9-20110203_74623 (JIT enabled, AOT enabled)

bash-3.2# uname -a
AIX aixas10 1 6 0001BBEAD200



 Comments   
Comment by kshitiz_saxena [ 18/May/11 ]

You need to use build for 3.1.1 for getting load-balancer plugin for AIX. AIX support was not available in 3.1.

I will send a separate email having link to latest load-balancer plugin.





[GLASSFISH-16847] Regression with JSF in latest builds Created: 13/Jun/11  Updated: 02/Dec/11  Resolved: 27/Jun/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 3.1.1_b09

Type: Bug Priority: Blocker
Reporter: Bhavanishankar Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 8 hours
Time Spent: Not Specified
Original Estimate: 8 hours
Environment:

any


Attachments: Text File changebundle.txt     Zip Archive jsftest.src.zip     File jsftest.war    
Tags: 3_1_1-approved

 Description   

I have a JSF application which has a managed bean like this:

@javax.faces.bean.ManagedBean(name = "testbean")
public class JSFTestBean {

    public TestTable[] getTestTable() {
        return testTable;
    }

    private TestTable[] testTable = new TestTable[]{
            new TestTable("BHAVANI", "+91999000000", "INDIA"),
            new TestTable("SHANKAR", "+199999999999", "USA"),
            new TestTable("Mr. X", "+122222222", "SFO"),
    };

    public class TestTable {
        // contains name, phone number, country
        // and the required getters/setters following JavaBean standards.
    }

}

My index.xhtml creates a table and populates its entries from the above managed bean, like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">
<h:head>
    <title>JSF Test</title>
</h:head>
<h:body>
    <f:view>
        <h:form>
            <h:dataTable value="#{testbean.testTable}" var="tableEntry">
                
                <f:facet name="header">
                    <h:outputText value="JSF Table"/>
                </f:facet>

                <h:column>
                    <f:facet name="header">
                        <h:outputText value="name"/>
                    </f:facet>
                    <h:outputText value="#{tableEntry.name}"></h:outputText>
                </h:column>

                <h:column>
                    <f:facet name="header">
                        <h:outputText value="number"/>
                    </f:facet>
                    <h:outputText value="#{tableEntry.number}"></h:outputText>
                </h:column>

                <h:column>
                    <f:facet name="header">
                        <h:outputText value="country"/>
                    </f:facet>
                    <h:outputText value="#{tableEntry.country}"></h:outputText>
                </h:column>

            </h:dataTable>
        </h:form>
    </f:view>
</h:body>
</html>

When I deploy this application and access index.xhtml, I expect the following output:

JSF Table
name number country
BHAVANI +91999000000 INDIA
SHANKAR +199999999999 USA
Mr. X +122222222 SFO

It works to my expectation with 3.1.1-b07 build (and also in the previous builds of both 3.1.1 and 3.2)

But when I run it with the latest 3.1.1 nightly build (or with 3.2 nightly build), I get only the following output:

JSF Table
name number country

The table data goes missing!

It seems to be regression in the latest 3.1.1 and 3.2 nightly builds.

To reproduce:

Install latest GF, deploy the attached jsftest.war and access http://localhost:8080/hellojsf/

The source of this application is attached as jsftest.src.zip (unzip it and

 mvn clean compile war:war 

to rebuild the .war file.

IMO, it is regression due to the latest JSF integration with GlassFish.



 Comments   
Comment by rogerk [ 13/Jun/11 ]

I've verified the regression.

Comment by rogerk [ 14/Jun/11 ]

It appears that the managed bean is not beging loaded by the JSF config system when the app is deployed.

Comment by Ed Burns [ 15/Jun/11 ]

Can you please try this with GlassFish 3.1?

I think the problem is a regression on the GlassFish side.

If you want to check out and build GlassFish 3.1 from source, the SVN tag is:

https://svn.java.net/svn/glassfish~svn/tags/3.1-b43

Ed

Comment by Bhavanishankar [ 15/Jun/11 ]

This works fine in GlassFish 3.1. In fact it was all working fine till b07 of 3.1.1

Comment by rogerk [ 15/Jun/11 ]

I'm noticing that when I remove the sun-web.xml file from the war, the app works fine.

Comment by rogerk [ 15/Jun/11 ]

I'm noticing that when I remove the sun-web.xml file from the war, the app works fine.

Comment by Bhavanishankar [ 15/Jun/11 ]

Hi Roger, can you please revert back the JSF integration pom.xml change until you the root cause is figured out.

Comment by scatari [ 20/Jun/11 ]

Approved as this is blocking Embedded API support in web profile.

Comment by Ed Burns [ 20/Jun/11 ]

Yes, please back it for now. I understand the cause and am working on a resolution to this regression.

I apologize for the inconvenience.

Ed

Comment by Ed Burns [ 20/Jun/11 ]

The system does not cope with the case where the contents of the <context-root /> element are not the same as the deployed path.

I will fix this.

Comment by Ed Burns [ 21/Jun/11 ]

I request that Shing Wai Chan review this before I commit it to Mojarra for eventual inclusion into GlassFish 3.1.1.

Comment by Ed Burns [ 22/Jun/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/config/DelegateToGlassFishAnnotationScanner.java
Adding jsf-test/GLASSFISH-16847
Adding jsf-test/GLASSFISH-16847/build.xml
Adding jsf-test/GLASSFISH-16847/jsftest
Adding jsf-test/GLASSFISH-16847/jsftest/pom.xml
Adding jsf-test/GLASSFISH-16847/jsftest/src
Adding jsf-test/GLASSFISH-16847/jsftest/src/main
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish/tests
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish/tests/embedded
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish/tests/embedded/jsftest
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish/tests/embedded/jsftest/JSFTestBean.java
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/org/glassfish/tests/embedded/jsftest/JSFTestServlet.java
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/java/test
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/webapp
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/webapp/WEB-INF
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/webapp/WEB-INF/sun-web.xml
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/GLASSFISH-16847/jsftest/src/main/webapp/index.xhtml
Adding jsf-test/GLASSFISH-16847/jsftest/src/test
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org/glassfish
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org/glassfish/tests
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org/glassfish/tests/embedded
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org/glassfish/tests/embedded/jsftest
Adding jsf-test/GLASSFISH-16847/jsftest/src/test/java/org/glassfish/tests/embedded/jsftest/JSFTest.java
Sending jsf-test/build.xml
Transmitting file data ..........
Committed revision 9176.

Comment by Ed Burns [ 22/Jun/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/config/DelegateToGlassFishAnnotationScanner.java
Transmitting file data .
Committed revision 9177.

Comment by Ed Burns [ 22/Jun/11 ]

Revision 9178 committed to 2.1 branch.

Comment by Bhavanishankar [ 23/Jun/11 ]

Please fix this issue on trunk also.

Comment by Ed Burns [ 24/Jun/11 ]

Fixed on Mojarra trunk and 2.1 branch.
Integrated into Glassfish as Mojarra 2.1.3-b01

Comment by Ed Burns [ 24/Jun/11 ]

Need to also integrate 2.1.3-b01 into trunk

Comment by scatari [ 25/Jun/11 ]

3.1.1 Fix was integrated into b09.

Comment by Bhavanishankar [ 27/Jun/11 ]

Kindly fix in 3.2 trunk as well.

Comment by rogerk [ 27/Jun/11 ]

This was checked into GF trunk this morning.





[GLASSFISH-16502] asadmin commands to manage IMS configuration Created: 29/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: glassfish
Component/s: iaas
Affects Version/s: 4.0
Fix Version/s: 4.0_b43

Type: New Feature Priority: Blocker
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7_cleanup_closed

 Description   

Implement asadmin commands to configure and otherwise manage IMS. For example (these as just examples):

create-virt: Configure IMS with a virtualization provider.
delete-virt
list-virts
update-virt?

create-server-pool: Create a virtualization server pool.
delete-server-pool
list-server-pools
update-server-pool?

create-machine: Add virtualization servers to a server pool.
delete-machine
list-machines

add-virt-template: Add a virtualization template to a server pool
delete-virt-template
list-virt-templates



 Comments   
Comment by shreedhar_ganapathy [ 27/Oct/11 ]

Changed AffectsVersion to 4.0

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to reassign dochez issue to component lead.

Comment by Tom Mueller [ 01/Oct/12 ]

Since cloud support has been removed from Java EE 7, this issue has been closed. This issue can be reopened if desired for future Java EE work.





[GLASSFISH-16499] Virtual Server not working Created: 29/Apr/11  Updated: 03/May/11  Resolved: 03/May/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

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

Windows 7 pro & Windows 2008. Both 64-bit.


Tags: server, virtual

 Description   

We're trying to deploy a few EAR projects on GF3.1 and need to use virtual servers. Our setup works in GF3.0, which we're forced to use instead. It's rather troublesome though, as NetBeans 7 is bundled with GF3.1 and we need to install 3.0 to use it. Furthermore, when we use GF3.0, we must replace the JSF version every time we install it, due to a bug with PhaseListeners and virtual machines in GF3.0.

Here's what we do:

1) Install our project, tracker-ear.ear.
2) Create a new virtual server called tracker.
3) Set the default web module on our virtual server to tracker-ear#tracker-web.war.
4) Test if it's working. It's not. HTTP-error 500.
5) Restart GF.
6) Test if it's working. It's not. HTTP-error 500.
7) Look in the log file. It contains the following exception.

[#|2011-04-29T09:39:27.193+0200|SEVERE|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=83;_ThreadName=Thread-1;|WEB0149: Unable to set default-web-module [/tracker-web] for virtual server [tracker]
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.loadDefaultWebModulesAfterAllAppsProcessed(WebContainer.java:1451)
at com.sun.enterprise.web.WebContainer.event(WebContainer.java:599)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 9 more

#]


 Comments   
Comment by Shing Wai Chan [ 29/Apr/11 ]

According to the above log message, the corresponding web app is not deployed to the virtual server 'tracker'.
One has to associate the application to the virtual server 'tracker' before setting the default-web-module of the virtual server.
This can be achieved through Admin Console: Applications > tracker-ear > Virtual Servers

Note that one has to set the http-listeners in a given virtual servers.
Now, you can set the default web module of the given virtual server.
If we do this, then there is no need to restart the server.

I have verified that it is working fine.

Comment by bjornstenfeldt [ 02/May/11 ]

Ok, it seems to be working now, but not quite as easy as you describe it. Here is what we did:

1) Deploy tracker-ear.ear.
2) Create a new virtual server called tracker on http-listener-1. (No default-web-module)
3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
4) Edit domain.xml and force tracker-ear to use tracker virtual server.
5) Restart GF.
6) Enable tracker-ear. It will throw an exception, but is still enabled. See the exception below.
7) Select a default-web-module for tracker virtual server.
8) Test it. It works.

[#|2011-05-02T09:23:41.377+0200|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=40;_ThreadName=Thread-1;|Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/tracker-web'|#]

[#|2011-05-02T09:23:42.424+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=130;_ThreadName=Thread-1;|WEB0671: Loading application tracker-ear#tracker-web.war at [tracker-web]|#]

[#|2011-05-02T09:23:42.429+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=185;_ThreadName=Thread-1;|CORE10010: Loading application tracker-ear done in 0 ms|#]

[#|2011-05-02T09:23:42.535+0200|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=40;_ThreadName=Thread-1;|Exception in prepareAlert():null|#]

[#|2011-05-02T09:23:42.540+0200|WARNING|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=40;_ThreadName=Thread-1;|java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]

[#|2011-05-02T09:23:42.547+0200|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]
Comment by Anissa Lam [ 02/May/11 ]

Looking at Step #3 and Step #4

>> 3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
>> 4) Edit domain.xml and force tracker-ear to use tracker virtual server.

You are hitting GLASSFISH-16048.
You need to use CLI to set the virtual server, and if you do a SAVE on that screen, ensure that the enabled checkbox is checked.

Comment by Shing Wai Chan [ 02/May/11 ]

Can you try 3.1.1 promoted build to see whether the jsftemplating exception is resolved?

Comment by Shing Wai Chan [ 02/May/11 ]

One more remark, both virtual servers `tracker' and `server' has http-listener-1. We should not do this.

Comment by bjornstenfeldt [ 03/May/11 ]

Thanks, I'll see if we can find time to do a 3.1.1 deployment, but we really need to get moving with our projects. I think this work-around can get us by until next GF is release.

Comment by Shing Wai Chan [ 03/May/11 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-16048





[GLASSFISH-16494] Enhancement for logging in a PaaS environment Created: 28/Apr/11  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed