1：在weblogic cluster環境中，配置一個Distributed Queue, 它的QueueMember分布于cluster中不同managed server上的JMS Server上。JMS采用filestore方式存儲消息。如果運行過程中，某一個managed server發生宕機的話，它的JMS Server上的消息在重起前，能不能被客戶端consume掉？

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

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

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

        3：Consumer粘連的物理Queue所在的server宕機，不重起consumer的話，它能不能繼續收到消息？ 物理Queue所在server重啟之后，它能不能接收？
        兩種情況都不能！這種問題典型場景就是message listener或message driven bean，問題2中我們提到，consumer創建的時候，它會粘連到某個物理Queue上，如果物理Queue所在的managed server宕機了，Queue就不會有消息進來（內存中都不存在這個物理Queue），當然這個consumer就不會收到消息了。對于第二種情況，即managed server重起之后，這個consumer如果不重起（或重建consumer）的話，它依然不會收到消息。對于這個問題，我們首先了解一下listener的機制: listener是客戶端通過setMessageListener設定到consumer中的，這個設定會駐留在服務器端，當服務器端發現對應Queue上有消息的時候，他們通過callback機制，把消息傳遞到客戶端的listener，listener的onMessage()被觸發，執行相應的邏輯。因為listener信息是保存在服務器端的，當managed server宕機并重起的時候，它不會recover listener信息，即即使consumer對應的物理Queue上有消息進來的時候，managed server上的jms server也不會通過listener callback把消息deliver給consumer，因為它根本不知道這個consumer的存在。

        對于第二中情況，我覺得這應該是weblogic設計的問題，它不能讓客戶端感知到managed server的crash，客戶端如果不知道后端發生什么的話，只能傻傻的等著。其實weblogic應該可以通過peerGone event拋出exception，客戶端可以去處理這個異常，重建consumer還是退出，由客戶端自己處理。這樣做感覺會更好些吧！

        更新！！！！！！！   
        對于最后關于異常處理的問題，實際上weblogic（也包含其他AppServer Vendor）提供了異常監聽功能，這是JMS規范的要求。具體的API是connection.setExceptionListener(JMSException e), 對于這個API，客戶端程序要做的就是，提供一個實現JMSExceptionListener的listener類，然后在connection創建完成后，將這個listener實例注入到這個新建的connection上，這樣這個連接發生JMSException的時候，ExceptionListener的onException()會被觸發，客戶可以在onException()中定義異常處理邏輯。下面是個exception listener的例子，
        對于這個listener,我們可以將底層的JMSException輸出，如果runtime過程中，對端managed server發生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