1：在weblogic cluster環(huán)境中，配置一個(gè)Distributed Queue, 它的QueueMember分布于cluster中不同managed server上的JMS Server上。JMS采用filestore方式存儲(chǔ)消息。如果運(yùn)行過(guò)程中，某一個(gè)managed server發(fā)生宕機(jī)的話，它的JMS Server上的消息在重起前，能不能被客戶(hù)端consume掉？

        要回答這個(gè)問(wèn)題，首先我們先看一下Distributed Queue的概念。所謂distributed queue, 顧名思義，分布式隊(duì)列。它實(shí)際上是個(gè)邏輯Queue, 管理著一堆物理Queue。這些物理Queue對(duì)于客戶(hù)端是透明的，即客戶(hù)端發(fā)送、接收消息的時(shí)候，他們無(wú)法辨別這個(gè)消息到底發(fā)到哪個(gè)物理Queue，消息從哪個(gè)物理Queue接收到的。客戶(hù)端看到的只是一個(gè)DQ，對(duì)于客戶(hù)端已經(jīng)足夠了，至于發(fā)到哪，從哪接收，這些由Weblogic幫你去做。好了，回到這個(gè)問(wèn)題，客戶(hù)做JMSServer配置的時(shí)候，filestore不能共享文件，即一個(gè)filestore對(duì)應(yīng)一個(gè)物理文件（這些文件可以通過(guò)ScanStore查看），而且jms server關(guān)聯(lián)的filestore只能和它自己部署在同一managed server上。filestore只能部署到某個(gè)managed server上，其實(shí)無(wú)論是filestore，還是jdbcstore，都不能部署到cluster上。由于store不能部署到cluster上，jms server于是不能共享store(共享store會(huì)涉及到IO同步問(wèn)題、事務(wù)問(wèn)題)。當(dāng)運(yùn)行過(guò)程中，某個(gè)managed server宕機(jī)的話，在它啟動(dòng)之前，它上面filestore是不可用的，即filestore中的message不可讀，message當(dāng)然也就不能被其他客戶(hù)端消費(fèi)了。

        題外話：測(cè)試中，我讓兩個(gè)JMSServer使用不同的jdbc store, 但這兩個(gè)jdbc store指向同一數(shù)據(jù)源。雖然active changes的時(shí)候，console不會(huì)看到什么錯(cuò)誤，當(dāng)log文件中會(huì)記錄store.open()相關(guān)的錯(cuò)誤，原因就在于兩個(gè)不同的jms server使用了同一張叫做WLStore的表。第一個(gè)store用了這個(gè)表，第二個(gè)就不能使用了。重起這兩個(gè)managed server, 后啟動(dòng)的那個(gè)不會(huì)變成running mode, 它會(huì)一直處于admin狀態(tài)(jms service無(wú)法啟動(dòng))。

        2：message consume的時(shí)候，會(huì)不會(huì)做load balance？
        不會(huì)！客戶(hù)端做message send的時(shí)候，weblogic server會(huì)根據(jù)DQ的load banlance policy做load balance，即每調(diào)用一次send，都會(huì)做一次load balance，這樣消息會(huì)在物理Queue之間均分（至于哪些物理Queue會(huì)參與均分，這跟loadbalance、serverAffinity設(shè)定有關(guān)），另外，當(dāng)所有QueueMember中，只有某個(gè)Queue有consumer的時(shí)候，那么所有消息都會(huì)發(fā)送到這個(gè)QueueMember，然后被消費(fèi)。客戶(hù)端consume的時(shí)候，consumer被創(chuàng)建的時(shí)候，weblogic會(huì)分配一個(gè)物理Queue給它，即該consumer只能從這個(gè)物理Queue上接受消息。當(dāng)然consumer被重新創(chuàng)建的時(shí)候，它們會(huì)粘連到不同的物理Queue上。

        3：Consumer粘連的物理Queue所在的server宕機(jī)，不重起consumer的話，它能不能繼續(xù)收到消息？ 物理Queue所在server重啟之后，它能不能接收？
        兩種情況都不能！這種問(wèn)題典型場(chǎng)景就是message listener或message driven bean，問(wèn)題2中我們提到，consumer創(chuàng)建的時(shí)候，它會(huì)粘連到某個(gè)物理Queue上，如果物理Queue所在的managed server宕機(jī)了，Queue就不會(huì)有消息進(jìn)來(lái)（內(nèi)存中都不存在這個(gè)物理Queue），當(dāng)然這個(gè)consumer就不會(huì)收到消息了。對(duì)于第二種情況，即managed server重起之后，這個(gè)consumer如果不重起（或重建consumer）的話，它依然不會(huì)收到消息。對(duì)于這個(gè)問(wèn)題，我們首先了解一下listener的機(jī)制: listener是客戶(hù)端通過(guò)setMessageListener設(shè)定到consumer中的，這個(gè)設(shè)定會(huì)駐留在服務(wù)器端，當(dāng)服務(wù)器端發(fā)現(xiàn)對(duì)應(yīng)Queue上有消息的時(shí)候，他們通過(guò)callback機(jī)制，把消息傳遞到客戶(hù)端的listener，listener的onMessage()被觸發(fā)，執(zhí)行相應(yīng)的邏輯。因?yàn)閘istener信息是保存在服務(wù)器端的，當(dāng)managed server宕機(jī)并重起的時(shí)候，它不會(huì)recover listener信息，即即使consumer對(duì)應(yīng)的物理Queue上有消息進(jìn)來(lái)的時(shí)候，managed server上的jms server也不會(huì)通過(guò)listener callback把消息deliver給consumer，因?yàn)樗静恢肋@個(gè)consumer的存在。

        對(duì)于第二中情況，我覺(jué)得這應(yīng)該是weblogic設(shè)計(jì)的問(wèn)題，它不能讓客戶(hù)端感知到managed server的crash，客戶(hù)端如果不知道后端發(fā)生什么的話，只能傻傻的等著。其實(shí)weblogic應(yīng)該可以通過(guò)peerGone event拋出exception，客戶(hù)端可以去處理這個(gè)異常，重建consumer還是退出，由客戶(hù)端自己處理。這樣做感覺(jué)會(huì)更好些吧！

        更新！！！！！！！   
        對(duì)于最后關(guān)于異常處理的問(wèn)題，實(shí)際上weblogic（也包含其他AppServer Vendor）提供了異常監(jiān)聽(tīng)功能，這是JMS規(guī)范的要求。具體的API是connection.setExceptionListener(JMSException e), 對(duì)于這個(gè)API，客戶(hù)端程序要做的就是，提供一個(gè)實(shí)現(xiàn)JMSExceptionListener的listener類(lèi)，然后在connection創(chuàng)建完成后，將這個(gè)listener實(shí)例注入到這個(gè)新建的connection上，這樣這個(gè)連接發(fā)生JMSException的時(shí)候，ExceptionListener的onException()會(huì)被觸發(fā)，客戶(hù)可以在onException()中定義異常處理邏輯。下面是個(gè)exception listener的例子，
        對(duì)于這個(gè)listener,我們可以將底層的JMSException輸出，如果runtime過(guò)程中，對(duì)端managed server發(fā)生crash,我們可以看到如下的exception,

weblogic.jms.common.LostServerException: java.lang.Exception: weblogic.rjvm.PeerGoneException: ;
 nested exception is: 
        weblogic.utils.net.SocketResetException
        at weblogic.jms.client.JMSConnection.dispatcherPeerGone(JMSConnection.java:1348)
        at weblogic.messaging.dispatcher.DispatcherWrapperState.run(DispatcherWrapperState.java:571)
        at weblogic.messaging.dispatcher.DispatcherWrapperState.timerExpired(DispatcherWrapperState.java:496)
        at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:265)
        at weblogic.work.ExecuteRequestAdapter.execute(ExecuteRequestAdapter.java:21)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
Caused by: java.lang.Exception: weblogic.rjvm.PeerGoneException: ; nested except
ion is:
        weblogic.utils.net.SocketResetException
        at weblogic.messaging.dispatcher.DispatcherWrapperState.onDisconnect(DispatcherWrapperState.java:276)
        at weblogic.rjvm.RJVMImpl$DisconnectEventDeliverer.run(RJVMImpl.java:1603)
        ... 3 more
Caused by: weblogic.rjvm.PeerGoneException: ; nested exception is:
        weblogic.utils.net.SocketResetException
        at weblogic.rjvm.RJVMImpl.gotExceptionReceiving(RJVMImpl.java:941)
        at weblogic.rjvm.ConnectionManager.gotExceptionReceiving(ConnectionManager.java:1025)
        at weblogic.rjvm.MsgAbbrevJVMConnection.gotExceptionReceiving(MsgAbbrevJVMConnection.java:452)
        at weblogic.rjvm.t3.MuxableSocketT3.hasException(MuxableSocketT3.java:373)
        at weblogic.socket.SocketMuxer.deliverExceptionAndCleanup(SocketMuxer.java:739)
        at weblogic.socket.SocketMuxer.deliverHasException(SocketMuxer.java:692)

        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:875)

        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:792)
        at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:283)
        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
        ... 3 more
Caused by: weblogic.utils.net.SocketResetException
        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:863)

        ... 6 more