Patching Glassfish 2.1.x with the latest Grizzly 1.0.x releases

From time to time Grizzly team works on issues, found by Glassfish 2.1.x users. Very often it happens, that issue has/might already been fixed in latest Grizzly 1.0.x release, and to not force user to perform complete Glassfish upgrade, we ask to try latest Grizzly 1.0.x and check if it fixes the problem.

Here I'd like to describe how user can patch existing Glassfish 2.1.x with latest Grizzly 1.0.x.

1) Check the Grizzly version, which is currently integrated to Glassfish.

To check the current Grizzly version, we need to set system property "com.sun.enterprise.web.connector.grizzly.displayConfiguration" to true. We can do it by editing Glassfish instance's domain.xml file (usually located under GF/domains/domain1/config/domain.xml) , specifically we need to find XML element <java-config> and add there child element [1].

After restarting Glassfish instance in server.log (usually located under GF/domains/domain1/logs/server.log)  we'd see output like [2], where Grizzly version is 1.0.30. Please note, that if you'll see output similar to [2], but without Grizzly version in it - it means, that your version is older than 1.0.30, so you might be interested in Grizzly upgrade :)

2) Find and download Grizzly 1.0.x binary file.

You can receive link to the required Grizzly binaries directly from Grizzly team, or find the latest Grizzly binaries in the maven repository [3].

3) Apply the latest Grizzly 1.0.x binary.

Assume we've downloaded Grizzly 1.0.x binary and saved it at "/home/my/grizzly-framework-http-1.0.30.jar". Now we need to set this jar file on Glassfish prefix-classpath, to force Glassfish use the latest Grizzly classes instead of embedded ones. Again we have to edit Glassfish instance's domain.xml file (usually located under GF/domains/domain1/config/domain.xml), find XML element <java-config> and edit/add its XML attribute classpath-prefix to make it point to the saved latest Grizzly binary. So it will like [4].

4) Restart Glassfish

Probably it will also make sense to repeat step 1, to make sure we run the latest Grizzly version.

That's it :) 

[1] <jvm-options>-Dcom.sun.enterprise.web.connector.grizzly.displayConfiguration=true</jvm-options> 

[2] 
Grizzly 1.0.30 running on Mac OS X-10.5.8 under JDK version: 1.6.0_15-Apple Inc.
port: 8080
maxThreads: 5
ByteBuffer size: 4096
useDirectByteBuffer: 8192
maxKeepAliveRequests: 250
keepAliveTimeoutInSeconds: 30
Static File Cache enabled: false
Pipeline : com.sun.enterprise.web.portunif.PortUnificationPipeline
Round Robin Selector Algorithm enabled: false
Round Robin Selector pool size: 1
Asynchronous Request Processing enabled: true|#]

[3] http://download.java.net/maven/2/com/sun/grizzly/grizzly-framework-http/

[4] <java-config classpath-prefix="/home/my/grizzly-framework-http-1.0.30.jar" classpath-suffix="" debug-enabled="true" debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" env-classpath-ignored="true" java-home="${com.sun.aas.javaRoot}" javac-options="-g" rmic-options="-iiop -poa -alwaysgenerate -keepgenerated -g" system-classpath=""> 

Comments:

Hello,

Thanks a lot for your very clear message.

I struggle a spurious bug in glassfish, where https client connections hangs under high load (this does not seem to occurs with https server connections) : after some time, GF server does not respond to connections on the https port -- no exception, no error, no warnings.

As I suspect a "deep" bug in Grizzly (race condition or kind of), I have tried to update to grizzly 1.0.30, according to your post.

Unfortunately, GF does not start anymore, as tomcat's methods signatures seem to have changed :
Here is my log :
<<
Grizzly 1.0.30 running on Linux-2.6.26-2-686 under JDK version: 1.6.0_06-Sun Microsystems Inc.
port: 8443
maxThreads: 32
ByteBuffer size: 4096
useDirectByteBuffer: 8192
maxKeepAliveRequests: 250
keepAliveTimeoutInSeconds: 30
Static File Cache enabled: true
Pipeline : com.sun.enterprise.web.connector.grizzly.ssl.SSLPipeline
Round Robin Selector Algorithm enabled: false
Round Robin Selector pool size: 1
Asynchronous Request Processing enabled: false|#]

[#|2009-11-26T09:59:08.382+0100|WARNING|sun-appserver9.1|org.apache.coyote.tomcat5.MapperListener|_ThreadID=18;_ThreadName=pool-1-thread-7;_RequestID=df156756-41dc-4813-91c0-f50792319df6;|Error registering Context com.sun.appserv:j2eeType=WebModule,name=//server/logging,J2EEApplication=eKeynox-GemaltoOEM-TMS-standalone-ear,J2EEServer=server
java.lang.NoSuchMethodError: org.apache.tomcat.util.http.mapper.Mapper.addContext(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Object;[Ljava/lang/String;Ljavax/naming/Context;)V
at org.apache.coyote.tomcat5.MapperListener.registerContext(MapperListener.java:609)
at org.apache.coyote.tomcat5.MapperListener.handleNotification(MapperListener.java:373)
...
at com.sun.enterprise.interceptor.DynamicInterceptor.registerMBean(DynamicInterceptor.java:263)
at com.sun.org.apache.commons.modeler.Registry.registerComponent(Registry.java:871)
at org.apache.catalina.core.StandardContext.registerJMX(StandardContext.java:6382)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5347)
at com.sun.enterprise.web.WebModule.start(WebModule.java:353)
at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

Is tomcat embedded in the grizzly jar ?

We use GlassFish v2.1 (sun application server 9.1.1 ; build b57-fcs)

Posted by Lolom on November 26, 2009 at 02:13 AM CET #

If I must user Glassfish V2 v2u2 instead of V2.1, can I upgrade to grizzly1.3.0?

As I tried before, it looks like my web-application can not be map.
It show Error registering Context
org.apache.tomcat.uti.http.mapper.Mapper.addContext .... exception.

Thanks!!

Posted by msnuser on December 25, 2009 at 09:06 AM CET #

G'day,
Just wondering whether you found a workaround to the HTTPS issue.. We seem to have encountered it ourselves recently and Glassfish just stops responding on HTTPS ports, but HTTP services continue as normal.

Posted by CoreyJohnston on April 14, 2010 at 03:35 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

oleksiys

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today