客戶提了這么個問題:admin server因為out of memory導致性能很差,此時managed server連接admin server的話,可能因為網絡原因或者admin server因為OOM而導致的低性能,最終導致managed server很多線程掛死在socket read上。如果沒有超時機制,這樣的線程會一直掛著,如果這樣的線程很多的話,系統線程資源逐漸會被消耗完,從而引起managed server無法提供響應。下面是這個客戶的線程堆棧,
Thread-90 "[STUCK] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'" <alive, in native, suspended, priority=1, DAEMON> {
jrockit.net.SocketNativeIO.readBytesPinned(SocketNativeIO.java:???)
jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:25)
java.net.SocketInputStream.socketRead0(SocketInputStream.java:???)
java.net.SocketInputStream.read(SocketInputStream.java:107)
java.io.BufferedInputStream.fill(BufferedInputStream.java:189)
java.io.BufferedInputStream.read(BufferedInputStream.java:234)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.net.http.MessageHeader.isHTTP(MessageHeader.java:214)
weblogic.net.http.MessageHeader.parseHeader(MessageHeader.java:141)
weblogic.net.http.HttpClient.parseHTTP(HttpClient.java:477)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:329)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.rjvm.http.HTTPClientJVMConnection.connect(HTTPClientJVMConnection.java:161)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.rjvm.http.HTTPClientJVMConnection.createConnection(HTTPClientJVMConnection.java:86)
weblogic.rjvm.ConnectionManager.createConnection(ConnectionManager.java:1723)
weblogic.rjvm.ConnectionManager.findOrCreateConnection(ConnectionManager.java:1330)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
^-- Holding lock: weblogic.net.http.HttpClient@5cc3ea0[thin lock]
weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:440)
weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:315)
weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal(RJVMManager.java:220)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:206)
weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer(RJVMFinder.java:226)
weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:170)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:154)
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialReference(WLInitialContextFactoryDelegate.java:384)
weblogic.jndi.Environment.getInitialReference(Environment.java:223)
weblogic.server.channels.RemoteChannelServiceImpl.registerInternal(RemoteChannelServiceImpl.java:153)
^-- Holding lock: java.io.BufferedInputStream@5cc3faf[thin lock]
weblogic.server.channels.RemoteChannelServiceImpl.access$300(RemoteChannelServiceImpl.java:46)
weblogic.server.channels.RemoteChannelServiceImpl$TimerListenerImpl.timerExpired(RemoteChannelServiceImpl.java:101)
weblogic.timers.internal.TimerImpl.run(TimerImpl.java:253)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:197)
weblogic.work.ExecuteThread.run(ExecuteThread.java:164)
現在的問題是,對于這種問題可不可以通過超時設定來釋放線程。weblogic中, RJVM(即server之間,可能是admin-to-managed,也可能是managed-to-managed)之間,連接的協議有兩類五種,兩類是http、t3,五種是http、https、t3、t3s、local。超時設定時協議層面的東西,所以我們這里只討論http和t3。
對于t3,從上面的trace可以看到,連接的創建從ServerURL.findOrCreateRJVM()開始,這個方法有多種實現,不同的實現使用不同的timeout,客戶端程序可以通過向environment中set一個叫做weblogic.jndi.requestTimeout的變量,如果不做設定,則使用系統默認的DEFAULT_CONNECTION_TIMEOUT,這是個靜態值(0)。而在上面的stack trace中,我們可以看到,environment是在RemoteChannelServiceImpl中定義的,這個environment對于客戶而言是不可配置的,而weblogic自己的這個env中是不設定request timeotu的,也就是,無論哪種方式,connectionTimeout/readTimeout對于t3,都是不可配置的,而且默認是沒有超時的。
而對于http,HTTPClientJVMConnection在創建HttpURLConnection的時候,會讀取系統環境變量中的如下兩個變量,
weblogic.http.client.defaultReadTimeout
weblogic.http.client.defaultConnectTimeout
如果沒有設定,這兩個變量的默認值均為-1,即不做timeout。如果我們作了設定,這兩個值即讀超時、連接超時都會生效。這兩個值可以用于解決上述的問題。
posted on 2009-08-29 23:15
走走停停又三年 閱讀(3670)
評論(0) 編輯 收藏