Re: suppress error from Camel Route on slave

[Tim Bain]

I was suggesting that as an enhancement (for which a JIRA enhancement
request would need to be submitted if you think it would be useful).  I
don't know of a currently-implemented way to do that, though if one exists
then hopefully someone else will share how to do it.

Your original question was about how to suppress the logging.  You should
be able to disable that logger in the Log4J config, but first you'll have
to figure out which logger that is (I'd either grep the ActiveMQ source
code or Google for that text, or change the appender format to include the
logger name).  I also don't know what other logging (that you'd want) comes
out of that logger and would be lost if you turn it off.

Or you could adjust your process for monitoring your logs, by filtering
them through a grep -v.
On Dec 29, 2015 8:05 AM, "mtod"  wrote:

> That's what I would like to happen but the question is how?
>
> Thanks
>
> Mike
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/suppress-error-from-Camel-Route-on-slave-tp4705457p4705478.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: suppress error from Camel Route on slave

[Quinn Stevenson]

Have you tried using the Broker Camel Component ( 
http://activemq.apache.org/broker-camel-component.html 
 )?  I thought that it 
wouldn’t start the route unless the broker was running.


Quinn Stevenson
qu...@pronoia-solutions.com
(801) 244-7758



> On Dec 29, 2015, at 7:45 AM, mtod  wrote:
> 
> That's what I would like to happen but the question is how?
> 
> Thanks
> 
> Mike
> 
> 
> 
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/suppress-error-from-Camel-Route-on-slave-tp4705457p4705478.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: suppress error from Camel Route on slave

[Tim Bain]

Nope, never; I've only read about it here and on the wiki.  (I've used
Camel, but never embedded in a broker.)  Sorry.  But others on this list
have, so hopefully they can share first-hand knowledge.
On Dec 29, 2015 10:22 AM, "Quinn Stevenson" 
wrote:

> Have you tried using the Broker Camel Component (
> http://activemq.apache.org/broker-camel-component.html <
> http://activemq.apache.org/broker-camel-component.html> )?  I thought
> that it wouldn’t start the route unless the broker was running.
>
>
> Quinn Stevenson
> qu...@pronoia-solutions.com
> (801) 244-7758
>
>
>
> > On Dec 29, 2015, at 7:45 AM, mtod  wrote:
> >
> > That's what I would like to happen but the question is how?
> >
> > Thanks
> >
> > Mike
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/suppress-error-from-Camel-Route-on-slave-tp4705457p4705478.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

Re: Offline durable subscriptions lost when rebuilding kahadb index.

[Tim Bain]

A separate KahaDB instance solely for durable subscription messages would
be a solution that doesn't require compaction.  We already keep scheduled
messages in their own KahaDB instance (right?) for exactly the same
reason.  I'm not sure the lifecycle of durable subscription messages and
the lifecycle of scheduled messages are guaranteed to be similar enough to
put them in the same KahaDB instance, but we can certainly use the same
paradigm a second time.

Tim

Tim
On Dec 28, 2015 10:30 AM, "Christopher Shannon" <
christopher.l.shan...@gmail.com> wrote:

> This is the way KahaDB currently works.  There is no way to keep around the
> durable subscriptions (other than the index) because then KahaDB would
> never be able to GC any files.  The main way I can think of to fix this
> would be to do some sort of compaction, as Tim pointed out in the comments
> of AMQ-4212.  However, compaction would not be a trivial thing to
> implement.
>
> On Fri, Dec 25, 2015 at 10:00 AM, Tim Bain  wrote:
>
> > Chris,
> >
> > Sorry no one responded to you before now, but this certainly does sound
> > like AMQ-4212 didn't fix all causes of the problem.  Can you submit a bug
> > in JIRA and attach a set of data files and the corresponding index that
> > will demonstrate the problem?
> >
> > Thanks,
> > Tim
> > On Sep 4, 2015 7:03 AM, "ChristianWander"  wrote:
> >
> > > Hi,
> > >
> > > I'm using ActiveMQ 5.10.2 and the included example code
> > > (jms-example-durable-sub) to play around with durable subscriptions.
> > >
> > > The examples work fine and the broker remembers the durable
> subscriptions
> > > when the consumer goes offline and the broker is restarted.
> > >
> > > However, if I stop the broker and delete the files db.data and db.redo
> to
> > > enforce a rebuild of the kahadb index according to  here
> > >   , the broker forgets
> about
> > > the
> > > offline durable subscriptions.
> > >
> > > Shouldn't this be fixed with  [AMQ4212]
> > >    or am I doing
> > something
> > > wrong here?
> > >
> > > Chris
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://activemq.2283324.n4.nabble.com/Offline-durable-subscriptions-lost-when-rebuilding-kahadb-index-tp4701701.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>

Re: Offline durable subscriptions lost when rebuilding kahadb index.

[Tim Bain]

Also, AMQ-4212 clearly requested that this exact problem be resolved, it is
marked as Fixed in 5.9, and neither Tim nor Gary made any comments that
indicate that a full solution wasn't implemented.  What you're saying
sounds like we didn't actually resolve the problem, which doesn't match
what the JIRA record indicates.

If the goal was a complete fix, then we have a regression (or a bug in the
fix) and a new JIRA bug should be submitted.  If the decision got made not
to attempt a full fix, then the JIRA record should have been updated to
reflect what we actually did (and a new record that's a clone of the
original should have been submitted to track the fact that we haven't
actually addressed the issue requested by the original, even though we did
work under the original and are closing it to reflect that we're done with
the smaller scope we decided to pursue).

Tim, can you provide any insight into whether we've got a regression/bug or
just need to do some cleanup in JIRA to avoid misleading people?

Tim
On Dec 29, 2015 6:55 AM, "Tim Bain"  wrote:

> A separate KahaDB instance solely for durable subscription messages would
> be a solution that doesn't require compaction.  We already keep scheduled
> messages in their own KahaDB instance (right?) for exactly the same
> reason.  I'm not sure the lifecycle of durable subscription messages and
> the lifecycle of scheduled messages are guaranteed to be similar enough to
> put them in the same KahaDB instance, but we can certainly use the same
> paradigm a second time.
>
> Tim
>
> Tim
> On Dec 28, 2015 10:30 AM, "Christopher Shannon" <
> christopher.l.shan...@gmail.com> wrote:
>
>> This is the way KahaDB currently works.  There is no way to keep around
>> the
>> durable subscriptions (other than the index) because then KahaDB would
>> never be able to GC any files.  The main way I can think of to fix this
>> would be to do some sort of compaction, as Tim pointed out in the comments
>> of AMQ-4212.  However, compaction would not be a trivial thing to
>> implement.
>>
>> On Fri, Dec 25, 2015 at 10:00 AM, Tim Bain  wrote:
>>
>> > Chris,
>> >
>> > Sorry no one responded to you before now, but this certainly does sound
>> > like AMQ-4212 didn't fix all causes of the problem.  Can you submit a
>> bug
>> > in JIRA and attach a set of data files and the corresponding index that
>> > will demonstrate the problem?
>> >
>> > Thanks,
>> > Tim
>> > On Sep 4, 2015 7:03 AM, "ChristianWander"  wrote:
>> >
>> > > Hi,
>> > >
>> > > I'm using ActiveMQ 5.10.2 and the included example code
>> > > (jms-example-durable-sub) to play around with durable subscriptions.
>> > >
>> > > The examples work fine and the broker remembers the durable
>> subscriptions
>> > > when the consumer goes offline and the broker is restarted.
>> > >
>> > > However, if I stop the broker and delete the files db.data and
>> db.redo to
>> > > enforce a rebuild of the kahadb index according to  here
>> > >   , the broker forgets
>> about
>> > > the
>> > > offline durable subscriptions.
>> > >
>> > > Shouldn't this be fixed with  [AMQ4212]
>> > >    or am I doing
>> > something
>> > > wrong here?
>> > >
>> > > Chris
>> > >
>> > >
>> > >
>> > > --
>> > > View this message in context:
>> > >
>> >
>> http://activemq.2283324.n4.nabble.com/Offline-durable-subscriptions-lost-when-rebuilding-kahadb-index-tp4701701.html
>> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> >
>>
>

Re: replicatedLevelDB errors after failover

[mtod]

Was this ever resolved?

I'm testing a leveldb cluster and was performing some fail over and I now
have the same problem.

 
 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/replicatedLevelDB-errors-after-failover-tp4674550p4705479.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: mKahaDB and durable subscriptions

[Tim Bain]

I meant the subscription message itself (and I shouldn't have included the
word "offline"), based on the belief that that message would be kept
forever.  Your response in the other thread makes it clear that that's not
currently done, which avoids the problem of preventing data files from
being deleted but obviously creates its own problem (index files can't be
recreated if durable subscriptions are in use).

What I asked about here would address both issues: by storing all durable
subscription messages (and only the durable subscription messages) in a
separate KahaDB instance, we could avoid deleting the durable subscription
messages (which allows index rebuilds) while separating the messages that
have vastly different lifecycles (so we don't keep the primary KahaDB
instance's data files alive).

Tim
On Dec 28, 2015 10:34 AM, "Christopher Shannon" <
christopher.l.shan...@gmail.com> wrote:

> Multi-KahaDB already separates destinations (if configured that way) into
> their own KahaDB store, so I'm not really sure what you mean by separate
> durable subscriptions.  If a topic has a bunch of offline durables and that
> topic is configured to have its own KahaDB instance then it would not
> affect other destinations and their messages and those other destinations
> would continue to GC properly.
>
> On Fri, Dec 25, 2015 at 10:20 AM, Tim Bain  wrote:
>
> > Is it currently possible to configure multi-KahaDB such that all offline
> > durable subscriptions (for all destinations) go into one KahaDB instance
> > while all other messages go into a second instance?
> >
> > Durable subscription messages seem to break the assumption implicit in
> > KahaDB's design decision to never compact data files, which is that as
> long
> > as consumers are keeping up, all messages in a journal file will quickly
> > become unneeded and the file can always be deleted in lieu of compacting
> > it.  And as has been discussed previously on this mailing list, it's
> > possible for a single old data file to keep alive every data file after
> it
> > if message-ack pairs span the data files, so a single durable
> subscription
> > can theoretically prevent KahaDB from ever deleting another data file
> > (which would be a bug, since correct operation of KahaDB is for data
> files
> > to be deleted when they contain no unconsumed messages).
> >
> > Being able to push them into a separate KahaDB instance would make the
> > assumption valid for the remaining messages in the store, but if that's
> not
> > currently possible then one of the two features (mKahaDB for durable
> > subscriptions, or compaction) needs to be implemented in 5.14.0.
> >
> > Tim
> >
>

Re: suppress error from Camel Route on slave

[mtod]

That's what I would like to happen but the question is how?

Thanks

Mike



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/suppress-error-from-Camel-Route-on-slave-tp4705457p4705478.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Running as an embedded broker in WildFly

[Tim Bain]

A number of people have posted to the list in the past few months about
running ActiveMQ with Wildfly (though mainly Wildfly 8); if any of you want
to create instructions, I'm happy to put them on the wiki if you don't have
edit rights and don't want to get them.
On Dec 28, 2015 1:57 PM, "gturner"  wrote:

> I am looking for GOOD instructions in using ActiveMQ as an embedded broker
> in
> WildFly 10.  Can someone provide such instructions.  We have waited and
> waited on a serious flaw in Artemis to be fixed, and tired of the waiting.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Running-as-an-embedded-broker-in-WildFly-tp4705448.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>