專利名稱：：用于具有過載保護的應用服務器的系統(tǒng)和方法
技術領域：
：本發(fā)明一般涉及應用服務器和消息系統(tǒng)(messagingsystem),尤其涉及一種用于具有過載保護的應用服務器的系統(tǒng)和方法。
背景技術：
：在典型的應用服務器和網(wǎng)絡服務器環(huán)境中，在很短的時間內(nèi)服務器可能接收上千個請求。在特定的情況下服務器將會變得過載并且不能再處理更多的請求。對于用戶來說，這會呈現(xiàn)為頁面錯誤或者凍結頁面(frozenpage)。用戶通常會通過請求來不斷地沖擊(hitting)服務器，而這實際上不具有任何效果并且只會使問題變得更糟。所需要的是一種能夠通知用戶當前服務器過載的機制，并且這能夠允許服務器在不必處理更多請求的情況下重新獲得穩(wěn)定性。傳統(tǒng)的做法是產(chǎn)生一個服務器"找不到對象"，或者將請求放置在一個固定長度的隊列中。然而，既沒有嘗試特性化(characterize)請求，也沒有例如拒絕那些將超過一分鐘的請求而服務其它請求。
發(fā)明內(nèi)容根據(jù)本發(fā)明的一個實施例，一種系統(tǒng)，例如一個服務器或集群(cluster)，被設計為每當服務器變得過載時就產(chǎn)生一個消息和/或拒絕進一步的工作。這以一種處理器-效率(processor-efficient)方式來進行，以便不對已經(jīng)高負荷的服務器添力。更多的壓力。該拒絕消息和動作(action)是可定制的。然而，在定制為靈活的點和過度定制為添加更多處理器要求的點之間僅有很小的區(qū)別(athinlinebetween)。最重要的是拒絕必須被快速地處理。傳統(tǒng)的方案不能適用于某些請求，例如保證支付請求(ensuringpaymentrequest)是以簡單瀏覽請求的開銷(expense)傳送(communicated)的。公司可以通過安裝多個服務器來從事這一處理。然而，本發(fā)明允許即使在只有一個服務器的情況下也能夠進行最佳的處理。根據(jù)一個實施例，該系統(tǒng)確定該請求將出現(xiàn)在優(yōu)先級隊列中的何處，并且拒絕那些在該隊列之后的請求。其通過確定這些請求(例如HTTP請求)將被遞送到哪個工作負載管理器(workloadmanager)來使用最少的處理時間快速進4于這一處理。該HTTP請求通過一個排隊邏輯(queuinglogic)來進行句法分析(parsing),并且確定其目的地小服務程序(servlet)。管理員可以配置哪個小服務程序應當優(yōu)先于(prioritized)其它小服務程序。句法分析于是暗示(implies)與那個小服務程序相關的特定工作負載管理器以及該請求的相應優(yōu)先級。該請求并不被太嚴格的查看，而主要是在URL級上確定哪個工作負載管理器或小服務程序?qū)⑻幚碓撜埱蟆Ｔ撓到y(tǒng)還可用于向用戶和管理員提供反饋，指示在當前某些請求將不被處理，但是例如其它請求可以被處理。這個消息還可以在合理的限度內(nèi)進行定制，而這是現(xiàn)有技術所不能達成的。根據(jù)一個實施例，該系統(tǒng)被配置成指定各個工作負載管理器的閾值、以及全局過載閾值。請求被給出虛擬時間戳，并且根據(jù)優(yōu)先級進行相應的排隊。當超過該閾值時，低于該閾值優(yōu)先級的請求^皮拒絕。圖1示出了根據(jù)本發(fā)明的一個實施例的包括使用服務器過載保護的系統(tǒng)的環(huán)境的視圖。具體實施例方式過載保護在服務器和集群的總體可用性中扮演著重要的部分。在典型的應用服務器和網(wǎng)絡服務器環(huán)境中，在很短的時間內(nèi)服務器可能接收上千個請求。在特定的情況下服務器將會變得過載并且不能再處理更多的請求。對于用戶來說，這會呈現(xiàn)為頁面錯誤或者凍結頁面。用戶通常通過請求來不斷地沖擊服務器，而這實際上不具有任何效果并且只會使問題變得更糟。所需要的是一種能夠通知用戶當前服務器過載的機制，并且這能夠允許該服務器在不必處理更多請求的情況下重新獲得穩(wěn)定性。傳統(tǒng)做法是產(chǎn)生一個服務器"找不到對象"，或者將請求放置在一個固定長度的隊列中。然而，既沒有嘗試請求，也沒有例如拒絕那些將超過一分鐘的請求而服務其它請求。其它的實施并不了解過載條件并且繼續(xù)接受請求。接收請求將加重狀況導致更糟的性能和穩(wěn)定性。所期望的是在這種情況下的請求的快速失敗。由于負載被在剩余的集群成員中分散，這在集群的情況下能夠良好的工作。根據(jù)本發(fā)明的一個實施例，一種系統(tǒng)，例如一個服務器或集群，被設計為每當服務器變得過載時就產(chǎn)生一個消息和/或拒絕進一步的工作。這以一種處理器-效率方式來進行，以便不對已經(jīng)高負荷的服務器添加更多的壓力。該拒絕消息和動作是可定制的。然而，在定制為靈活的點和過度定制為添加更多處理器要求的點之間僅有很小的區(qū)別。最重要的是拒絕必須被快速地處理。傳統(tǒng)的方案不能適用于某些請求，例如保證支付請求是以簡單瀏覽請求的開銷傳送的。公司可以通過安裝多個服務器來從事這一處理。然而，本發(fā)明允許即使在只有一個服務器的情況下也能夠進行最佳的處理。根據(jù)一個實施例，該系統(tǒng)確定該請求將出現(xiàn)在優(yōu)先級隊列中的何處，并且拒絕那些在該隊列之后的請求。其通過確定這些請求(例如HTTP請求)將被遞送到哪個工作負載管理器來使用最少的處理時間快速進行這一處理。該HTTP請求通過一個排隊邏輯來進行句法分析，并且確定其目的地小服務程序。管理員可以配置哪個小服務程序應當優(yōu)先于其它小服務程序。句法分析于是暗示與那個小服務程序相關的特定工作負載管理器以及該請求的相應優(yōu)先級。該請求并不被太嚴格的查看，而主要是在URL級上確定哪個工作負載管理器或小服務程序?qū)⑻幚碓撜埱蟆Ｔ撓到y(tǒng)還可用于向用戶和管理員提供反饋，指示在當前某些請求將不被處理，但是例如其它請求可以被處理。這個消息還可以在合理的限度內(nèi)進行定制，而這是現(xiàn)有技術所不能達成的。根據(jù)一個實施例，該系統(tǒng)被配置成指定各個工作負載管理器的閾值、以及全局過載閾值。請求被給出虛擬時間戳，并且根據(jù)優(yōu)先級進行相應的排隊。當超過該閾值時，低于該閾值優(yōu)先級的請求被拒絕。圖1示出了根據(jù)本發(fā)明的一個實施例的包括使用服務器過載保護的系統(tǒng)的環(huán)境的視圖。如圖l所示，服務器100接受來自多個客戶機102、104、106的請求。在這個例子中，服務器100包括多個小服務程序108、110、112,每個小服務程序都有它們的相關工作負載管理器。服務器包括服務器狀態(tài)監(jiān)視器116或類似的用于確定當前服務器負載的機制。服務器還包括優(yōu)先級隊列118,用于在將請求傳送到小服務程序之前接受請求，以及排隊邏輯124,用于從服務器狀態(tài)監(jiān)視器接受狀態(tài)信息以及控制優(yōu)先級隊列的進入。在操作中，當客戶機發(fā)出請求126、130、138時，給定當前的系統(tǒng)狀態(tài)，排隊邏輯將只對那些被認為可以接受的請求進行排隊。配置有更高優(yōu)先級的小服務程序的請求被以更高的優(yōu)先級排隊。配置有低的優(yōu)先級的小服務程序?qū)l(fā)現(xiàn)輸入的(incoming)請求被拒絕138，在某些例子中利用客戶機消息或動作來拒絕。示例實施下面的部分描述了一個示例實施，該示例實施包括在超過執(zhí)行隊列長度、交易(transaction)計數(shù)、HTTP對話計數(shù)以及遭遇到OOME的時候所采取的過載動作。根據(jù)一個實施例，JRockit專用API被用于計算在每個GC間隔后的存儲器用量(memoryusage),并且當平均空閑存儲器低于所配置的閾值時提供通知。其通過將在過載集群中的RMI客戶機導向(directingto)還可以接受請求的成員來保證這些RMI客戶機的更快的失敗保護(failover)。術語定義，縮寫和簡寫過載一一種服務器情況，其中接收更多的請求將導致服務器性能和穩(wěn)定性的惡化。服務器已經(jīng)超過了其資源容量，諸如可用的存儲器。OOM—由VM拋出(thrown)的java.lang.OutOfMemoryErrorFD—文件描述符OOM保護這種特征使得服務器在遭遇到OOM錯誤時能夠退出。在JRockitVM上，專用API被用于在每次全面(full)GC后計算存儲器用量，并在平均空閑存儲器降到閾值之下時產(chǎn)生事件(events)。OOM保護有兩個部分一在OOME時退出，以及在平均空閑存儲器降到閾值之下時的mbean通知。服務器將在執(zhí)行請求期間捕捉拋出的OOM錯誤，并在被配置為立即退出的情況下立即退出。這是基于應用程序本身不捕捉OOM錯誤的假定的。如果服務器是由NodeManager或由HA解決方案支持的(backed),則該特征是有用的。服務器將以一個充分定義的、能夠和正常的VM中斷相區(qū)分的退出代碼來退出。在JRockit上，其管理API被用于在每次GC間隔后計算存儲器用量。如果平均空閑存儲器低于一個配置的閾值，則一個存儲器低的事件(lowmemoryevent)將被發(fā)送到注冊的監(jiān)聽者(listener)。該服務器被當作過載對待，并且采取配置的過載動作。注意通知機制的設計并不是JRockit專用的，而是將用于包括該功能的其它VM。在存儲器低的通知中可以建入(buildinto)滯后現(xiàn)象(hysteresis)。存在一個被使用的存儲器的上限，當該上限被達到后就發(fā)送存儲器低的通知。還存在一個下限，當該下限被達到后就撤銷存儲器低的通知?？刂婆_(console)可以具有包含下面選項的過載保護部分當遭遇OutOfMemoryError時的退出服務器處理平均空閑存儲器閾值和計算空閑存儲器的存儲器樣本的數(shù)量。服務器能夠捕捉在執(zhí)行請求期間生成的OOME,并用充分定義的錯誤代碼來退出。這里假定應用程序本身不處理OOME。系統(tǒng)將在內(nèi)部子系統(tǒng)的任何可能的地方類似地處理OOME。管理員能夠?qū)⒖臻e存儲器閾值配置為總存儲器的百分比。在采用了這個閾值和配置的過載動作后，該服務器被認為是過載的。用于確定存儲器低的情況的參數(shù)已經(jīng)存在于ServerMbean(例如LowMemorySampleSize)中。該系統(tǒng)更進一步(goesonestepforther)并在JRockit和可比的VM產(chǎn)品上執(zhí)行過載動作。J歸編程接口子系統(tǒng)可以利用標準MBean通知方案來為存儲器通知注冊。下面是一個例子1.向JVMRuntime添力口MemoryListenerJVMRuntimeMBeanjvmRuntime=serverRuntime.getJVMRuntime();mbeanServer.addNotificationListener(jvmRuntime.getObjectName(),myMemoryListener，myMemoryFilter,null);2.MyMemoryFilter的實施importweblogic.management.runtime.MemoryNotification;publicclassMyMemoryFilterimplementsJavax.management.NotificationFilter{publicbooleanisNotificationEnabled(Notificationn){if(ninstanceofMemoryNotification){longfreeMemory=((MemoryNotification)n).getFreeMemory();longtotalMemory=((MemoryNotification)n).getTotalMemory();if(freeMemory<(0.2*totalMemory)){returntrue;returnfalse;}〃endofMyMemoryFilterweblogic.management.runtime.MemoryNotification可以有兩種方法,getFreeMemory()禾口getTotalMemory()。getFreeMemory()返回在"ServerMbean丄owMemorySampleSize"采樣上的平均空閑存儲器。關于平均空閑存儲器的周期性的通知被發(fā)送到具有指定的通知過濾器的監(jiān)聽者。如果沒有指定通知過濾器，則只有當空閑存儲器低于全局配置的存儲器閾值時才發(fā)送通知。執(zhí)行隊列長度保護本特征允許管理員限制在執(zhí)行隊列中未完成的(outstanding)請求的數(shù)量?；緛碚f，管理員可以定義全局隊列閾值，在超過該閾值后請求將被扼殺(throttled)。自我調(diào)諧的分派模型還允許排隊的請求與OverloadManager相關。OverloadManager為那個請求類別確定最大未決請求。OverloadManager取代(override)全局隊列閾值。具有低公平共享(lowfairshare)的非-交易性RMI請求在過載服務器中將被立即拒絕。這應用在單向、同步或非同步RMI中。如果過載條件繼續(xù)維持，則更高優(yōu)先級的請求將開始被拒絕。對于這個規(guī)則有一些例外目的地為諸如JMS的子系統(tǒng)的請求和交易被允許進入，這是由于它們執(zhí)行它們自己的過載管理。管理員(admin)請求被允許。除了(apartfrom)諸如控制臺的內(nèi)部管理應用之外的網(wǎng)絡應用(webapp)請求將被立即拒絕。更快的RMI客戶端失敗保護如果某些或所有的集群節(jié)點都過載，則可集群化的RMI客戶機被給予一個特殊的ref。該特殊ref指向不過載并且還可以接收應用請求的集群節(jié)點。這將避免客戶端嘗試多哥集群節(jié)點并失敗。這一特征使得RMI客戶機能夠快速識別在過載集群中的健康節(jié)點而不需要嘗試在復制列表(replicalist)中的每一項(entry)。如果管理員啟動新的集群節(jié)點來幫助減少過載，其將把客戶機導向新啟動的節(jié)點。每個服務器的可用信息被以集群的節(jié)奏(heartbeat)發(fā)送?？捎眯畔⒄f明該服務器是否在運行、是否過載和是否被桂起(suspended)。如果服務器超過了執(zhí)行隊列閾值或者運行存儲器過低，則該服務器被視為過載?？捎眯畔⒈话l(fā)送回客戶機并被如下使用集群中的所有服務器都是健康的。發(fā)送回客戶機的復制列表將具有所有服務器項。客戶機可以基于其負載平衡策略任意地選擇任何服務器。集群中的一個或多個服務器是過載的。作為連帶響應(piggybackresponse)的一個部分，系統(tǒng)將向指向不過載服務器的客戶機發(fā)送特殊的ref。由于其具有更好的成功機會(change),客戶機將在其下一個請求中嘗試該特殊ref。在執(zhí)行后，服務器可以返回另一個特殊ref或者為下一個客戶機執(zhí)行保留相同的一個。這種情況將持續(xù)直到過載的情況過去。如果有多個ref，則該服務器輪換(rotates)特殊ref。如果啟動新的集群節(jié)點來降低過載的條件，該特殊ref將指向新啟動的節(jié)點。為了防止在新節(jié)點的泛濫(flooding),在幾次請求后可以撤銷該特殊ref。如果所有的集群節(jié)點都是過載的，則客戶機被請求不要再進行嘗試直到經(jīng)過某個時段。等待時間是由服務器的吞吐量、在執(zhí)行隊列中的等待請求的數(shù)量等確定的。有效(active)交易限制本特征允許管理員限制在服務器中的有效交易的數(shù)量。一旦達到了最大的限制，服務器將拒絕參與新的交易。注意與已有交易相關的RMI呼叫是允許進入的。只有試圖啟動新的交易的RMI呼叫將被禁止。控制臺可以具有指定交易限制的選項。當超過交易限制時，交易子系統(tǒng)^年拋出javax.transaction.SystemException。有效HTTP對話限制本特征允許管理員限制在服務器中的有效HTTP對話的數(shù)量。限制新對話的數(shù)量能避免OOME。如果達到了最大對話限制，系統(tǒng)將拒絕那些創(chuàng)建新HTTP對話的請求。在集群中，插件(plugin)將把請求導向另一個集群節(jié)點。在一個非-集群的情況下，服務器可以將請求導向一個替代(alternate)服務器。服務器中允許的主HTTP對話的最大數(shù)量可以在控制臺中設置。對話限制是跨越所有應用的全局性的。如果達到了max-sessions限制，小服務程序包容器(container)將執(zhí)行下列動作之一如果服務器是在集群中，返回響應503并且插件將對該請求進行失敗保護。如果該服務器不在集群中但是指定了一個替代服務器，則小服務程序包容器將該請求導向該替代服務器。如果在網(wǎng)絡應用描述符中定義了過載-錯誤-頁面(overload-error-page),則服務器將用其將過載響應返回客戶機。如果在控制臺中指定了過載重新導向(redirection)url,則其將被用來發(fā)送過載響應。死鎖一企測在JRockit上，系統(tǒng)能夠確定是否有線程死鎖(threaddeadlock)并且按照期望退出。這一特征只在具有檢測線程死鎖能力的VM上才是可能的。服務器將定期檢查卡住的(stuck)線程。如果超過一個線程被卡住，則系統(tǒng)使用JRockit管理API來檢查該線程是否巻入了死鎖。在這種情況下服務器可以被配置為退出。如果服務器是由NodeManager或諸如Veritas的HA解決方案支持的，則這是有用的。HA后端將重啟服務器。這提供了自動的失敗恢復。注意該系統(tǒng)將只在同一處理中檢測死鎖。處理之間的死鎖是超出該范圍的。只有在服務器中的所有的線程都卡住，并且自我-調(diào)諧線程模型不能添加更多的線程時才執(zhí)行上述的動作。控制器可以具有在檢測到線程死鎖時退出服務器進程的選項。服務器將經(jīng)常地監(jiān)視其線程的健康狀況，并確定它們中的任何一個是否被卡住?？ㄗ〉臅r間間隔已經(jīng)可以通過控制器來配置。如果超過一個線程被卡住，我們將使用JRockit管理API來檢查是否被卡住的線程巻入了死鎖。服務器在結束(killing)自己之前在日志中保存線程的轉儲(dump)。每個通道的FD保留管理員可以為每個網(wǎng)絡通道進行文件描述符的保留。這將使得管理員即使在DOS攻擊期間也能訪問服務器。這將保證即使是在服務器沉重負載的情況下，管理員用戶(adminuser)也總是能夠獲得對服務器的訪問。即使在DOS攻擊期間，服務器也將被管理。有可能為管理員用戶指定為每個網(wǎng)絡通道保留的FD的數(shù)量。服務器將保證在任何時間為管理員用戶分配至少所保留的數(shù)量的FD。充分定義的退出代碼出代碼可以由shell腳本程序或HA代理來確定是否需要服務器重啟。表1所示的退出代碼被定義用于服務器終止。<table>tableseeoriginaldocumentpage13</column></row><table>表1過載服務器狀態(tài)"過載"(OVERLOADED)狀態(tài)可以被添加為新的服務器狀態(tài)。如果服務器在運行但是不是過載的，則該狀態(tài)由ServerRuntimeMBean.getState()和ServerLifeCycleRuntimeMbean.getState()返回。或是由于所執(zhí)行隊列長度達到其閾值或是由于存儲器低而發(fā)生過載條件。當過載條件消除(goaway)后，服務器狀態(tài)將變回運行。狀態(tài)轉換如下1.關閉一〉待命一〉運行一〉過載一〉運行一〉關閉2.關閉一>待命一〉運行一〉過載一〉失敗一〉關閉在運行狀態(tài)中可用的操作也在過載狀態(tài)中得到支持。因此，服務器還可以從過載狀態(tài)被掛起或關閉。具有單獨的過載狀態(tài)保證了過載條件;陂顯著地顯示在管理控制臺中并且通過各種MBean實用(utilities)。其也便于子系統(tǒng)向ServerLifeCycleRuntime添加通知監(jiān)聽者以及得到作為正常狀態(tài)改變通知方案(scheme)的一部分的過載通知。本發(fā)明可以由傳統(tǒng)通用或?qū)Ｓ脭?shù)字計算機或者根據(jù)本公開編程的微處理器編程來實施。對于軟件領域技術人員顯而易見的是可以由有經(jīng)驗的程序員基于本公開的教導來容易地準備適當?shù)能浖幋a。介質(zhì)(媒介)的計算機程序產(chǎn)品，其可被用于對計算機編程以執(zhí)行本發(fā)明的任何處理。該存儲介質(zhì)可以包括，但不局限于，軟盤、光盤、DVD、CD-ROM、微型石更盤(microdrive)以及磁光盤、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、閃速存儲設備、磁性或光學卡、納米系統(tǒng)(包括分子存儲器IC)或適合用于存儲指令和/霍數(shù)據(jù)的任何類型的媒介或設備。前面敘述的本發(fā)明用于說明和描述的目的而被提供。其不意味著窮盡性或為了將本發(fā)明限制在所公開的具體形式。選擇和描述實施例以便最好地說明本發(fā)明的原理及其實際應用，從而使得本領域的其它技術人員能夠理解本發(fā)明可用于很多實施例，并且具有適合于可想到的特定用途的改變。特別是，當描述使用JRockit或與JRockit—起使用的多種實施例時，顯然能夠使用其它的VM產(chǎn)品。本發(fā)明的范圍旨在由所附權利要求及其等價物來定義。權利要求1.一種用于提供具有過載保護的應用服務器的系統(tǒng)，包括服務器，其被配置來從客戶機接收請求，并且具有在其上操作的多個工作負載管理器；排隊邏輯，其確定由該請求被導向的工作負載管理器的優(yōu)先級所確定的所接收的請求的優(yōu)先級；和其中，所述排隊邏輯被配置來當服務器狀態(tài)指示可能的過載條件時拒絕某種所述請求。2.如權利要求l所述的系統(tǒng)，其中每個工作負載管理器與一個小服務程序相關，并且其中所述請求被導向在所述服務器上工作的小服務程序，并與所述工作負載管理器取得聯(lián)系(reachedby)。3.4.如權利要求3所述的系統(tǒng)，其中所述可用線程時間部分被指定為用于一個工作負載管理器的允許的線程時間對于另一個工作負載管理器的相對的共享值。5.如權利要求l所述的系統(tǒng)，其中所述工作負載管理器可以由系統(tǒng)管理員來手動優(yōu)先化。6.如權利要求5所述的系統(tǒng)，其中所述系統(tǒng)包括由所述系統(tǒng)管理員在優(yōu)先化所述工作負載管理器中使用的控制臺應用程序。7.如權利要求l所述的系統(tǒng)，其中這樣根據(jù)目的地工作負載管理器優(yōu)先化的請求根據(jù)它們的優(yōu)先級被放置在隊列中。8.如權利要求7所述的系統(tǒng)，其中未被放置在隊列中的請求被拒絕。9.如權利要求l所述的系統(tǒng)，其中所述請求可以用返回客戶機的定制消息來拒絕。10.如權利要求l所述的系統(tǒng)，其中所述系統(tǒng)接收關于其用來確定可能的過載條件的服務器的當前狀態(tài)的狀態(tài)信息。11.一種用于提供具有過載保護的應用服務器的方法，其包括下列步驟:在服務器接收來自客戶機的請求，所述服務器具有多個在其上操作的工作負載管理器；確定由該請求被導向的工作負載管理器的優(yōu)先級所確定的所接收的請求的優(yōu)先級；和當服務器狀態(tài)指示可能的過載條件時拒絕某種所述請求。12.如權利要求11所述的方法，其中每個工作負載管理器與一個小服務程序相關，并且其中所述請求被導向操作在所述服務器的小服務程序，并與所述工作負載管理器取得聯(lián)系(reachedby)。13.如權利要求11所述的方法，其中所述工作負載管理器是通過分配一部分可用的線程時間給它們使用來進行優(yōu)先化的。14.如權利要求13所述的方法，其中所述可用線程時間部分被指定為用于一個工作負載管理器的允許的線程時間對于另一個工作負載管理器的相對的共享值。15.如權利要求11所述的方法，其中所述工作負載管理器可以由系統(tǒng)管理員來手動優(yōu)先化。16.如權利要求15所述的方法，其中所述系統(tǒng)包括由所述系統(tǒng)管理員在優(yōu)先化所述工作負載管理器中使用的控制臺應用程序。17.如權利要求11所述的方法，其中這樣根據(jù)目的地工作負載管理器優(yōu)先化的所述請求根據(jù)它們的優(yōu)先級被放置在隊列中。18.如權利要求17所述的方法，其中未被放置在隊列中的請求被拒絕。19.如權利要求11所述的方法，其中所述請求可以用返回客戶機的定制消息來拒絕。20.如權利要求11所述的方法，其中所述系統(tǒng)接收關于其用來確定可能的過載條件的服務器的當前狀態(tài)的狀態(tài)信息。21.—種計算機可讀介質(zhì)，包括存儲在其上的當被執(zhí)行時使得所述計算機執(zhí)行下列步驟的指令在服務器接收來自客戶機的請求，所述服務器具有多個在其上操作的工作負載管理器；確定由該請求被導向的工作負載管理器的優(yōu)先級所確定的所接收的請求的優(yōu)先級；和當服務器狀態(tài)指示可能的過載條件時拒絕某種所述請求。全文摘要一種用于具有過載保護的應用服務器的系統(tǒng)和方法。一種系統(tǒng)，例如一個服務器或集群，被設計成每當服務器過載時就生成一個消息和/或拒絕進一步的工作。其使用處理器-效率的方式來進行，以便不對已經(jīng)高負荷的服務器添加更多的壓力。拒絕消息或動作是可定制的。根據(jù)一個實施例，該系統(tǒng)確定在優(yōu)先級隊列中該請求應該在哪里出現(xiàn)，并拒絕那些在該隊列之后的請求。通過確定該請求將被遞送到哪個工作負載管理器，其能快速和使用最少的處理時間來這樣做。文檔編號G06F9/54GK101305346SQ200580001186公開日2008年11月12日申請日期2005年5月20日優(yōu)先權日2004年5月21日發(fā)明者安諾·R·蘭根,納里什·里瓦納魯申請人:Bea系統(tǒng)公司