The Source for Java Technology Collaboration
User: Password:
Register | Login help    

Search

Online Books:
java.net on MarkMail:


Customizing GlassFish v2 with 23 unpublished properties.

Posted by jfarcand on October 4, 2007 at 12:14 PM PDT

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

Maintenant 038.jpg

  • -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"/>

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

technorati:

Related Topics >> Java Enterprise      
Comments
Comments are listed in date ascending order (oldest first)

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

Hi,
is it possible to set these variables with asadmin?
Thorleif Wiik

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

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

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

@pccontac168 Really sorry I

@pccontac168 Really sorry I guess java.net didn't send me your first post. Next time post it on users@grizzly.dev.java.net of tweet it to @project_grizzly or @jfarcand