OK - found the answer just a couple of posts down in the thread "Artemis: DLQ
not working with Core". I needed to add:
clientMessage.acknowledge();
right before the
clientSession.rollback();
...
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Hi,
thank you for this explanation and for the link containing further
explanation.
Regards,
Cooshal.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Hi. I'm using ActiveMQ Artemis 2.6.3. Java client, with separate single
ActiveMQ server. (I.E. no HA)
I'm programmatically creating ClientConsumer's on ClientSession's with
autoCommitAcks false, and with a message handler so I can consume
asynchronously. In the message handler, I have it set t
Log files are deleted after all messages in them are no longer active. For
a normal message, this happens when the message is acknowledged (by its
last consumer, for topics). For an ack message, this happens when the
message being acked is deleted or is in the same file as the ack itself.
If you f
> So does that mean that -- after shutting down master and then slave --
it's not enough to start the slave again and that the master server must be
then started as well?
That's not what I'm saying.
I'm saying that if the master and slave both go down then *administrative
intervention* is require
Hi:
I am using ActiveMQ 5.15.4 on Windows, and currently I am using Apache Camel
in Apache Karaf to import high amount of data, around 7 million records from
one instance, and more 10+ million from another instance. Both these
instances are using the same broker.
I see that around 1.5 million rec
thank you for the explanation.
well, right now I have around 500+ destinations (queues and topics). This is
about to grow further, as my number of karaf instances (with camel routes)
accessing the broker grows. Alongside scaling, as many karaf instances, I
also need to ensure that my messages are
with optimizedDispatch=true, the queue dispatch thread is redundant
(the thread that reads a message does the dispatch) and does not get
to service a browse repeatedly.
it turns a browse into a one shot operation.
The benefits of optimizedDispatch=true are really only apparent with
straight through
Hi again @gtully,
I have a query again.
What if I do not use optimizedDispatch? How does optimizedDispatch help in
scaling. I guess, it does by limiting the message window size. But,
alternately, does it affect the broker's performance?
Any clarification on this would be very helpful.
Regards,
@nico_franz I'm upgrading to 2.9.0 now. I'll test with this one and update
the results here.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Thanks for your reply Justin and wildpeanut
I don't have the skills to extend the netty codec for MQTT 5.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Hi again:
so, does that also mean that my broker will be able to fetch upto 4000
messages at a time? If so, I guess I will run out of connections, right?
Or, will that be managed by ActiveMQ? I will try to play with these settings
and get back.
Regards,
Cooshal.
--
Sent from: http://activemq.
Hi:
ahh ok. then that was caused by optimizedDispatch, right?
Thanks for the clarification.
Regards,
Cooshal.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
there is a policyEntry maxBrowsePageSize with default value 400,
increase that value to see a different result.
`
On Mon, 24 Jun 2019 at 16:11, cooshal wrote:
>
> Hi again:
>
> I checked further stuffs on this issue, and I think I am not able to fetch
> JMS Messages > 400, because of optimizedDi
14 matches
Mail list logo
