Excellent, thanks for your help Domenico
On Thu, Nov 18, 2021, 9:34 PM Domenico Francesco Bruscino, <
bruscin...@gmail.com> wrote:
> Hi Dave,
>
> you need to add the monitor role to HAWTIO_ROLE in artemis.profile and the
> access for the isActive method in management.xml.
>
> Execute the followi
Hi Dave,
you need to add the monitor role to HAWTIO_ROLE in artemis.profile and the
access for the isActive method in management.xml.
Execute the following steps to get a working example:
1) create a new broker instance:
./bin/artemis create broker --user admin --password admin --require-login
Hello Matt,
Thanks for the reply. Yes, I meant 5.15.12 and 5.16.3. I doubt I'll be able to
get the software engineers to drain the production queues. I have an active and
passive server in each cluster. I'm hoping to upgrade the passive server first,
then making it the active server. Then upgra
Hello Karl-
The upgrade should be pretty straight forward for those versions. You had typed
‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.
If you can have all the applications ‘drain’ all messages, that is the best.
You then get fresh kahadb files created by 5.16.3.
Other
Hi all,
I'm trying to configure role access via the Jolokia REST API for the single
attribute "Active" on the "org.apache.activemq.artemis" domain.
I have a user with a role "monitor" and want them to be able to access
nothing but the above attribute via e.g.
/console/jolokia/read/org.apache.acti
Hi Robbie,
Thanks for your super helpful reply! I'll go with a fixed reply queue and a
dedicated thread for receiving replies.
Again, thanks a lot!
Yann
On Thu, Nov 18, 2021 at 2:42 PM Robbie Gemmell
wrote:
> Setting a MessageListener on a consumer dedicates the Session to its
> asynchronous
Is there documentation on how to upgrade ActiveMQ classic?
I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
our production cluster from 1.16.0 to 1.16.3.
We are using KahaDB version 6.
Thanks
---
Karl Nordström
Systems Administrator
Penn State IT | Application Platforms
Thank you for the answer, Justin.
I'm using another Artemis instance with a bridge sending data to this one.
I've seen Artemis enforcing this limit when using Java clients and writing the
corresponding entry in the log file. We sometimes get a log indicating that the
limit is reached:
2021-11-18
I don't recall any issues with BLOCK which we've fixed in 2.18.0 or 2.19.0
and all the tests are passing. It certainly could be a new bug, but we'd
need more details to confirm.
First off, what kind of client are you using to send the messages?
Justin
On Thu, Nov 18, 2021 at 8:58 AM Roberto wr
Hi all,
In certain configurations the address-full-policy set to BLOCK does not work in
Artemis 2.17.0.
The following configuration:
50Mb
BLOCK
This
By the way, I will create a Jira about that.
Regards
JB
On 18/11/2021 15:08, Jean-Baptiste Onofré wrote:
Hi,
It depends how you start activemq.
If you use your own script, or bin/activemq console, or wrapper, it works.
For instance, I rarely use bin/activemq start|stop.
Anyway, a fix is req
Hi,
It depends how you start activemq.
If you use your own script, or bin/activemq console, or wrapper, it works.
For instance, I rarely use bin/activemq start|stop.
Anyway, a fix is required for sure, probably testing the environment.
I will fix that for 5.16.4.
Regards
JB
On 11/11/2021 21
Setting a MessageListener on a consumer dedicates the Session to its
asynchronous message delivery thread of control [while the connection
is started]. So sending with one thread and also having listener(s)
being delivered consumed messages on the same session is still
multi-threading the session.
13 matches
Mail list logo
