gemmellr commented on code in PR #4101:
URL: https://github.com/apache/activemq-artemis/pull/4101#discussion_r896922898


##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java:
##########
@@ -3101,29 +3108,21 @@ protected void removeMessageReference(ConsumerHolder<? 
extends Consumer> holder,
       refRemoved(ref);
    }
 
-   private void checkDepage(boolean noWait) {
-      if (pageIterator != null && pageSubscription.isPaging() && 
!depagePending && needsDepage() && (noWait ? pageIterator.tryNext() > 0 : 
pageIterator.hasNext())) {
+   private void checkDepage() {
+      if (pageIterator != null && pageSubscription.isPaging() && 
!depagePending && needsDepage() && pageIterator.tryNext() != 
PageIterator.NextResult.noElements) {
          scheduleDepage(false);
       }
    }
 
    /**
-    * This is a common check we do before scheduling depaging.. or while 
depaging.
-    * Before scheduling a depage runnable we verify if it fits / needs 
depaging.
-    * We also check for while needsDepage While depaging.
-    * This is just to avoid a copy & paste dependency
+    *
+    * This is a check on page sizing.
     *
     * @return
     */
    private boolean needsDepage() {
-      return queueMemorySize.get() < 
pageSubscription.getPagingStore().getMaxSize() &&
-         /**
-          * In most cases, one depage round following by at most 
MAX_SCHEDULED_RUNNERS deliver round,
-          * thus we just need to read MAX_DELIVERIES_IN_LOOP * 
MAX_SCHEDULED_RUNNERS messages. If we read too much, the message reference
-          * maybe discarded by gc collector in response to memory demand and 
we need to read it again at
-          * a great cost when delivering.
-          */
-         intermediateMessageReferences.size() + messageReferences.size() < 
MAX_DEPAGE_NUM;
+      return queueMemorySize.getSize() < 
pageSubscription.getPagingStore().getMaxPageReadBytes() &&
+             queueMemorySize.getElements() < 
pageSubscription.getPagingStore().getMaxPageReadMessages();

Review Comment:
   Maybe it is similar...doesnt mean it is right? How much it can read in one 
go, seems largely seperate from when it can read and should/shouldnt still be 
paging and continuing to read in. Keeping the queue in paging when it could 
potentially otherwise exit it seems weird.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to