@liyh

這么配置沒什么問題，每個server上可以配置多個指向不同db的data source

http://www.tkk7.com/fjin/archive/2009/01/22/252337.html

看看這，感覺是這個問題

@zz
1: domain-configuration-JTA
2: 報什么超時？ 事務(wù)超時還是thread stuck? 事務(wù)超時的話，你的看看每個操作耗時多少，找出性能瓶頸點，找不出來的話，只能加大tx timeout。 Thread stuck的話，做thread dump,看看thread掛在什么地方。
3：weblogic沒有這個層面的限制，兩個jvm之間可以任意通信，安全限制要在業(yè)務(wù)層面控制
4：沒有這樣的例子，呵呵

@zz
1:交易超時可以通過transaction timeout控制，這個超時可以是服務(wù)器級別的，也可以是指定服務(wù)級別的。
2：應(yīng)該是Cpu個數(shù)*80，這只是個推薦值，實際應(yīng)用以壓力、性能測試結(jié)果為準。
3：不是很理解你的問題，rjvm間沒有具體的安全機制，需要通過jndi、業(yè)務(wù)層的sec policy對業(yè)務(wù)進行保護。

北京

這不都是形勢所逼嘛，實在是找不到合適的人啊。

看在俺辛辛苦苦之前發(fā)帖的份上，管理員原諒俺一回吧

沒錯，正如我文中所說的那樣，pinned-to-thread被check后，連接一直被某個線程拿著而不會再close后釋放。至于用不用這個選項，看應(yīng)用啦！

@gan

這幾個參數(shù)跟集群沒什么關(guān)系，這些值由你的應(yīng)用對連接的需求決定。如果數(shù)據(jù)庫端對并發(fā)連接沒有什么限制，最后把initial和max設(shè)成一樣，這樣連接池不用在運行過程中去做擴展。

@sorcerer

你可以這么認為，如果費用不吃緊可以考慮lvs。failover是由weblogic的session replication實現(xiàn)的，這個是硬件層面無法做到的。

對于無法連接的server，apache會做mark bad。過了max skip time后，這個server會被重新加入server list（無論這個server是否存活），然后嘗試創(chuàng)建到該server的連接，如果失敗，那么繼續(xù)將其mark bad。至于，hanging server的問題，參考WLIOTimeoutSecs。

@禮物
學(xué)習(xí)了，謝謝 :)

不要太拘泥于定義。所謂TI，說白了就是工具接口，沒必要把要什么語言定義死吧，要這個語言寫就是，換個語言寫就不是。也許你是對的，TI用c或c++寫，而JDI，其實就是TI的高層接口，對于Java程序員更為適用。兩者的功能區(qū)別有多大？ 他們的功能都依賴于JVM開放函數(shù)，即jmvti.h中的函數(shù)。你用TI要限于這些函數(shù)，而JDI就是對這些函數(shù)的封裝，我不覺得會少多少東西。至少我們常用的：heap遍歷、class裝載、卸載監(jiān)聽、方法調(diào)用監(jiān)聽、鎖等待監(jiān)聽等一一都有。至于類動態(tài)更新，你可以看看：http://www.tkk7.com/fjin/archive/2009/09/11/294634.html

對，線程不會被結(jié)束，等同于thread.interrupt()

你手里有TI的例子嗎？我對這塊比較感興趣，如果有能否共享一下？ 你說的是agent吧，我這里用的是JDI，TI的Java接口。

Tools can be written directly to JVM TI or indirectly through higher level interfaces. The Java Platform Debugger Architecture includes JVM TI, but also contains higher-level, out-of-process debugger interfaces. The higher-level interfaces are more appropriate than JVM TI for many tools. For more information on the Java Platform Debugger Architecture, see the Java Platform Debugger Architecture website.

參考這個鏈接：http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html

對于系統(tǒng)時間問題，我們可以用下面的小程序測試一下，

public class JVMTimeTest {

public static void main(String args[]){
JVMTimeTest test = new JVMTimeTest();
test.retriveTime();
}

private void retriveTime(){
long previousTime = -1;
while(true){
long currentTime = System.currentTimeMillis();
System.out.println("currentTime is: " + currentTime);
if(previousTime > currentTime)
System.out.println("OS time change is detected! and:" +
"previousTime: " + previousTime + " " +
"currentTime: " + currentTime);
previousTime = currentTime;
try{
Thread.currentThread().sleep(100);
}catch(Exception e){}
}
}
}

什么樣的runtime exception呢？ 有可能是你的acknowledege可能由于網(wǎng)絡(luò)問題沒有發(fā)過去，導(dǎo)致message處于receive，所以不會重新發(fā)送。建議你用client_acknowledge，等你消息成功處理后直接調(diào)用message.acknowledge()。

你把$DOMAIN_HOME\servers\$SERVER_NAME\data\store\default下的.dat文件備份到其他地方，然后刪除他們，重啟服務(wù)器看看。

172.20.1.18:7005這個url和你當前的AdminServer4Smejb地址、端口一致嗎？ 如果一致，172.20.1.18:7005目前通嗎？

你有什么疑問，這里說好了。

赫赫，我只是把學(xué)到的東西紀錄在這里，方便的時候回頭看看，溫故而知新嘛。

這個問題基本很難重現(xiàn)，原因很可能跟系統(tǒng)環(huán)境有關(guān)系。weblogic在JMSSession中計算timeout的時候，參考了System.currentTimeMills()，如果系統(tǒng)起了NTP client定期做時間同步的話，可能會在計算的時候引起負值。如果真跟系統(tǒng)時間有關(guān)，那么最好的做法就是保證客戶端運行期間，不要做系統(tǒng)時間同步。

另外一個客戶端回避的方法就是客戶端使用receiveNoWait()來代替receive()或receive(long timeout)。

檢查一個server log，看看是multi cast有問題，還是managed server本身出了問題。通常情況下，如果server正常，log中你可以看到j(luò)oin cluster之類的文字

的確，并行寫文件不如預(yù)期的那么快，但相對于串行，大概還是有50%的提升。我做了一個測試，寫10個25M的文件，串行要82秒的時間，而并行的每個線程不到53秒。結(jié)果如下：

singleThread writer takes: 82.328 secs!

multiThread writer takes: 51.016 secs!
multiThread writer takes: 51.5 secs!
multiThread writer takes: 52.047 secs!
multiThread writer takes: 52.453 secs!
multiThread writer takes: 52.531 secs!
multiThread writer takes: 52.781 secs!
multiThread writer takes: 52.828 secs!
multiThread writer takes: 52.844 secs!
multiThread writer takes: 52.86 secs!
multiThread writer takes: 53.219 secs!