[ 
https://issues.apache.org/jira/browse/ARTEMIS-4973?focusedWorklogId=928949&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-928949
 ]

ASF GitHub Bot logged work on ARTEMIS-4973:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 06/Aug/24 15:44
            Start Date: 06/Aug/24 15:44
    Worklog Time Spent: 10m 
      Work Description: gemmellr commented on code in PR #5128:
URL: https://github.com/apache/activemq-artemis/pull/5128#discussion_r1705762102


##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java:
##########
@@ -228,11 +228,34 @@ private void configureSizeMetric() {
       size.setMax(maxSize, maxSize, maxMessages, maxMessages);
    }
 
+   private boolean validateNewSettings(final AddressSettings addressSettings) {
+
+      Long newPageLimitBytes = addressSettings.getPageLimitBytes();
+
+      if (newPageLimitBytes != null && newPageLimitBytes.longValue() < 0) {
+         newPageLimitBytes = null;
+      }
+      int newPageSize = 
storageManager.getAllowedPageSize(addressSettings.getPageSizeBytes());
+      if (newPageLimitBytes != null && newPageSize > 0) {
+         long newEstimatedMaxPages = newPageLimitBytes / newPageSize;
+         if (this.numberOfPages > newEstimatedMaxPages) {
+            ActiveMQServerLogger.LOGGER.pageSettingsFailedApply(storeName, 
addressSettings, "estimated max pages " + newEstimatedMaxPages + " is less than 
current number of pages " + this.numberOfPages);
+            return false;
+         }
+      }
+      return true;
+   }
+
    /**
     * @param addressSettings
     */
    @Override
    public void applySetting(final AddressSettings addressSettings) {
+
+      if (!validateNewSettings(addressSettings)) {
+         return;
+      }

Review Comment:
   The limit > page size requirement would remove any issue with e.g 0 page 
files at the low end. Though essentially the same thing occurs with `n` files 
at the top end, unless the limit is always a multiple of the page size.
   
   The main issue here is that the limit is tracked by a file count based on 
current limit/size, and so any existing 'old' files of the 'wrong' size can 
over/underutilise the effective limit if you adjust the page size with 
outstanding page files. There doesnt seem to be a way around that without 
byte-level tracking, which is likely to be awkward.
   
   I think we should perhaps just better document that the effective limit is a 
file count based on current limit/page size, and so changing page size whilst 
there are existing outstanding pages can lead to such behaviour and if you want 
to influence things to e.g unblock earlier it might be necessary to adjust the 
limit at the same time whilst those old files are present.





Issue Time Tracking
-------------------

    Worklog Id:     (was: 928949)
    Time Spent: 1h 50m  (was: 1h 40m)

> pageSizeBytes/pageLimitBytes combination can cause Address full
> ---------------------------------------------------------------
>
>                 Key: ARTEMIS-4973
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4973
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 2.36.0
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Major
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> There is an edge case where adjusting pageSizeBytes can cause "Address is 
> full" errors, even though the address is not full.
> Do we need to enforce that pageSizeBytes <= pageLimitBytes?
> Reproducer steps:
> Step 1: configure pageSizeBytes == pageLimitBytes == 1mb:
> $ cat my.broker.properties 
> addressSettings."FOO".pageSizeBytes=1048576
> addressSettings."FOO".pageLimitBytes=1048576
> addressSettings."FOO".maxSizeBytes=1048576
> addressSettings."FOO".pageFullMessagePolicy=FAIL
> addressConfigurations."FOO".routingTypes=MULTICAST
> addressConfigurations."FOO".queueConfigs."FOO".name=FOO
> addressConfigurations."FOO".queueConfigs."FOO".address=FOO
> addressConfigurations."FOO".queueConfigs."FOO".routingType=MULTICAST
> Step 2: run broker
> bin/artemis run --properties my.broker.properties
> Step 3: produce 15 messages
> $ bin/artemis producer --user admin --password admin --destination 
> topic://FOO --message-count 15 --message-size 100000 --protocol amqp
> Step 4: observe paging started on the destination (but the page size is 
> 328kb, can hold more messages)
> INFO  [org.apache.activemq.artemis.core.server] AMQ222038: Starting paging on 
> address 'FOO'; size=1107003 bytes (11 messages); maxSize=1048576 bytes (-1 
> messages); globalSize=1107003 bytes (11 messages); globalMaxSize=1073741824 
> bytes (-1 messages);
> Step 5: stop broker, increase page size
>  cat my.broker.properties 
> addressSettings."FOO".pageSizeBytes=4048576
> ...
> Step 6: run broker, observe logs show paging warning
> 2024-06-25 15:23:47,135 WARN  [org.apache.activemq.artemis.core.server] 
> AMQ224123: Address FOO has more pages than allowed. System currently has 1 
> pages, while the estimated max number of pages is 0 based on the 
> page-limit-bytes (1048576) / page-size (4048576)
> Step 7: try to produce a message, address full
> WARN  [org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback] 
> AMQ229102: Address "FOO" is full.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact


Reply via email to