Hi Alex, On Mon, 25 Jun 2018 at 11:44, Oleksandr Rudyy <oru...@gmail.com> wrote:
> Hi Olivier, > > An implementation of new non-persistent config store for the > dispatch-router is not on the current Qpid roadmap. > You are welcome to contribute such implementation. > Basically, you need to implement a new type of VirtualHostNode and new > type of DurableConfigurationStore. > Potentially, a new type of VirtualHostNode can extend existing > org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode. > You can follow an implementation of JSON Virtual Host Node > (org.apache.qpid.server.virtualhostnode.JsonVirtualHostNodeImpl). > I'm not sure I understand how any of this relates to the Dispatch Router? All your comments above seem to be referencing Qpid Broker-J not Dispatch. -- Rob > > Kind Regards, > Alex > > On 25 June 2018 at 08:39, VERMEULEN Olivier <olivier.vermeu...@murex.com> > wrote: > > Ok so I must keep a persistent config store for the Broker. > > But if I'm not mistaken the Dispacth-Router only supports a > non-persistent config store. > > So are there any plans to implement new config stores for the > dispatch-router? > > > > Thanks, > > Olivier > > > > -----Original Message----- > > From: Rob Godfrey <rob.j.godf...@gmail.com> > > Sent: vendredi 22 juin 2018 13:20 > > To: users@qpid.apache.org > > Cc: Keith Wall <keith.w...@gmail.com> > > Subject: Re: [Broker-J 7.0.3] Memory configuration store and messages > recovery > > > > Sure - but at that point you really need to provide the vhost config > before the vhost itself starts up... would providing all the config > (including the queue UUIDs) in a virtualHostInitialConfiguration provided > to the VirtualHostNode on creation help I wonder... > > > > -- Rob > > > > On Fri, 22 Jun 2018 at 12:14, VERMEULEN Olivier < > olivier.vermeu...@murex.com> > > wrote: > > > >> Hello Rob, > >> > >> The main problem is to keep my version of the config in sync with the > >> one of each broker. > >> And knowing that all our brokers have the same config the added > >> complexity seems a bit overkill. > >> Especially when you start thinking about broker restart, scale up, > >> scale down... > >> > >> Olivier > >> > >> -----Original Message----- > >> From: Rob Godfrey <rob.j.godf...@gmail.com> > >> Sent: vendredi 22 juin 2018 11:27 > >> To: users@qpid.apache.org > >> Cc: Keith Wall <keith.w...@gmail.com> > >> Subject: Re: [Broker-J 7.0.3] Memory configuration store and messages > >> recovery > >> > >> In general, in order to be able to recover the queues from a message > >> store, the broker needs to know details of the queue - not only its > >> name, but also the type of the queue (standard, priority, LVQ, etc) as > >> well as other queue properties... this is precisely the data which is > >> stored in the configuration store, I don't think there's really any > >> way around that problem. What sort of problems are you experiencing > >> by using a non-Memory configuration store in your setup? > >> > >> -- Rob > >> > >> On Fri, 22 Jun 2018 at 10:47, VERMEULEN Olivier < > >> olivier.vermeu...@murex.com> > >> wrote: > >> > >> > Hello Keith, > >> > > >> > Thanks for the quick answer. > >> > Our target is a cluster of brokers and dispatch-routers. > >> > To configure it we created a management component that centralizes > >> > the configuration of all the Qpid components. > >> > With this approach, having the broker store its own configuration is > >> > redundant with what our management component does and causes some > >> problems. > >> > That's why I was looking into the memory configuration store which > >> > would have made the broker behave like the dispatch-router regarding > >> > dynamic configuration. > >> > > >> > Olivier > >> > > >> > -----Original Message----- > >> > From: Keith W <keith.w...@gmail.com> > >> > Sent: vendredi 22 juin 2018 10:14 > >> > To: users@qpid.apache.org > >> > Subject: Re: [Broker-J 7.0.3] Memory configuration store and > >> > messages recovery > >> > > >> > Hello Olivier > >> > > >> > Let me say first that the memory store's primary use-case is to aid > >> > development and testing of Broker-J, by speeding ups the test cycle. > >> > It also has utility when using embedding Broker-J in the unit tests > >> > of another project and you want to discard all messaging state > >> > between > >> tests. > >> > > >> > You are correct in your analysis. Queues (like all other objects) > >> > are allocated a random UUID on creation. This UUID is stored in the > >> > configuration store together with the queue's name and all other > >> > attributes. Within the message store, the message instance records > >> > refer to the queue's UUID rather than its name. So if your set-up > >> > is a persistent message store and volatile configuration store, yes, > >> > you will lose messages. This is expected. The recovery phase of > >> > startup will clear the message store of the orphans. > >> > > >> > What problem are you actually trying to solve? > >> > > >> > Keith. > >> > > >> > > >> > > >> > On 22 June 2018 at 08:54, VERMEULEN Olivier > >> > <olivier.vermeu...@murex.com> > >> > wrote: > >> > > Hello, > >> > > > >> > > I was running some tests on a Java Broker with 'Memory' > >> > > configuration > >> > store and 'DERBY' message store. > >> > > Is there a way with this configuration to recover the messages > >> > > stored in > >> > DB upon a broker restart? > >> > > Because it looks like the messages are mapped to the queue UUID > >> > > and that > >> > they are discarded directly during the broker startup if the queue > >> > with the specified UUID is not found. > >> > > And obviously since I'm using a 'Memory' configuration store, the > >> > > queue > >> > has not been recreated yet when the broker starts... > >> > > Have I missed something? > >> > > > >> > > 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 authorised 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: users-unsubscr...@qpid.apache.org For > >> > additional commands, e-mail: users-h...@qpid.apache.org > >> > > >> > ******************************* > >> > > >> > 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 authorised 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: users-unsubscr...@qpid.apache.org For > >> > additional commands, e-mail: users-h...@qpid.apache.org > >> > > >> > > >> ******************************* > >> > >> 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 authorised 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 authorised 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: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
