UPDATE: It doesn’t matter with topics.  Topics seem to be well-behaved, in the 
sense that topics that are auto-deleted while there are active producers are 
re-created as soon as a message is published.  This is not true with queues, 
where auto-deletion effectively breaks all current producers.  We’ve worked 
around queue auto-delete and I’ll file a bug report for it.

Thanks
John





[rg] <https://www.redpointglobal.com/>

John Lilley

Data Management Chief Architect, Redpoint Global Inc.

888 Worcester Street, Suite 200 Wellesley, MA 02482

M: +1 7209385761<tel:+1%207209385761> | 
john.lil...@redpointglobal.com<mailto:john.lil...@redpointglobal.com>
From: John Lilley <john.lil...@redpointglobal.com.INVALID>
Sent: Wednesday, November 9, 2022 10:01 AM
To: users@activemq.apache.org
Subject: Artemis: how to prevent auto-deletion of topics?

*** [Caution] This email is from an external source. Please use caution 
responding, opening attachments or clicking embedded links. ***

Greetings!

Using JMS drivers, we are finding that auto-created topics are deleted after 
all consumers go away, but then the topic is not automatically re-created when 
still-active producers post.  This seems to fail silently and is basically the 
same behavior I reported earlier with regard to auto-deleted queues.

I’ve been able to suppress auto-deletion of queues (see broker.xml below) but 
topics continue to be auto-deleted.  Do I need to create topics differently?  
Is there a broker setting I am missing?

Thanks
John

<?xml version='1.0'?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->

<configuration xmlns="urn:activemq"
               xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
               xmlns:xi=http://www.w3.org/2001/XInclude
               xsi:schemaLocation="urn:activemq 
/schema/artemis-configuration.xsd">

   <core xmlns="urn:activemq:core" 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
         xsi:schemaLocation="urn:activemq:core ">

      <name>localhost</name>


      <persistence-enabled>true</persistence-enabled>

      <!-- this could be ASYNCIO, MAPPED, NIO
           ASYNCIO: Linux Libaio
           MAPPED: mmap files
           NIO: Plain Java Files
       -->
      <journal-type>NIO</journal-type>

      <paging-directory>data/paging</paging-directory>

      <bindings-directory>data/bindings</bindings-directory>

      <journal-directory>data/journal</journal-directory>

      <large-messages-directory>data/large-messages</large-messages-directory>


      <!-- if you want to retain your journal uncomment this following 
configuration.

      This will allow your system to keep 7 days of your data, up to 10G. Tweak 
it accordingly to your use case and capacity.

      it is recommended to use a separate storage unit from the journal for 
performance considerations.

      <journal-retention-directory period="7" unit="DAYS" 
storage-limit="10G">data/retention</journal-retention-directory>

      You can also enable retention by using the argument journal-retention on 
the `artemis create` command -->



      <journal-datasync>true</journal-datasync>

      <journal-min-files>2</journal-min-files>

      <journal-pool-files>10</journal-pool-files>

      <journal-device-block-size>4096</journal-device-block-size>

      <journal-file-size>10M</journal-file-size>

      <!--
       This value was determined through a calculation.
       Your system could perform 5.32 writes per millisecond
       on the current journal configuration.
       That translates as a sync write every 188000 nanoseconds.

       Note: If you specify 0 the system will perform writes directly to the 
disk.
             We recommend this to be 0 if you are using journalType=MAPPED and 
journal-datasync=false.
      -->
      <journal-buffer-timeout>248000</journal-buffer-timeout>


      <!--
        When using ASYNCIO, this will determine the writing queue depth for 
libaio.
       -->
      <journal-max-io>1</journal-max-io>
      <!--
        You can verify the network health of a particular NIC by specifying the 
<network-check-NIC> element.
         <network-check-NIC>theNicName</network-check-NIC>
        -->

      <!--
        Use this to use an HTTP server to validate the network
         
<network-check-URL-list>http://www.apache.org</network-check-URL-list<http://www.apache.org%3c/network-check-URL-list>>
 -->

      <!-- <network-check-period>10000</network-check-period> -->
      <!-- <network-check-timeout>1000</network-check-timeout> -->

      <!-- this is a comma separated list, no spaces, just DNS or IPs
           it should accept IPV6

           Warning: Make sure you understand your network topology as this is 
meant to validate if your network is valid.
                    Using IPs that could eventually disappear or be partially 
visible may defeat the purpose.
                    You can use a list of multiple IPs, and if any successful 
ping will make the server OK to continue running -->
      <!-- <network-check-list>10.0.0.1</network-check-list> -->

      <!-- use this to customize the ping used for ipv4 addresses -->
      <!-- <network-check-ping-command>ping -c 1 -t %d 
%s</network-check-ping-command> -->

      <!-- use this to customize the ping used for ipv6 addresses -->
      <!-- <network-check-ping6-command>ping6 -c 1 
%2$s</network-check-ping6-command> -->




      <!-- how often we are looking for how many bytes are being used on the 
disk in ms -->
      <disk-scan-period>5000</disk-scan-period>

      <!-- once the disk hits this limit the system will block, or close the 
connection in certain protocols
           that won't support flow control. -->
      <max-disk-usage>90</max-disk-usage>

      <!-- should the broker detect dead locks and other issues -->
      <critical-analyzer>true</critical-analyzer>

      <critical-analyzer-timeout>120000</critical-analyzer-timeout>

      <critical-analyzer-check-period>60000</critical-analyzer-check-period>

      <critical-analyzer-policy>HALT</critical-analyzer-policy>


      <page-sync-timeout>248000</page-sync-timeout>


      <!-- the system will enter into page mode once you hit this limit. This 
is an estimate in bytes of how much the messages are using in memory

      The system will use half of the available memory (-Xmx) by default for 
the global-max-size.
      You may specify a different value here if you need to customize it to 
your needs.

      <global-max-size>100Mb</global-max-size> -->

      <!-- the maximum number of messages accepted before entering full address 
mode.
           if global-max-size is specified the full address mode will be 
specified by whatever hits it first. -->
      <global-max-messages>-1</global-max-messages>

      <acceptors>

         <!-- useEpoll means: it will use Netty epoll if you are on a system 
(Linux) that supports it -->
         <!-- amqpCredits: The number of credits sent to AMQP producers -->
         <!-- amqpLowCredits: The server will send the # credits specified at 
amqpCredits at this low mark -->
         <!-- amqpDuplicateDetection: If you are not using duplicate detection, 
set this to false
                                      as duplicate detection requires 
applicationProperties to be parsed on the server. -->
         <!-- amqpMinLargeMessageSize: Determines how many bytes are considered 
large, so we start using files to hold their data.
                                       default: 102400, -1 would mean to 
disable large mesasge control -->

         <!-- Note: If an acceptor needs to be compatible with HornetQ and/or 
Artemis 1.x clients add
                    "anycastPrefix=jms.queue.;multicastPrefix=jms.topic." to 
the acceptor url.
                    See https://issues.apache.org/jira/browse/ARTEMIS-1644 for 
more information. -->


         <!-- Acceptor for every supported protocol -->
         <acceptor 
name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>

         <!-- AMQP Acceptor.  Listens on default AMQP port for AMQP traffic.-->
         <acceptor 
name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=true</acceptor>

         <!-- STOMP Acceptor. -->
         <acceptor 
name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor>

         <!-- HornetQ Compatibility Acceptor.  Enables HornetQ Core and STOMP 
for legacy HornetQ clients. -->
         <acceptor 
name="hornetq">tcp://0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor>

         <!-- MQTT Acceptor -->
         <acceptor 
name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true</acceptor>

      </acceptors>


      <security-settings>
         <security-setting match="#">
            <permission type="createNonDurableQueue" roles="amq"/>
            <permission type="deleteNonDurableQueue" roles="amq"/>
            <permission type="createDurableQueue" roles="amq"/>
            <permission type="deleteDurableQueue" roles="amq"/>
            <permission type="createAddress" roles="amq"/>
            <permission type="deleteAddress" roles="amq"/>
            <permission type="consume" roles="amq"/>
            <permission type="browse" roles="amq"/>
            <permission type="send" roles="amq"/>
            <!-- we need this otherwise ./artemis data imp wouldn't work -->
            <permission type="manage" roles="amq"/>
         </security-setting>
      </security-settings>

      <address-settings>
         <!-- if you define auto-create on certain queues, management has to be 
auto-create -->
         <address-setting 
match="//activemq.management#"><https://linkprotect.cudasvc.com/url?a=https%3a%2f%2f%2f%2factivemq.management%23%26quot%3b%26gt%3b&c=E,1,v5nCB89PDLV5Uy_Lge6662h3VYBTS3Xz0_q5-hbawa4Dl2MFzrr5_ioa2xvrG5D_5kT9eklwHdc_2Amw7YbnQstoMhfRPfhVfJEZMOuAm-mL6V57zoA,&typo=1&ancr_add=1>
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            
<message-counter-history-day-limit>10</message-counter-history-day-limit>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
         </address-setting>
                                <!--
                                                See 
https://access.redhat.com/documentation/en-us/red_hat_amq/7.0/html/using_amq_broker/addresses
                                                The order of rules is not 
important, only the match specificity.
                                -->
         <address-setting match="rpdm.#">
                                                <!-- RPDM queues do not 
auto-delete, because a bug in Artemis prevents auto-deleted queues from being 
re-created -->
                                                
<auto-delete-queues>false</auto-delete-queues>
                                                
<auto-delete-addresses>false</auto-delete-addresses>
                                                
<auto-delete-jms-topics>false</auto-delete-jms-topics>
         </address-setting>
         <!--default for catch all-->
         <address-setting match="#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <!-- if max-size-bytes and max-size-messages were both enabled, the 
system will enter into paging
                 based on the first attribute to hits the maximum value -->
            <!-- limit for the address in bytes, -1 means unlimited -->
            <max-size-bytes>-1</max-size-bytes>
            <!-- limit for the address in messages, -1 means unlimited -->
            <max-size-messages>-1</max-size-messages>
                                                
<auto-delete-queues>false</auto-delete-queues>
                                                
<auto-delete-addresses>false</auto-delete-addresses>
                                                
<auto-delete-jms-topics>false</auto-delete-jms-topics>
         </address-setting>
      </address-settings>

      <addresses>
         <address name="DLQ">
            <anycast>
               <queue name="DLQ" />
            </anycast>
         </address>
         <address name="ExpiryQueue">
            <anycast>
               <queue name="ExpiryQueue" />
            </anycast>
         </address>

      </addresses>


      <!-- Uncomment the following if you want to use the Standard 
LoggingActiveMQServerPlugin pluging to log in events
      <broker-plugins>
         <broker-plugin 
class-name="org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin">
            <property key="LOG_ALL_EVENTS" value="true"/>
            <property key="LOG_CONNECTION_EVENTS" value="true"/>
            <property key="LOG_SESSION_EVENTS" value="true"/>
            <property key="LOG_CONSUMER_EVENTS" value="true"/>
            <property key="LOG_DELIVERING_EVENTS" value="true"/>
            <property key="LOG_SENDING_EVENTS" value="true"/>
            <property key="LOG_INTERNAL_EVENTS" value="true"/>
         </broker-plugin>
      </broker-plugins>
      -->

   </core>
</configuration>


[rg]<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,HBg1KuTEI75xpGiPCUFnlM4WHU-2LbipeP-GKaKPqvSfIwKucMgO18UCcd3zU-DwNX6ySiINnjKPdt8EOc3svQh17-91VqX6qfXPQWKw1BhXG89-cA,,&typo=1>

John Lilley

Data Management Chief Architect, Redpoint Global Inc.

888 Worcester Street, Suite 200 Wellesley, MA 02482

M: +1 7209385761<tel:+1%207209385761> | 
john.lil...@redpointglobal.com<mailto:john.lil...@redpointglobal.com>

PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is confidential 
and is intended solely for the use of the individual(s) to whom it is 
addressed. If you believe you received this e-mail in error, please notify the 
sender immediately, delete the e-mail from your computer and do not copy, print 
or disclose it to anyone else. If you properly received this e-mail as a 
customer, partner or vendor of Redpoint, you should maintain its contents in 
confidence subject to the terms and conditions of your agreement(s) with 
Redpoint.

PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is confidential 
and is intended solely for the use of the individual(s) to whom it is 
addressed. If you believe you received this e-mail in error, please notify the 
sender immediately, delete the e-mail from your computer and do not copy, print 
or disclose it to anyone else. If you properly received this e-mail as a 
customer, partner or vendor of Redpoint, you should maintain its contents in 
confidence subject to the terms and conditions of your agreement(s) with 
Redpoint.

Reply via email to