Jean-Francois Arcand's Blog

Customizing GlassFish v2 with 23 unpublished properties.

Because Grizzly has replaced the Sun WebServer runtime (starting with 9.0/GlassFish v1) in Sun's Application Server (SJSAS), and to avoid breaking compatibility with previous release, some configuration mechanisms are not officially exposed in GlassFish's domain.xml as attribute or elements. We will fix the problem with our upcoming v3 release, but for now those hidden features are sleeping with the bear! Time to officially expose them. Some are highly NIO related, some not. UPDATE: if you are using GlassFish v3, all properties starts with com.sun.grizzly instead of com.sun.enterprise.web.connector.grizzly

• -Dcom.sun.enterprise.web.connector.grizzly.selector.timeout==xxx : The time, in milliseconds, a NIO Selector will block waiting for events (users requests). By default it blocks 1000 (1 second). In some environment, increasing the value will reduce the CPU usage, but changes to that value aren't recommended unless you are seeing high CPU, most probably when your server doesn't have enough ram.
• -Dcom.sun.enterprise.web.connector.grizzly.displayConfiguration=true : flush Grizzly's internal configuration to the server logs (like number of threads created, how many polled objects, etc.)
• -Dcom.sun.enterprise.web.connector.grizzly.enableCometSupport=true : enable Comet support for all http-listener, including the Admin-gui.
• -Dcom.sun.enterprise.web.connector.grizzly.useDirectByteBuffer=true : Use direct ByteBuffer instead of heap ByteBuffer. Turning on direct byte buffer may improve performance if your application use a lot of memory or do a lot a write operations.
• -Dcom.sun.enterprise.web.connector.grizzly.pipelineClass=className : replace the default Grizzly's Thread pool with a customized one. You can easily change the Thread pool with your own by implementing the simple Pipeline interface.
• -Dcom.sun.enterprise.web.connector.grizzly.algorithmClassName=className : replace the current http parser with a customized one. This is useful if you want to optimize the parsing based on some application headers, etc., but quite dangerous as it might breaks the http logic so use it carefully.
• -Dcom.sun.enterprise.web.connector.grizzly.maxSelectors=xx x : The number of temporary NIO Selector used to read more bytes when incomplete read. The default is 20, but can significantly increase performance if you running on slow network.
• -Dcom.sun.enterprise.web.connector.grizzly.factoryTimeout= 5000 : When Grizzly try to read bytes from a browser's request, the bytes might not be available when the read occurs. By default, the thread will block for 5 seconds, and then drop the request. In some slow network (or fast), changing that value might significantly improve performance (mostly throughput).
• -Dcom.sun.enterprise.web.connector.grizzly.asyncHandlerClass=className : change the default Grizzly's Asynchronous Request Processing (ARP)AsyncHandler implementation. Useful if want to use ARP with your application
• -Dcom.sun.enterprise.web.connector.grizzly.asyncHandler.ports=8080,4848 : the port supporting the ARP mechanism.
• -Dcom.sun.enterprise.web.connector.grizzly.enableSnoop=true : dump the requests/response information in server.log. Useful for debugging purpose, but significantly reduce performance as the request/response bytes are translated to String.
• -Dcom.sun.enterprise.web.connector.grizzly.readTimeout=5000 : the time Grizzly waits on its first read before dropping the connection. Can improve your site performance if you are under denial-of-service attack frequently, by reducing the value.
• -Dcom.sun.enterprise.web.connector.grizzly.writeTimeout=30000 : the time before Grizzly stop waiting for the browser to read the response bytes. By default, if the browser haven't read all the response bytes after 30 seconds, Grizzly drops the connection. Useful to improve performance on slow network (or fast).
• -Dcom.sun.grizzly.comet.notificationHandlerClassName=classname : If you use Comet, you might want to improve the Server push performance by customizing its notification mechanism.
• -Dcom.sun.grizzly.http.bufferResponse=true : buffer the entire response before flushing it to the client. Might improve performance as you only execute a single write operation instead of several.
• -Dcom.sun.enterprise.web.connector.grizzly.OOBInline=true : See JDK definition.
• -Dcom.sun.enterprise.web.connector.grizzly.protocolFinders= xxx : Inject your own Protocol finder. Quite useful if you want to open a single tcp port on a server and serve several protocol on that port (not only http).
• -Dcom.sun.enterprise.web.connector.grizzly.protocolHandlers=className : when a protocol has been found (see the above property), redirect it to the proper container/server/etc.

All the above properties needs to be added in domain.xml using the jvm-options elements:

<jvm-options>-D....</jvm-options>

Now the following list of property can be added under the http-service in domain.xml:

<property name="xxx" value="xxx"/>

• compression=on|off enable http compression.
• selectorThread=className : change the default HTTP based SelectorThread and replace it with your own implementation. See the JRuby extension as an example.
• rcmSupport=true : enable the resource consumption management extension.
• maxPostSize=number : increase the size of an http post Grizzly can handle.
• cometSupport=true : enable Grizzly Comet support for a specific port (no all porhttp-listener).

Et hop! Grizzly no longer have an hidden side :-)!

technorati: grizzly comet glassfish jruby glassfishv2 http compression

Comments

• I am assuming you are showing the defaults. Or more specifically what is the default for enableSnoop?

  Posted by: jlorenzen on October 05, 2007 at 10:57 AM

• Hi,

  is it possible to set these variables with asadmin?

  
  
  Thorleif Wiik

  Posted by: thorleif on October 05, 2007 at 03:22 PM

• I wouldn't bother with the Euro spec turbo's, you won't gain a lot for the hassle. However a hybridised pair of stock turbo's might be worth it. They are the same externally as the stock turbo's but feature larger compressor and turbine wheels.

  The 550cc injectors will allow you to get close to 550HP with the right turbo's but in reality a small single turbo is required to achieve the power as even the hybrid OEM turbos arn't capable of flowing that much air.how to play roulette
  roulette how to win
  roulette tips
  how to win at roulette
  Run your car on water
  Run Car on Water
  Water Powered Car
  Water Car
  horse racing
  horse racing tips
  horse racing betting
  horse racing software
  horse racing systems
  downloadable movies
  download full version movies
  download movies
  movie downloads
  forex trading systems
  forex currency trading
  forex software
  learn forex
  world of warcraft guide
  wow gold guide
  wow guide
  world of warcraft cheats
  how to play poker
  learn poker
  poker strategy
  poker sites
  poker calculator
  free blackjack
  online blackjack
  blackjack strategy
  how to play blackjack
  iphone downloads
  iphone games download
  iphone download site review
  iphone download sites
  how to make money on ebay
  make money on ebay
  warren buffett
  warren buffet

  Posted by: j_doe1 on May 25, 2008 at 04:34 AM

• I am using glassfish v2u2 on AMD 4200 with 3GRAM
  I wrote a simple web-service which response the total request count(a integer) in my local LAN environment.
  I tested the environment on Windows XP SP3 with just tuned my heap size to 1G.
  I used SOAPUI to test the concurrent access withe 0 delay.
  I used 2 clients with SOAPUI to access the same web-service on the same time.
  I could get about 800 request/response for each client.(my client CPU usage reach 100% then I could not increase anymore)
  The network usage for the client is only about 12%, for the server is only about 25% and CPU for the server reach about 99%.
  That means total 1600.
  I used the same client but switch the same server with CentOS 5.2 installed with GlassFish(SunApplicationServer Ed. 9.1).
  No matter I used 1 or 2 clients to connect to the server at the same time, the total request/response I can get is about 600 only.
  I even tuned my server with your advise, but the result is the same.
  My server's network usage is only about 1.7Mbit/s.
  I am wondering is the problem arise from the Linux, my networking environment or the GlassFish(Grizzly) limitation on CentOS?
  Or I have to configured anything I missed?
  I really appreciate your help.
  Best Regrads,

  Eric
  I

  Posted by: pccontac168 on January 12, 2009 at 07:48 PM

• I tuned my GlassFish with your advise from another post about Grizzly tuning for JVM. not from this post.

  Posted by: pccontac168 on January 12, 2009 at 07:50 PM

This work is licensed under a Creative Commons License.