[jboss-cvs] JBoss Messaging SVN: r7881 - in branches/JBMESSAGING-1742/src/main/org/jboss: messaging/core/impl/postoffice and 1 other directory.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Wed Oct 28 23:15:37 EDT 2009


Author: gaohoward
Date: 2009-10-28 23:15:36 -0400 (Wed, 28 Oct 2009)
New Revision: 7881

Modified:
   branches/JBMESSAGING-1742/src/main/org/jboss/jms/server/destination/TopicService.java
   branches/JBMESSAGING-1742/src/main/org/jboss/messaging/core/impl/postoffice/MessagingPostOffice.java
Log:
format


Modified: branches/JBMESSAGING-1742/src/main/org/jboss/jms/server/destination/TopicService.java
===================================================================
--- branches/JBMESSAGING-1742/src/main/org/jboss/jms/server/destination/TopicService.java	2009-10-28 16:28:08 UTC (rev 7880)
+++ branches/JBMESSAGING-1742/src/main/org/jboss/jms/server/destination/TopicService.java	2009-10-29 03:15:36 UTC (rev 7881)
@@ -27,6 +27,7 @@
  * @author <a href="mailto:tim.fox at jboss.com">Tim Fox</a>
  * @author <a href="mailto:alex.fu at novell.com">Alex Fu</a>
  * @author <a href="mailto:juha at jboss.org">Juha Lindfors</a>
+ * @author <a href="mailto:hgao at redhat.com">Howard Gao</a>
  *
  * @version <tt>$Revision$</tt>
  *
@@ -92,52 +93,52 @@
             //TODO We need to set the paging params this way since the post office doesn't store them
             //instead we should never create queues inside the postoffice - only do it at deploy time
             
+            //if the queue is redeployed as clustered from a non-clustered state, the queue is already activated.
             if (!queue.isActive())
             {
-            
-            queue.setPagingParams(destination.getFullSize(), destination.getPageSize(), destination.getDownCacheSize());
-            
-            queue.load();
-                        
-            queue.activate();  
-               
-            //Must be done after load
-            queue.setMaxSize(destination.getMaxSize());  
-            
-            //Create a counter
-            String counterName = SUBSCRIPTION_MESSAGECOUNTER_PREFIX + queue.getName();
-            
-            String subName = MessageQueueNameHelper.createHelper(queue.getName()).getSubName();
-            
-            int dayLimitToUse = destination.getMessageCounterHistoryDayLimit();
-            if (dayLimitToUse == -1)
-            {
-               //Use override on server peer
-               dayLimitToUse = serverPeer.getDefaultMessageCounterHistoryDayLimit();
+               queue.setPagingParams(destination.getFullSize(),
+                                     destination.getPageSize(),
+                                     destination.getDownCacheSize());
+
+               queue.load();
+
+               queue.activate();
+
+               // Must be done after load
+               queue.setMaxSize(destination.getMaxSize());
+
+               // Create a counter
+               String counterName = SUBSCRIPTION_MESSAGECOUNTER_PREFIX + queue.getName();
+
+               String subName = MessageQueueNameHelper.createHelper(queue.getName()).getSubName();
+
+               int dayLimitToUse = destination.getMessageCounterHistoryDayLimit();
+               if (dayLimitToUse == -1)
+               {
+                  // Use override on server peer
+                  dayLimitToUse = serverPeer.getDefaultMessageCounterHistoryDayLimit();
+               }
+
+               MessageCounter counter = new MessageCounter(counterName, subName, queue, true, true, dayLimitToUse);
+
+               serverPeer.getMessageCounterManager().registerMessageCounter(counterName, counter);
+
+               // Now we need to trigger a delivery - this is because message suckers might have
+               // been create *before* the queue was deployed - this is because message suckers can be
+               // created when the clusterpullconnectionfactory deploy is detected which then causes
+               // the clusterconnectionmanager to inspect the bindings for queues to create suckers
+               // to - but these bindings will exist before the queue or topic is deployed and before
+               // it has had its messages loaded
+               // Therefore we need to trigger a delivery now so remote suckers get messages
+               // See http://jira.jboss.org/jira/browse/JBMESSAGING-1136
+               // For JBM we should remove the distinction between activation and deployment to
+               // remove these annoyances and edge cases.
+               // The post office should load(=deploy) all bindings on startup including loading their
+               // state before adding the binding - there should be no separate deployment stage
+               // If the queue can be undeployed there should be a separate flag for this on the
+               // binding
+               queue.deliver();
             }
-            
-            MessageCounter counter =
-               new MessageCounter(counterName, subName, queue, true, true,
-                                  dayLimitToUse);
-            
-            serverPeer.getMessageCounterManager().registerMessageCounter(counterName, counter);    
-            
-            //Now we need to trigger a delivery - this is because message suckers might have
-            //been create *before* the queue was deployed - this is because message suckers can be
-            //created when the clusterpullconnectionfactory deploy is detected which then causes
-            //the clusterconnectionmanager to inspect the bindings for queues to create suckers
-            //to - but these bindings will exist before the queue or topic is deployed and before
-            //it has had its messages loaded
-            //Therefore we need to trigger a delivery now so remote suckers get messages
-            //See http://jira.jboss.org/jira/browse/JBMESSAGING-1136
-            //For JBM we should remove the distinction between activation and deployment to
-            //remove these annoyances and edge cases.
-            //The post office should load(=deploy) all bindings on startup including loading their
-            //state before adding the binding - there should be no separate deployment stage
-            //If the queue can be undeployed there should be a separate flag for this on the
-            //binding
-            queue.deliver();
-            }
          }
 
          serverPeer.getDestinationManager().registerDestination(destination);

Modified: branches/JBMESSAGING-1742/src/main/org/jboss/messaging/core/impl/postoffice/MessagingPostOffice.java
===================================================================
--- branches/JBMESSAGING-1742/src/main/org/jboss/messaging/core/impl/postoffice/MessagingPostOffice.java	2009-10-28 16:28:08 UTC (rev 7880)
+++ branches/JBMESSAGING-1742/src/main/org/jboss/messaging/core/impl/postoffice/MessagingPostOffice.java	2009-10-29 03:15:36 UTC (rev 7881)
@@ -95,6 +95,7 @@
  * @author <a href="mailto:tim.fox at jboss.com">Tim Fox</a>
  * @author <a href="mailto:ovidiu at feodorov.com">Ovidiu Feodorov</a>
  * @author <a href="mailto:clebert.suconic at jboss.com">Clebert Suconic</a>
+ * @author <a href="mailto:hgao at redhat.com">Howard Gao</a>
  * @version <tt>$Revision: 2782 $</tt>
  *
  * $Id: DefaultClusteredPostOffice.java 2782 2007-06-14 12:16:17Z timfox $




More information about the jboss-cvs-commits mailing list