I was referencing the "Pure static networks" section near the bottom of https://activemq.apache.org/networks-of-brokers. That ensures that messages are propagated off the 5.3 broker and onto the 5.16 broker even if no consumer for those destinations is currently connected to the 5.16 broker.
Also, do you use durable subscriptions on topics? If so, and if those durable subscriptions have been re-created on your 5.16 broker, I'm not sure what will happen when you network in the 5.3 broker. I'd expect that the prior subscription's state wouldn't be honored, but I'm not sure whether your subscriber would receive all messages on the topic from the 5.3 broker (i.e. ignoring the fact that some messages had already been acked) or none of the messages on the topic from the 5.3 broker (i.e. treating the topic as though all of those messages had already been acked). Hopefully you don't have any durable subscriptions and don't have to worry about this. If you do, I encourage you to test this out in a non-production environment to be sure you understand the behavior. There might be suggestions we can make if needed, depending on the specifics of your use case. Tim On Fri, Jun 4, 2021, 11:06 AM Phil Ruggera <prugg...@gmail.com> wrote: > What does "include all destinations in the 5.3 -> 5.16 direction, to force > all messages to be transferred" entail? > > On Fri, Jun 4, 2021, 5:45 AM Tim Bain <tb...@alumni.duke.edu> wrote: > > > One option would be to load the 5.3 data file into a new temporary 5.3 > > broker and configure it to make a network of brokers with your 5.16.0 > > broker. You'll likely want to statically include all destinations in the > > 5.3 -> 5.16 direction, to force all messages to be transferred to the > > 5.16.0 broker. Once that's complete, you can tear down the 5.3 broker. > > > > Tim > > > > On Thu, Jun 3, 2021, 1:50 PM Lipika Rout <lipikar...@gmail.com> wrote: > > > > > Hello, > > > > > > We are using activemq embedded with Tomcat v9.0.26. Recently we > upgraded > > > activemq jar from v5.3.0 to 5.16.0 without realizing that messages > > stopped > > > processing for a month in one of the nodes. We are trying to recover > data > > > from 2 journal log files. Usually this happens automatically after > > restart, > > > but this time this didn't happen. > > > > > > Below are the statistics for one of the journal files. > > > > > > Destination statistics: > > > - Topics: 0. > > > - Queues: 0. > > > > > > Commands without destination: > > > + CmdType: KAHA_TRACE_COMMAND (Count: 51407, TotalSize: 31.5 MB > > (33034964), > > > ~AvrgSize: 642 Byte(s) (642), LastBigSize: 2.39 KB (2448), LastSize: 79 > > > Byte(s) (79)) > > > All commands: 51407 (Total size: 31.5 MB (33034964). > > > ----------------------------------------------------------- > > > Command statistics: > > > - Topics: 0 (messages: 0, +subscriptions: 0, -subscription: 0). > > > - Queues: 0 (messages: 0). > > > - Other messages: 51407. > > > > > > Commands: > > > + CmdType: KAHA_TRACE_COMMAND (Count: 51407, TotalSize: 31.5 MB > > (33034964), > > > ~AvrgSize: 642 Byte(s) (642), LastBigSize: 2.39 KB (2448), LastSize: 79 > > > Byte(s) (79)) > > > All commands: 51407 (Total size: 31.5 MB (33034964). > > > > > > Looking for a solution to replay these messages. > > > > > > Thanks > > > Lipika Rout > > > > > >
