Olivier
On Thu, 7 Feb 2019 at 12:47, VERMEULEN Olivier
<[email protected]> wrote:
>
> Alex,
>
> Actually I'm trying to find the easiest way to switch my existing performance
> benchmark to use only non-persistent messages...
Take a look at Queue#messageDurability. It allows you to override
the sender application's preference for a message's durability. If
you set NEVER, the message won't written to persistent store even if
the sender requested it.
All queues take their default from ${queue.defaultMessageDurability},
so unless are setting explicitly setting it on a queue, you can just
override from a higher level, for instance, as a system property. It
won't affect messages that are already on the queue.
./bin/qpid-server -Dqueue.defaultMessageDurability=NEVER
Hope this helps
> And using a memory message store seemed like the best option.
> I'm just looking for a quick feedback on the kind of performance improvement
> we could have.
>
> Olivier
>
> -----Original Message-----
> From: Oleksandr Rudyy <[email protected]>
> Sent: jeudi 7 février 2019 11:42
> To: [email protected]
> Subject: Re: [Broker-J] non persistent messages
>
> Olivier,
>
> You are right. The persistent messages are kept in memory with memory message
> store. Please note, that with AMQP 1.0 an attempt to publish persistent
> message on VH with memory store would end-up in error
> "amqp:precondition-failed" - "Non-durable message store cannot accept durable
> message."
> You can set JVM system property 'qpid.tests.mms.messagestore.persistence'
> to 'true' in order to allow persisting of AMQP 1.0 persistent messages into
> memory store.
> Persisting of AMQP 0-x messages into memory store works straight away.
>
> Out of curiosity, what is you messaging use case? Why do you need to use
> Memory message store?
>
> Kind Regards,
> Alex
>
>
> On Thu, 7 Feb 2019 at 10:20, VERMEULEN Olivier <[email protected]>
> wrote:
>
> > Hello Alex,
> >
> > Thanks for the clarification on the non-durable queues.
> > For the store I was talking about the message store, not the config one.
> > So I guess the memory message store would be equivalent to having all
> > messages non-persistent?
> >
> > Olivier
> >
> > -----Original Message-----
> > From: Oleksandr Rudyy <[email protected]>
> > Sent: jeudi 7 février 2019 10:29
> > To: [email protected]
> > Subject: Re: [Broker-J] non persistent messages
> >
> > Hi Olivier,
> >
> > The non-durable queues are not stored in the configuration. Thus, on
> > broker restart they disappear with all their messages regardless
> > whether they are persistent or not.
> > The Memory store was designed mainly for using in tests. All
> > configuration stored there is "persisted" into heap, and, thus, it
> > disappears on broker restart.
> >
> > Kind Regards,
> > Alex
> >
> >
> > On Thu, 7 Feb 2019 at 08:10, VERMEULEN Olivier <
> > [email protected]>
> > wrote:
> >
> > > Hello,
> > >
> > > Just a quick question regarding the broker config.
> > > What's the difference between setting the message store to "Memory"
> > > and setting each queue as "non-durable"? or is it exactly the same thing?
> > >
> > > Thanks,
> > > Olivier
> > > *******************************
> > > This e-mail contains information for the intended recipient only. It
> > > may contain proprietary material or confidential information. If you
> > > are not the intended recipient you are not authorized to distribute,
> > > copy or use this e-mail or any attachment to it. Murex cannot
> > > guarantee that it is virus free and accepts no responsibility for
> > > any loss or damage arising from its use. If you have received this
> > > e-mail in error please notify immediately the sender and delete the
> > > original email received, any attachments and all copies from your system.
> > >
> > *******************************
> > This e-mail contains information for the intended recipient only. It
> > may contain proprietary material or confidential information. If you
> > are not the intended recipient you are not authorized to distribute,
> > copy or use this e-mail or any attachment to it. Murex cannot
> > guarantee that it is virus free and accepts no responsibility for any
> > loss or damage arising from its use. If you have received this e-mail
> > in error please notify immediately the sender and delete the original
> > email received, any attachments and all copies from your system.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected] For
> > additional commands, e-mail: [email protected]
> >
> >
> *******************************
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not the
> intended recipient you are not authorized to distribute, copy or use this
> e-mail or any attachment to it. Murex cannot guarantee that it is virus free
> and accepts no responsibility for any loss or damage arising from its use. If
> you have received this e-mail in error please notify immediately the sender
> and delete the original email received, any attachments and all copies from
> your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
