Just to clarify, did you conduct a load test of some kind which indicated a
single broker couldn't handle the connection load? If so, I'd be curious to
know the details of that test (e.g. hardware specs, OS, connection load,
failure mode, etc.).
Justin
On Wed, Dec 18, 2019 at 8:39 AM ldebello w
Hi Justin,
I was thinking about your point regarding performance and my concern is not
regarding number of messages is more related to number of connections.
In our model you register to our service and you become a consumer in the
broker so per each registration we will have at least one connect
> Is there any wait to max the number of "in delivery" message, because it
seems if I have at least one consumer connected there is no wait to make
use of LVQ.
If the consumer is connected then the broker will dispatch messages to it.
There is no way to force the broker to wait for an arbitrary am
Thanks for your answer, I got your point regarding "in delivery" messages.
Is there any wait to max the number of "in delivery" message, because it
seems if I have at least one consumer connected there is no wait to make use
of LVQ.
I tried to configure "jms.prefetchPolicy.all=1" to test but it w
revious question, because I am checking
> different options but getting some weird behaviors.
>
> We have an Artemis Broker 2.9.0 (Single Node - No Cluster) and doing the
> following test
>
> Queue: State (Last Value Queue)
>
> Producer Send Message: Message(LVQ_ID="So
Hi,
This is some kind of related to my previous question, because I am checking
different options but getting some weird behaviors.
We have an Artemis Broker 2.9.0 (Single Node - No Cluster) and doing the
following test
Queue: State (Last Value Queue)
Producer Send Message: Message(LVQ_ID
I addressed your question about global order on the other thread whose
subject is "Global Order + Cluster + Message Redistribution." In short,
"global order" and "high traffic/volume" are essentially at odds with each
other. If you really want global order then don't cluster. If you want high
volum
I got your point, after analyzing the result it seems when connecting to a
different broker is first doing the message aggregation/redistribution and
then providing the message to consumer.
Given the fact clustering is something good to scale out and LVQ is
something like a good feature, I was thi
Although the behavior appears incorrect I think it is, in fact, correct.
This is because every node in the cluster maintains its own independent
queues and therefore the last-value on each node will be different.
Furthermore, when messages are redistributed then the last-value can change
because ev
Hi,
I have two Artemis broker (2.9.0) running creating a cluster using UDP, and
I hit and issue using LVQ in this way. It general works ok but in some
situations it does not.
Use Cases:
1) Working as Expected
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=985,
Queue=Stat
A unit test would be best that way it can be reproduced. And any solution can
be verified as fixing the problem.
Get Outlook for Android
On Fri, Jul 5, 2019 at 4:02 PM +0100, "mschmeiser"
wrote:
I appreciate the discussion but this seems to have gotten off-topic from my
orig
A test case that recreates the issue is best next steps
Get Outlook for Android
On Fri, Jul 5, 2019 at 4:02 PM +0100, "mschmeiser"
wrote:
I appreciate the discussion but this seems to have gotten off-topic from my
original issue. The issue of durability and server restarts is
I appreciate the discussion but this seems to have gotten off-topic from my
original issue. The issue of durability and server restarts is secondary to
the issue that the replacement of a non-destructively consumed LVQ message
results in an error being thrown.
What are the next steps I should take
; >
> > > Yes, the last value always wins.
> > >
> > > The document says "Another common pattern is to have queue "browsers"
> > which
> > > send all messages to the browser, but do not prevent other consumers
> from
> > > receiving the messages,
t;
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yes, the last value always wins.
> > >
> > > The document says "Another common pattern is to have queue "browsers"
> > which
> >
t; > browser is done with them. Such a browser is an instance of a
> > "non-destructive" consumer." The fact is we don't remove them in memory
> but
> > we append records in journal. When the consumer acks the message and
> > reference count of message is
nce count of message is decremented to zero, the ack record and
> > delete message record are written into journal. If broker restarts, the
> > last value is lost. Not sure it's what we expect?
> >
> >
> > michael.andre.pearce 于2019年7月4日周四
> > 下午11:30写道：
> &
meaning the last value is always kept in the lvq.When a new messages
> > replaces and old then it needs the old one is acked to it is removed,
> this
> > is the point.Sent from my Samsung Galaxy smartphone.
> > Original message From: yw yw Date:
> > 04/07/2019
s the old one is acked to it is removed,
> this
> > is the point.Sent from my Samsung Galaxy smartphone.
> > Original message From: yw yw Date:
> > 04/07/2019 08:42 (GMT+00:00) To: users@activemq.apache.org Subject:
> Re:
> > A
lvq.When a new messages
> > replaces and old then it needs the old one is acked to it is removed,
> this
> > is the point.Sent from my Samsung Galaxy smartphone.
> > Original message From: yw yw Date:
> > 04/07/2019 08:42 (GMT+00:00) To: users@activemq
lvq.When a new messages
> > replaces and old then it needs the old one is acked to it is removed,
> this
> > is the point.Sent from my Samsung Galaxy smartphone.
> > Original message From: yw yw Date:
> > 04/07/2019 08:42 (GMT+00:00) To: users@activemq.ap
(GMT+00:00) To: users@activemq.apache.org Subject: Re:
> AMQ 224038 on Last Value Queue Hi,We have encountered the same problems
> these days.Right now the JMSNonDestructiveTest passes successfully bcs
> persistence isdisabled which means there are no journal operations. If we
> enabl
places and old then it needs the old one is acked to it is removed, this
> is the point.Sent from my Samsung Galaxy smartphone.
> Original message From: yw yw Date:
> 04/07/2019 08:42 (GMT+00:00) To: users@activemq.apache.org Subject: Re:
> AMQ 224038 on Last
From: yw yw Date:
04/07/2019 08:42 (GMT+00:00) To: users@activemq.apache.org Subject: Re: AMQ
224038 on Last Value Queue Hi,We have encountered the same problems these
days.Right now the JMSNonDestructiveTest passes successfully bcs persistence
isdisabled which means there are no journal
So, the LVQ example that came packaged with Artemis doesn't actually work.
According to the comments, it publishes three messages, then expects the
queue to only have one message (as seen in the browser) and for only one of
two invocations of 'receive' to work.
Instead, it publishes three messages
ould it be possible for you to provide more details about how to reproduce
> this failure? Perhaps some simple modifications to the last-value-queue
> example distributed with the broker would suffice.
>
>
> Justin
>
> On Wed, Jul 3, 2019 at 4:44 PM mschmeiser wrote:
>
everything appears to be working as expected.
For what it's worth, I'm testing on the tip of the master branch (i.e.
2.10.0-SNAPSHOT).
Would it be possible for you to provide more details about how to reproduce
this failure? Perhaps some simple modifications to the last-value-queue
example d
Hello
I am getting an error "AMQ224039: Failed to ack old reference:
java.lang.IllegalStateException: Cannot find add info 5698 on compactor or
current records" after every publish of a message to a Last Value Queue
except the first time.
I am on ActiveMQ Artemis 2.8.1. I know ther
f...@gmail.com> Date: 30/04/2018 22:58 (GMT+00:00) To:
> users@activemq.apache.org Subject: [Artemis, AMQP] last-value queue
> question: nondestructive consumers
> currently using Artemis 2.5.0 and AMQP in our tests
> question in short:
> is there an ability to force last-value
: users@activemq.apache.org Subject:
[Artemis, AMQP] last-value queue questions: msg-delay
currently using Artemis 2.5.0 and AMQP in our tests
question in short:
should we be able to use last-value queue and message delay/scheduling
together and have scheduled messages be considered as part of the
:
[Artemis, AMQP] last-value queue question: nondestructive consumers
currently using Artemis 2.5.0 and AMQP in our tests
question in short:
is there an ability to force last-value queue consumers to be
non-destructive so the messages remain on the queue?
a cool use case which we do in the QPID java
currently using Artemis 2.5.0 and AMQP in our tests
question in short:
is there an ability to force last-value queue consumers to be
non-destructive so the messages remain on the queue?
a cool use case which we do in the QPID java broker is we create a
last-value queue and in the broker we can
currently using Artemis 2.5.0 and AMQP in our tests
question in short:
should we be able to use last-value queue and message delay/scheduling
together and have scheduled messages be considered as part of the
last-value queue features.
Some of the teams here have started exploring some interesting
Thanks Michael!
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
t;>
>>>
>>> true
>>>
>>>
>>> I'm writing messages to these queues and the last-value property seems to be
>>> working fine. But on stopping the broker and starting up again, the queue
>>> doesn't behave like last-valu
iting messages to these queues and the last-value property seems to be
>> working fine. But on stopping the broker and starting up again, the queue
>> doesn't behave like last-value queue. I can also see in the web-console that
>> the last-value checkbox is not checked. Is t
e last-value property seems to be
> working fine. But on stopping the broker and starting up again, the queue
> doesn't behave like last-value queue. I can also see in the web-console that
> the last-value checkbox is not checked. Is that a problem with my address
> setting?
>
Hi
I'm creating last-value queues using
true
I'm writing messages to these queues and the last-value property seems to be
working fine. But on stopping the broker and starting up again, the queue
doesn't behave like last-value queue. I can also see in the web-console that
UDP multicast for server discovery or using a multicast address and/or
> queue?
>
>
> > Will they immediately get the last value?
>
> In a last-value queue the only message for a given value which is stored is
> the "last" one received so that will be the one which a c
> Can the multicast work for a client who is connecting for the first time?
I'm not entirely clear on your question here. Are you talking about using
UDP multicast for server discovery or using a multicast address and/or
queue?
> Will they immediately get the last value?
In a last-
> > >
> > >
> > > Justin
> > >
> > > On Fri, Aug 11, 2017 at 5:13 AM, Lionel van den Berg <
> lion...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm currently using activemq a
t; >
> > > Hi,
> > >
> > > I'm currently using activemq and now looking into Artemis. One of the
> > > interest features I see is the is the last-value queue option. However
> > what
> > > I want to use it for is for regularly updating dat
now looking into Artemis. One of the
> > interest features I see is the is the last-value queue option. However
> what
> > I want to use it for is for regularly updating data and not so regular
> > updating data where the last value is always the only interesting value,
> >
ug 11, 2017 at 5:13 AM, Lionel van den Berg
wrote:
> Hi,
>
> I'm currently using activemq and now looking into Artemis. One of the
> interest features I see is the is the last-value queue option. However what
> I want to use it for is for regularly updating data and not so regu
Hi,
I'm currently using activemq and now looking into Artemis. One of the
interest features I see is the is the last-value queue option. However what
I want to use it for is for regularly updating data and not so regular
updating data where the last value is always the only interesting value
Can you share a test?
On Tue, May 30, 2017 at 1:09 AM, vishal3007 wrote:
> if ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE is used as acknowledgement
> option and queue is marked as last-value-queue, then calling recover() on
> the JMSContext does not re-deliver the message.
>
>
if ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE is used as acknowledgement
option and queue is marked as last-value-queue, then calling recover() on
the JMSContext does not re-deliver the message.
Please see the attaced broker.xml for the reference.
broker.xml <http://activemq.2283324
47 matches
Mail list logo
