Hello team.
Could you please tell me if there is a way to auto-create a last-value
queue by passing some config via JMS API from Java app? I have tried
multiple options but none of them work for me.
In my case I want to have this config only without configuring a separate
address setting for last-value queue in my broker xml:
* <address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<address-full-policy>PAGE</address-full-policy>
<auto-create-queues>true</auto-create-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-delete-queues>true</auto-delete-queues>
<auto-delete-addresses>true</auto-delete-addresses>
<auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
<auto-delete-queues-delay>30000</auto-delete-queues-delay>
<auto-delete-addresses-delay>60000</auto-delete-addresses-delay>
<!-- The size of each page file -->
<page-size-bytes>10M</page-size-bytes> <!-- When we start
applying the address-full-policy, e.g paging --> <!-- Both are
disabled by default, which means we will use the
global-max-size/global-max-messages -->
<max-size-bytes>-1</max-size-bytes>
<max-size-messages>-1</max-size-messages> <!-- When we read
from paging into queues (memory) -->
<max-read-page-messages>-1</max-read-page-messages>
<max-read-page-bytes>20M</max-read-page-bytes> <!-- Limit on
paging capacity before starting to throw errors -->
<page-limit-bytes>-1</page-limit-bytes>
<page-limit-messages>-1</page-limit-messages> </address-setting>*
Thanks! Best regards.
ср, 29 окт. 2025 г. в 19:07, Illia <[email protected]>:
> Hello guys.
> Seems that the issue was with tls connection. The behavior is weird
> because my consumer successfully connected to an ssl configured active node
> via non-tls but failed to connect to a backup node.
> After I correctly configured the tls connection from application side,
> everything started to work properly.
>
> Thanks! Best regards.
>
>
> ср, 29 окт. 2025 г. в 17:54, Justin Bertram <[email protected]>:
>
>> Are you using a shared-store HA configuration on the broker? If so, how
>> did
>> you stop the broker? Based on the error message it looks like you shut the
>> broker down "gracefully" (e.g. using CTRL-C).
>>
>>
>> Justin
>>
>> On Tue, Oct 28, 2025 at 8:18 PM Illia <[email protected]> wrote:
>>
>> > Hi Justin.
>> > Could you please help me with one more thing?
>> > I am using the library that you mentioned but it seems that my consumer
>> > doesn't automatically reconnect to a backup node on failover. Here is my
>> > connection factory configuration:
>> >
>> > @Bean
>> > public ConnectionFactory artemisConnectionFactory() {
>> > // failover URL with two cluster nodes
>> > String brokerUrl =
>> > "(tcp://artemis-node-a:61616,tcp://artemis-node-b:61616)?ha=true";
>> >
>> > // create the factory
>> > ActiveMQConnectionFactory factory = new
>> > ActiveMQConnectionFactory(brokerUrl);
>> >
>> > factory.setUser("artemis");
>> > factory.setPassword("artemis");
>> >
>> > factory.setRetryInterval(1000);
>> > factory.setRetryIntervalMultiplier(1.5);
>> > factory.setMaxRetryInterval(10000);
>> > factory.setReconnectAttempts(-1);
>> > return factory;
>> > }
>> >
>> >
>> > I also tried to use spring library
>> > *org.springframework.boot:spring-boot-starter-activemq* (which uses
>> > activemq-client underneath) with next configuration:
>> >
>> > @Bean
>> > public ConnectionFactory connectionFactory() {
>> > ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory();
>> >
>> > // Failover broker URL (auto-reconnect)
>> >
>> >
>> factory.setBrokerURL("failover:(tcp://artemis-node-a:61616,tcp://artemis-node-b:61616)?randomize=false");
>> >
>> > factory.setUserName("artemis");
>> > factory.setPassword("artemis");
>> >
>> > return factory;
>> > }
>> >
>> >
>> > and the consumer successfully reconnects.
>> >
>> > Could you please let me know what is the reason why the consumer doesn't
>> > automatically reconnect on failover with artemis-jakarta-client library?
>> >
>> > Thanks! Best regards.
>> >
>> >
>> > пн, 27 окт. 2025 г. в 20:52, Justin Bertram <[email protected]>:
>> >
>> > > ActiveMQ Artemis provides the necessary JMS client implementation
>> > > libraries. If you're using a relatively recent version of Spring this
>> is
>> > > the depenency you need to add in your Maven pom.xml:
>> > >
>> > > <dependency>
>> > > <groupId>org.apache.activemq</groupId>
>> > > <artifactId>artemis-jakarta-client</artifactId>
>> > > <version>2.43.0</version> <!-- currently the latest release -->
>> > > </dependency>
>> > >
>> > > More details are available in the documentation [1].
>> > >
>> > >
>> > > Justin
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> https://activemq.apache.org/components/artemis/documentation/latest/client-classpath.html#the-client-classpath
>> > >
>> > > On Mon, Oct 27, 2025 at 12:10 PM Illia <[email protected]>
>> wrote:
>> > >
>> > > > Hi Justin.
>> > > > Thanks for your response.
>> > > >
>> > > > There is no specific reason why we decided to use Core API.
>> > > >
>> > > > Could you please suggest JMS API libraries that we can integrate to
>> our
>> > > app
>> > > > instead of Core API?
>> > > >
>> > > > Thanks! Best regards.
>> > > >
>> > > > пн, 27 окт. 2025 г. в 18:02, Justin Bertram <[email protected]>:
>> > > >
>> > > > > You're using the Core API in your application. This is a low-level
>> > API
>> > > > > meant for applications that want to strictly manage their own
>> > > resources.
>> > > > I
>> > > > > think this is the wrong API for your use-case.
>> > > > >
>> > > > > You're managing the creation of the queue(s) yourself, but you
>> don't
>> > > want
>> > > > > to your application to manage the deletion of the queues as it
>> would
>> > > add
>> > > > > unwanted complexity. Therefore, the broker is managing the
>> deletion
>> > of
>> > > > the
>> > > > > queue(s). However, the broker is deleting them in a manner that's
>> > > causing
>> > > > > problems for your application since your application is apparently
>> > > > > expecting the queue to be there when it isn't.
>> > > > >
>> > > > > I recommend you simply use the JMS API and let the broker handle
>> both
>> > > the
>> > > > > creation & deletion of the resources as needed. You're already
>> using
>> > > > Spring
>> > > > > which has strong integration with JMS so you could likely simplify
>> > your
>> > > > > application a fair bit by switching.
>> > > > >
>> > > > > Is there a specific reason you're using the Core API rather than
>> the
>> > > JMS
>> > > > > API?
>> > > > >
>> > > > >
>> > > > > Justin
>> > > > >
>> > > > > On Fri, Oct 24, 2025 at 1:29 PM Illia <[email protected]>
>> > wrote:
>> > > > >
>> > > > > > Hi Justin.
>> > > > > > I have some kind of video conferencing app where I need to
>> create
>> > > many
>> > > > > > addresses/queues for each session/call.
>> > > > > > Setting the auto delete flag to false means that I will need to
>> > clean
>> > > > > > unused addresses and queues manually with the help of a
>> scheduler
>> > > which
>> > > > > > complicates the solution.
>> > > > > >
>> > > > > > Is there any way to start taking into consideration auto delete
>> > > delay?
>> > > > So
>> > > > > > when failover is done, the queue is not deleted automatically
>> but
>> > > only
>> > > > > > after a specified time?
>> > > > > >
>> > > > > > Thanks! Best regards.
>> > > > > >
>> > > > > > чт, 23 окт. 2025 г. в 17:51, Justin Bertram <
>> [email protected]>:
>> > > > > >
>> > > > > > > I tracked this behavior down to ARTEMIS-3525 [1]. On start the
>> > > broker
>> > > > > > will
>> > > > > > > explicitly delete empty queues that are to be auto-deleted.
>> > > > > > >
>> > > > > > > That said, if auto-creation is enabled and you're using a
>> > protocol
>> > > > > where
>> > > > > > > auto-creation is supported then the queue should be re-created
>> > > when a
>> > > > > > > message is sent to it or a consumer is created on it.
>> > > > > > >
>> > > > > > > Is there a particular reason that you don't want to delete
>> queues
>> > > > > > > immediately after failover when the queue auto-delete flag is
>> set
>> > > to
>> > > > > > true?
>> > > > > > > Have you considered setting the auto-delete flag to false so
>> that
>> > > > this
>> > > > > > > doesn't happen?
>> > > > > > >
>> > > > > > >
>> > > > > > > Justin
>> > > > > > >
>> > > > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-3525
>> > > > > > >
>> > > > > > > On Wed, Oct 22, 2025 at 8:10 PM Illia <
>> [email protected]>
>> > > > wrote:
>> > > > > > >
>> > > > > > > > Hi Justin.
>> > > > > > > > I have prepared a Java app for you. The link -
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://drive.google.com/file/d/1aLExH0nWTtWvdjFTw6KJIdid5wTXlJ9J/view?usp=sharing
>> > > > > > > > Steps to reproduce the issue:
>> > > > > > > > 1. Build Java app with *./mvnw clean package*
>> > > > > > > > 2. Start docker compose *docker compose up* which will start
>> > java
>> > > > > > client
>> > > > > > > > and 2 artemis nodes in replication mode (active and backup).
>> > > > > > > > 3. After the application is started, an address with the
>> name
>> > > > > > > > "new-address" and a queue with the name "new-queue" are
>> > created.
>> > > > > > > > 4. Stop active node with *docker stop artemis-node-a*
>> > > > > > > > 5. Go to *http://localhost:8162/console/artemis
>> > > > > > > > <http://localhost:8162/console/artemis> *where you can
>> observe
>> > > > that
>> > > > > > > > address was replicated and queue was not
>> > > > > > > > [image: image.png]
>> > > > > > > > [image: image.png]
>> > > > > > > >
>> > > > > > > > 6. The reason is that my queue is configured with
>> autodelete:
>> > > > > > > > [image: image.png]
>> > > > > > > > 7. If you remove autoDelete and autoDeleteDeley lines and
>> > repeat
>> > > > > > > > everything from the beginning, you will notice that both
>> > address
>> > > > and
>> > > > > > > queue
>> > > > > > > > are successfully replicated.
>> > > > > > > >
>> > > > > > > > My goal is to not delete queues immediately after failover
>> when
>> > > the
>> > > > > > queue
>> > > > > > > > auto delete flag is set to true. Is it even possible?
>> > > > > > > >
>> > > > > > > > Thanks! Best regards.
>> > > > > > > >
>> > > > > > > > ср, 22 окт. 2025 г. в 06:07, Justin Bertram <
>> > [email protected]
>> > > >:
>> > > > > > > >
>> > > > > > > >> Nothing in the address-settings seems problematic. Can you
>> > work
>> > > up
>> > > > > > some
>> > > > > > > >> instructions or ideally an automated reproducer so that I
>> can
>> > > > > observe
>> > > > > > > the
>> > > > > > > >> same behavior that you described?
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >> Justin
>> > > > > > > >>
>> > > > > > > >> On Tue, Oct 21, 2025 at 4:52 PM Illia <
>> > [email protected]>
>> > > > > > wrote:
>> > > > > > > >>
>> > > > > > > >> > Hi Justin.
>> > > > > > > >> > This my settings in broker.xml:
>> > > > > > > >> >
>> > > > > > > >> > <address-setting match="#">
>> > > > > > > >> > <dead-letter-address>DLQ</dead-letter-address>
>> > > > > > > >> > <expiry-address>ExpiryQueue</expiry-address>
>> > > > > > > >> > <redelivery-delay>0</redelivery-delay>
>> > > > > > > >> >
>> > > > > > > >> >
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > >
>> > > > >
>> > >
>> <message-counter-history-day-limit>10</message-counter-history-day-limit>
>> > > > > > > >> > <address-full-policy>PAGE</address-full-policy>
>> > > > > > > >> > <auto-create-queues>true</auto-create-queues>
>> > > > > > > >> > <auto-create-addresses>true</auto-create-addresses>
>> > > > > > > >> > <auto-delete-queues>false</auto-delete-queues>
>> > > > > > > >> > <auto-delete-addresses>false</auto-delete-addresses>
>> > > > > > > >> >
>> > > > > > > >> > <!-- The size of each page file -->
>> > > > > > > >> > <page-size-bytes>10M</page-size-bytes>
>> > > > > > > >> >
>> > > > > > > >> > <!-- When we start applying the address-full-policy,
>> e.g
>> > > > > paging
>> > > > > > > -->
>> > > > > > > >> > <!-- Both are disabled by default, which means we
>> will
>> > use
>> > > > the
>> > > > > > > >> > global-max-size/global-max-messages -->
>> > > > > > > >> > <max-size-bytes>-1</max-size-bytes>
>> > > > > > > >> > <max-size-messages>-1</max-size-messages>
>> > > > > > > >> >
>> > > > > > > >> > <!-- When we read from paging into queues (memory)
>> -->
>> > > > > > > >> >
>> > > > > > > >> > <max-read-page-messages>-1</max-read-page-messages>
>> > > > > > > >> > <max-read-page-bytes>20M</max-read-page-bytes>
>> > > > > > > >> >
>> > > > > > > >> > <!-- Limit on paging capacity before starting to
>> throw
>> > > > errors
>> > > > > > -->
>> > > > > > > >> >
>> > > > > > > >> > <page-limit-bytes>-1</page-limit-bytes>
>> > > > > > > >> > <page-limit-messages>-1</page-limit-messages>
>> > > > > > > >> > </address-setting>
>> > > > > > > >> >
>> > > > > > > >> >
>> > > > > > > >> > ср, 22 окт. 2025 г. в 00:15, Justin Bertram <
>> > > > [email protected]
>> > > > > >:
>> > > > > > > >> >
>> > > > > > > >> > > Can you provide the address settings that correspond to
>> > this
>> > > > > > queue?
>> > > > > > > >> > >
>> > > > > > > >> > > For what it's worth, setting the auto-delete
>> message-count
>> > > on
>> > > > > the
>> > > > > > > >> queue
>> > > > > > > >> > to
>> > > > > > > >> > > -1 is not normal as that means the broker will delete
>> the
>> > > > queue
>> > > > > > > >> > regardless
>> > > > > > > >> > > of the number of messages it contains. It might make
>> sense
>> > > > > > depending
>> > > > > > > >> on
>> > > > > > > >> > > your use-case, but folks typically don't want to delete
>> > > their
>> > > > > > > messages
>> > > > > > > >> > > automatically.
>> > > > > > > >> > >
>> > > > > > > >> > >
>> > > > > > > >> > > Justin
>> > > > > > > >> > >
>> > > > > > > >> > > On Tue, Oct 21, 2025 at 3:28 PM Illia <
>> > > > [email protected]>
>> > > > > > > >> wrote:
>> > > > > > > >> > >
>> > > > > > > >> > > > Hi team. Could you please help me with the next
>> issue.
>> > > > > > > >> > > >
>> > > > > > > >> > > > My cluster consists of two nodes with replication
>> mode
>> > > (live
>> > > > > and
>> > > > > > > >> > backup)
>> > > > > > > >> > > > that are configured to auto delete queues.
>> > > > > > > >> > > >
>> > > > > > > >> > > > When my active node fails, I see that only addresses
>> are
>> > > > > > > replicated
>> > > > > > > >> to
>> > > > > > > >> > > the
>> > > > > > > >> > > > backup node but not queues. Seems that the reason is
>> > that
>> > > my
>> > > > > > > queues
>> > > > > > > >> are
>> > > > > > > >> > > > configured for auto delete. Queue replication works
>> fine
>> > > > > without
>> > > > > > > the
>> > > > > > > >> > auto
>> > > > > > > >> > > > delete flag. I tried to set up an auto delete delay
>> but
>> > it
>> > > > > seems
>> > > > > > > >> that
>> > > > > > > >> > it
>> > > > > > > >> > > > still doesn’t work with failover.
>> > > > > > > >> > > >
>> > > > > > > >> > > > My goal is to not delete queues immediately after
>> > failover
>> > > > > when
>> > > > > > > the
>> > > > > > > >> > queue
>> > > > > > > >> > > > auto delete flag is set to true.
>> > > > > > > >> > > >
>> > > > > > > >> > > > Is there any way to do this?
>> > > > > > > >> > > >
>> > > > > > > >> > > > Here is my queue configuration in Java code:
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > > > *final QueueConfiguration queueConfig =
>> > > > > > > >> > > >
>> > > > > > > >> > > >
>> > > > > > > >> > >
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> QueueConfiguration.of(queueName).setAddress(addressName).setRoutingType(RoutingType.ANYCAST).setAutoDelete(true).setAutoDeleteDelay(30000L).setAutoDeleteMessageCount(-1L).setPurgeOnNoConsumers(false).setNonDestructive(false);*
>> > > > > > > >> > > >
>> > > > > > > >> > > > Thanks! Best regards.
>> > > > > > > >> > > >
>> > > > > > > >> > >
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
