Hello,
maybe I am wrong in writing here, it seems, this mailing list is really
for developer.
I would like to use the AWS-Apache activeMQ for MQTT and I am searching
for some samples I can use for setting it up with some MQTT-devices.
Currently I have some troubles with the TLS-protocol, as I cannot
establish a connection and it seems to be a TLS-issue.
Can you please point me to the right direction?
C:\Program Files\direct\mosquitto_wise4000>mosquitto_pub -h x.x.x.x -m
"test" -t "topic" -u sbomq -P "xxxxxxxxxxx" -p 8883 -d --cafile ca.cert
--insecure
Client null sending CONNECT
Client null received CONNACK (5)
Connection error: Connection Refused: not authorised.
Error: The connection was refused.
it may be a conflict in MQTT-versions, is there any way to get some
debugging information on the AWS-side?
sorry, if this is the wrong channel....
br
Thomas
On 27.10.2025 19:52, Justin Bertram wrote:
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.
EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust
the sender and know the content is safe.
--
*
Thomas Bachleitner*
Sonnblick Observatorium
Sonnblick Observatory
*Akademiestraße 39, 5020 Salzburg
M. +43 664 8319202*
[email protected] <mailto:[email protected]>
| www.geosphere.at <http://www.geosphere.at/>
Besuchen Sie uns auch in den sozialen Netzwerken
Facebook <https://www.facebook.com/GeoSphere.at> | Instagram
<https://www.instagram.com/GeoSphere_AT/> | LinkedIn
<https://www.linkedin.com/company/geosphereaustria>
GeoSphere Austria – Bundesanstalt für Geologie, Geophysik, Klimatologie
und Meteorologie | Anstalt öffentlichen Rechts
Firmensitz: Hohe Warte 38, 1190 Wien | Firmenbuchnummer: 584036 b |
Firmenbuchgericht: Handelsgericht Wien | UID-Nummer: ATU78680526
