Sorry for the ambiguousness. I created a durable lvq where non destructive
is *true*, the consumer received the message and acked it. After broker
restarted, the message was lost.
<michael.andre.pea...@me.com.invalid> 于2019年7月5日周五 下午3:28写道：
> Have you done the same test with lvq and non destructive false (default)
> where the consumer receives the message but doesnt ack it. Then restart
> broker.
>
>
>
>
> If the message is lost there it would suggest issue in lvq or persistence.
>
>
>
>
> Remember you need to set the queue to durable if you want it to survive a
> restart.
>
>
>
>
> I did a quick test myself and from what i can tell if the queue is non
> durable i get the experiece you are describing which would be expected as
> queue is not durable. But if i set the queue durable i dont.
>
>
>
>
> So far from tests ive done things are behaving expected per settings.
>
>
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Fri, Jul 5, 2019 at 8:06 AM +0100, <michael.andre.pea...@me.com.INVALID>
> wrote:
>
>
>
>
>
>
>
>
>
>
> Note non destructive, is regardless of the queue being lvq or normal.
>
>
>
>
> Though primary case (but not only) for it is in conjunction with lvq.
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Fri, Jul 5, 2019 at 8:03 AM +0100, wrote:
>
>
>
>
>
>
>
>
>
>
> When non destructive is true the consumer ack ignored.
>
>
>
>
> When non destructive is false (default) the consumer ack is honoured.
>
>
>
>
> There is test cases for this and is used in real use cases.
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Fri, Jul 5, 2019 at 7:30 AM +0100, "yw yw" wrote:
>
>
>
>
>
>
>
>
>
>
> Hi,
> Just to clarify, are consumers meant to be able to remove the message for
> lvq when non destructive is true?
>
> I took a test: for the lvq of which non destructive is true, the producer
> sent a message and consumer received it. After broker restarted, the
> message was removed.
>
> 于2019年7月5日周五 下午1:33写道：
>
> > For lvq when non destructive is false consumers are meant to be able to
> > remove the message by acking.
> >
> >
> >
> >
> > Use case there is coalesced price updates where you just care about
> > lastest value, but the updates are faster than a consumer may deal with.
> >
> >
> >
> >
> > Behaviour is as expected.
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 5, 2019 at 2:53 AM +0100, "yw yw" wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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, and do not remove them from the queue when the
> > 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 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写道：
> >
> > > Non destructive is so a consumer doesnt ack the message. Essentially
> > > 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 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 operations. If
> we
> > > enablepersistence, the test fails in
> testNonDestructiveLVQTombstone().The
> > > reproduce step is the same with what Matt said:1. First send a
> message.2.
> > > Then receive the message. The key point is here: We ack this message
> > > anddelete the message so the record is removed in "records" map.3. Last
> > > send another message. The exception occurs
> > >
> >
> below:[Thread-13(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@77a57272
> > )]15:01:06,990
> > > ERROR [org.apache.activemq.artemis.core.server] AMQ224038:Failed to ack
> > old
> > > reference: java.lang.IllegalStateException: Cannot findadd info 446 on
> > > compactor or current
> > >
> >
> recordsatorg.apache.activemq.artemis.core.journal.impl.JournalImpl.checkKnownRecordID(JournalImpl.java:1081)[:]atorg.apache.activemq.artemis.core.journal.impl.JournalImpl.appendUpdateRecord(JournalImpl.java:888)[:]atorg.apache.activemq.artemis.core.journal.Journal.appendUpdateRecord(Journal.java:98)[:]atorg.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.storeAcknowledge(AbstractJournalStorageManager.java:425)[:]atorg.apache.activemq.artemis.core.server.impl.QueueImpl.acknowledge(QueueImpl.java:1539)[:]atorg.apache.activemq.artemis.core.server.impl.LastValueQueue.acknowledge(LastValueQueue.java:193)[:]atorg.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.acknowledge(MessageReferenceImpl.java:235)[:]atorg.apache.activemq.artemis.core.server.impl.LastValueQueue.replaceLVQMessage(LastValueQueue.java:172)[:]atorg.apache.activemq.artemis.core.server.impl.LastValueQueue.addTail(LastValueQueue.java:107)[:]atorg.apache.activemq.artemis.core.server.impl.RoutingContextImpl.internalprocessReferences(RoutingContextImpl.java:164)[:]atorg.apache.activemq.artemis.core.server.impl.RoutingContextImpl.processReferences(RoutingContextImpl.java:159)[:]atorg.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl$2.done(PostOfficeImpl.java:1378)[:]atorg.apache.activemq.artemis.core.persistence.impl.journal.OperationContextImpl$1.run(OperationContextImpl.java:244)[:]atorg.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)[:]atorg.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)[:]atorg.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)[:]atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[rt.jar:1.8.0_102]atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[rt.jar:1.8.0_102]atorg.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)[:]I'm
> > > confused with the current lastValueQueue design. Why do we
> acknowledgethe
> > > message(i mean in normal ack reason) if the queue is non
> destructive?What
> > > if we acknowledged messages and messages were deleted in the
> journal,then
> > > broker restarted? I assume these messages would be lost, seems
> againstthe
> > > non destructive principal? It seems like we don't need to
> > reallyacknowledge
> > > messages except for KILLED/EXPIRED/ REPLACED reasons for thenon
> > destructive
> > > queue?Justin Bertram 于2019年7月4日周四 上午11:27写道：> There
> > > are a couple of tests in the test suite which use both last-value and>
> > > non-destructive queue attributes (e.g. in>
> > >
> >
> org.apache.activemq.artemis.tests.integration.amqp.JMSNonDestructiveTest).>
> > > These work without issue. I also took the code you pasted and tried to>
> > > reproduce the failure, but 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 distributed with the broker would
> > suffice.>>>
> > > Justin>> On Wed, Jul 3, 2019 at 4:44 PM mschmeiser
> > > wrote:>> > 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 there's a more recent version but> > checked the release
> > > notes and none of the bug fixes looked like they'd be> > relevant to
> > this.>
> > > >> > I'm not working with a deployment-ready system yet, this is very
> > > early> > stage> > prototyping. I have a single broker with the basic
> > > configuration, I'm> > basically running things 'out of the box'. The
> java
> > > code that I'm using> > looks something like:> >> > ***> >> >
> > ActiveMQQueue
> > > destination = ActiveMQQueue.createQueue(subject +> >
> > > "?last-value-key=LVK&non-destructive=true");> >> > MessageProducer
> > producer
> > > = session.createProducer(destination);> >> > TextMessage message =
> > > session.createTextMessage("test object");> >
> > > message.setStringProperty("LVK", "foo");> >> > Thread.sleep(500);> >> >
> > > session.createConsumer(destination, "LVK =
> 'foo'").setMessageListener(m>
> > > ->> > processMessage(m));> >> > Thread.sleep(500);> >> > message =
> > > session.createTextMessage("test object 2");> >
> > > message.setStringProperty("LVK", "foo");> >> > producer.send(message);>
> > >>
> > > > Thread.sleep(500);> >> > session.createConsumer(destination, "LVK =
> > > 'foo'").setMessageListener(m> ->> > processMessage(m));> >> > ***> >> >
> > The
> > > first time this code is run, I only get the error when the message is>
> >
> > > sent the second time. After that, the error happens twice per run. If
> I>
> > > go> > into the broker console and purge the queue, then the first
> message
> > > send> > works fine, error is thrown every subsequent time.> >> > The
> > stack
> > > trace (I'm not able to copy/paste from my development> > environment)>
> >
> > > looks like:> >> >
> JournalImpl.checkKnownRecordID(JournalImpl.java:1074)>
> > >
> > > JournalImpl.appendUpdateRecord(JournalImpl.java:881)> >
> > > Journal.appendUpdateRecord(Journal.java:98)> >> >>
> > >
> >
> AbstractJournalStorageManager.storeAcknowledge(AbstractJournalStorageManager.java:425)>
> > > > QueueImpl.acknowledge(QueueImpl.java:1533)> >
> > > LastValueQueue.acknowledge(MessageReferenceImpl.java:235)> >
> > > MessageReferenceImpl.acknowledge(MessageReferenceImpl.java:235)> >
> > > LastValueQueue.replaceLVQMessage(LastValueQueue.java:172)> >
> > > LastValueQueue.addTail(LastValueQueue.java:107)> > ...> >> > Tracing it
> > > back that far, it looks like the failed acknowledge shouldn't> > cause
> > > major problems for the functionality of the system. The code is all> >
> > > executing as you'd expect it to and the queue on the broker always has>
> > > the> > expected message in it. The error is still a concern though
> simply
> > > as a> > matter of performance - scalability is a concern for me and the
> > > overhead> of> > logging a bunch of errors would be a problem.> >> > Let
> > me
> > > know if there's any other information I can provide that could> help> >
> > > diagnose this issue.> >> > Thanks,> > Matt> >> >> >> > --> > Sent
> from:>
> > >
> > > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html> >>
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
