在企業(yè)級的應(yīng)用中，經(jīng)常會存在一些訪問非常頻繁的web應(yīng)用，這些web模塊很容易就會將GlassFish的HTTP
Thread全部占滿，這時其它的web應(yīng)用就始終在queue中等待獲取HTTP的connection，直至超時。
在Weblogic中，我們可以通過在weblogic.xml中設(shè)置wl-dispatch-policy去引用創(chuàng)建的execute queue，來控制該web應(yīng)用可使用的線程數(shù)。但在GlassFish中就沒有相應(yīng)的實現(xiàn)方式，如果是EJB組件，可以采取Request Partitioning的方式來分配模塊所使用的資源，可參考http://docs.sun.com/app/docs/doc/820-4343/abecu?a=view。對于Web應(yīng)用只有等到V3版本發(fā)布時才具備資源分配的功能了，查看GlassFish
V3 Improvement List: http://wiki.glassfish.java.net/Wiki.jsp?page=V3GeneralImprovements,
其中的Gen-009就是對應(yīng)的這項功能。對于SUN現(xiàn)在的局面，不知道要等到什么時候才會發(fā)布這個feature，好在已從SUN離職的Grizzly的開發(fā)者Jeanfrancois在V2中就已經(jīng)實現(xiàn)了該功能，可以通過配置的方式實現(xiàn)web資源的分配。
Grizzly的Application Resources
Allocation(ARA)擴(kuò)展是GlassFish的Resource Consumption
Management(RCM)的web實現(xiàn)。ARA允許你為每個web應(yīng)用虛擬化系統(tǒng)資源，就像Solaris
10 中的Zone。ARA現(xiàn)在支持兩種應(yīng)用于TCP請求的規(guī)則：
1.
保留指定比率的可用的heap
memory；
2.
保留指定比率的可用的thread；
對于我當(dāng)前的場景，只需要使用第二種規(guī)則即可。要實現(xiàn)這種資源分配的配置，需要加入以下的配置：
1.
在http-listener-1中添加property：rcmSupport=true；
2.
添加jvm-options：-Dcom.sun.enterprise.web.ara.policyMetric=/yourApp/requestURI1|0.5,/yourApp/requestURI2|0.3；
通過上面的配置，Grizzly將會保留50%的線程為/yourApp/requestURI1的請求處理，30%用于/yourApp/requestURI2的處理，剩余的20%用于其它請求的處理。總的線程數(shù)為http-service.request-processing.thread-count減去http-service.request-processing.initial-thread-count，initial-thread-count創(chuàng)建出來的那幾個線程好像就沒用了，但是該值不能設(shè)為0，至少要為1。
本以為到此就算結(jié)束了，但GlassFish實在是太偷工減料了，默認(rèn)實現(xiàn)的ThreadRatioRule匹配不到我設(shè)置的URL，并且創(chuàng)建線程的函數(shù)不是線程安全的，當(dāng)有并發(fā)請求進(jìn)來的時候，就會創(chuàng)建很多組線程，無奈之下只有自己重新寫了個實現(xiàn)，最后把實現(xiàn)類打了個jar，然后在java-config的classpath-prefix指定該jar。最后檢查一下你的http-listener-1中是否有proxiedProtocols屬性，如果有的話就必須要刪除，否則RCM不生效，該屬性在developer模式中不存在，在Cluster模式下默認(rèn)會添加。
現(xiàn)在你的Web應(yīng)用就可以實現(xiàn)資源分配了，如果Grizzly默認(rèn)的實現(xiàn)不滿足你的要求，還可以擴(kuò)展他的實現(xiàn)。
參考資料：
Resource
Consumption Management using GlassFish
Improving
Ajax performance and usability by using request based priority