[GitHub] activemq-artemis pull request #843: Example showing how to use + in topics

[atoulme]

GitHub user atoulme opened a pull request:

https://github.com/apache/activemq-artemis/pull/843

Example showing how to use + in topics

This edits the basic pubsub example showing Artemis can work with MQTT and 
adds one more use case with a + topic.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/atoulme/activemq-artemis example_with_+_topic

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/843.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #843


commit 36eddbdb4bab292bb9e947f88753e3e0506a93dc
Author: Antoine Toulme 
Date:   2016-10-13T01:36:29Z

Example showing how to use + in topics




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #842: NPE fixes

[scop]

GitHub user scop opened a pull request:

https://github.com/apache/activemq-artemis/pull/842

NPE fixes

Found through code analysis.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scop/activemq-artemis npe

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/842.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #842


commit 6fbafc4441791bd3883e695f395ef35a4d36e62e
Author: Ville Skyttä 
Date:   2016-10-12T21:20:59Z

Fix NPE in empty InExpression.toString

commit a3527869b4a90f4c9ee578c09d1ce9fc06bc1408
Author: Ville Skyttä 
Date:   2016-10-12T21:25:08Z

Fix NPE in JAAS PropertiesLoader when in debug mode without baseDir




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Christopher Shannon]

I went ahead and created https://issues.apache.org/jira/browse/ARTEMIS-796
and the discussion can be continued on there for how to go about this.

On Wed, Oct 12, 2016 at 11:46 AM, Martyn Taylor  wrote:

> On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > The advisories are all listed here:
> > http://activemq.apache.org/advisory-message.html
>
> Thanks.  One difficulty here would be adding all the "topic" advisories,
> since we don't really have the concept of a "topic" in Artemis Core.  I am
> hoping to change this with:
> https://issues.apache.org/jira/browse/ARTEMIS-780.  Which would expose
> pub/sub at the Artemis Core level.  This should facilitate any equivalent
> pub/sub (topic) advisories listed here.
>
> > The only ones currently
> > that I saw that were being sent from the OpenWireProtocolManager were for
> > created/destroyed destinations and new connections.
> >
> > Obviously not all the advisories are currently possible to add but
> > eventually would be nice to support them. In 5.x there's a plugin to
> handle
> > the advisories but in Artemis maybe we could piggy back on the
> > NotificationListener interface that is used for notifications to handle
> > publishing advisory messages.  There's also the notion of replaying
> > advisories for new connections which may not currently exist.  Ie when a
> > new subscriber comes online to the consumer advisory topic we should
> replay
> > all the consumers messages.
>
>
> > For MQTT and STOMP, I agree that it may not necessarily make sense to
> track
> > the producers since they don't exist in the protocol (or maybe we send it
> > lazy on the first message send)  But for the CORE protocol I would think
> it
>
> would be pretty straightforward to add a new packet type that a client
> > could send and it could be tracked. I can work on a PR for it if everyone
> > agrees it makes sense to track it.
>
> I don't think I am quite sold on the lazy producer notifications idea :P.
> But we can get into the details on the JIRA / PR.
>
> >
> > I don't currently have a JIRA created as I wanted to get a discussion
> going
> > first.  Not sure if it makes sense to create individual JIRAs or create
> one
> > JIRA for advisory support with sub tasks.
>
> I tend to go with a single JIRA with subtasks for things like this.
>
> >
>
>
> >
> > On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor 
> > wrote:
> >
> > > Christopher do you have a list of missing notifications, is it mainly
> the
> > > producer notifications?
> > >
> > > I'm all for adding these where they make sense, but there maybe places
> > > where the notifications don't quite make sense to do at the Artemis
> Core
> > > level.  I suspect then, that we'll need to do some notifications on a
> per
> > > protocol basis.  In the producer case, protocols handlers layer the
> > > functionality on top of the CORE model, the concept of a broker side
> > > producer is not something we have in Artemis Core.  OpenWire has a
> > > ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> > > "producer" state is kept in the protocol module itself, MQTT, STOMP and
> > > CORE don't have such things and I'm not sure a notification makes sense
> > to
> > > send notifications for these.
> > >
> > > We probably need to address these one by one.  Do you have a JIRA where
> > we
> > > can track this?
> > >
> > > On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > > > I would say that for JMS (and certainly OpenWire) a producer should
> be
> > > > considered created when making that create producer call on a JMS
> > client.
> > > > At least with OpenWire that ProducerInfo object is sent immediately
> on
> > > > creation and is tracked.
> > > >
> > > > However for other protocols that isn't the case and lazy notification
> > > might
> > > > make more sense but it would be different behavior than 5.x which may
> > or
> > > > may not be ok.  So really we need to decide what our strategy is and
> > > > whether or not we try to make advisory processing uniform across all
> > > > protocols like 5.x or if we leave something like when a producer
> > advisory
> > > > is sent up to each individual protocol.
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes 
> wrote:
> > > >
> > > > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > > > supports.
> > > > >
> > > > > As for when the advisory message is sent for a Producer, I'm not
> sure
> > > > there
> > > > > is a specific guarantee about that. If a Producer is 'created',
> but a
> > > > > message is never sent, was it actually created? I'm not necessarily
> > > > opposed
> > > > > to the lazy notification strategy.
> > > > >
> > > > >
> > > > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > > > christopher.l.shan...@gmail.com> wrote:
> > > > >
> > > > > 

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Martyn Taylor]

On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> The advisories are all listed here:
> http://activemq.apache.org/advisory-message.html

Thanks.  One difficulty here would be adding all the "topic" advisories,
since we don't really have the concept of a "topic" in Artemis Core.  I am
hoping to change this with:
https://issues.apache.org/jira/browse/ARTEMIS-780.  Which would expose
pub/sub at the Artemis Core level.  This should facilitate any equivalent
pub/sub (topic) advisories listed here.

> The only ones currently
> that I saw that were being sent from the OpenWireProtocolManager were for
> created/destroyed destinations and new connections.
>
> Obviously not all the advisories are currently possible to add but
> eventually would be nice to support them. In 5.x there's a plugin to handle
> the advisories but in Artemis maybe we could piggy back on the
> NotificationListener interface that is used for notifications to handle
> publishing advisory messages.  There's also the notion of replaying
> advisories for new connections which may not currently exist.  Ie when a
> new subscriber comes online to the consumer advisory topic we should replay
> all the consumers messages.


> For MQTT and STOMP, I agree that it may not necessarily make sense to track
> the producers since they don't exist in the protocol (or maybe we send it
> lazy on the first message send)  But for the CORE protocol I would think it

would be pretty straightforward to add a new packet type that a client
> could send and it could be tracked. I can work on a PR for it if everyone
> agrees it makes sense to track it.

I don't think I am quite sold on the lazy producer notifications idea :P.
But we can get into the details on the JIRA / PR.

>
> I don't currently have a JIRA created as I wanted to get a discussion going
> first.  Not sure if it makes sense to create individual JIRAs or create one
> JIRA for advisory support with sub tasks.

I tend to go with a single JIRA with subtasks for things like this.

>


>
> On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor 
> wrote:
>
> > Christopher do you have a list of missing notifications, is it mainly the
> > producer notifications?
> >
> > I'm all for adding these where they make sense, but there maybe places
> > where the notifications don't quite make sense to do at the Artemis Core
> > level.  I suspect then, that we'll need to do some notifications on a per
> > protocol basis.  In the producer case, protocols handlers layer the
> > functionality on top of the CORE model, the concept of a broker side
> > producer is not something we have in Artemis Core.  OpenWire has a
> > ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> > "producer" state is kept in the protocol module itself, MQTT, STOMP and
> > CORE don't have such things and I'm not sure a notification makes sense
> to
> > send notifications for these.
> >
> > We probably need to address these one by one.  Do you have a JIRA where
> we
> > can track this?
> >
> > On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > I would say that for JMS (and certainly OpenWire) a producer should be
> > > considered created when making that create producer call on a JMS
> client.
> > > At least with OpenWire that ProducerInfo object is sent immediately on
> > > creation and is tracked.
> > >
> > > However for other protocols that isn't the case and lazy notification
> > might
> > > make more sense but it would be different behavior than 5.x which may
> or
> > > may not be ok.  So really we need to decide what our strategy is and
> > > whether or not we try to make advisory processing uniform across all
> > > protocols like 5.x or if we leave something like when a producer
> advisory
> > > is sent up to each individual protocol.
> > >
> > >
> > > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes  wrote:
> > >
> > > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > > supports.
> > > >
> > > > As for when the advisory message is sent for a Producer, I'm not sure
> > > there
> > > > is a specific guarantee about that. If a Producer is 'created', but a
> > > > message is never sent, was it actually created? I'm not necessarily
> > > opposed
> > > > to the lazy notification strategy.
> > > >
> > > >
> > > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > > christopher.l.shan...@gmail.com> wrote:
> > > >
> > > > > Also as a follow up, I noticed that the OpenWireProtocalManager
> > already
> > > > > fires a couple advisories for new connections/destinations.  I can
> > > > > certainly create a PR to add more advisories but I guess really the
> > > > > question is whether or not we should support the advisories across
> > any
> > > > > protocol or not.
> > > > >
> > > > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > > > 

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Christopher Shannon]

The advisories are all listed here:
http://activemq.apache.org/advisory-message.html  The only ones currently
that I saw that were being sent from the OpenWireProtocolManager were for
created/destroyed destinations and new connections.

Obviously not all the advisories are currently possible to add but
eventually would be nice to support them. In 5.x there's a plugin to handle
the advisories but in Artemis maybe we could piggy back on the
NotificationListener interface that is used for notifications to handle
publishing advisory messages.  There's also the notion of replaying
advisories for new connections which may not currently exist.  Ie when a
new subscriber comes online to the consumer advisory topic we should replay
all the consumers messages.

For MQTT and STOMP, I agree that it may not necessarily make sense to track
the producers since they don't exist in the protocol (or maybe we send it
lazy on the first message send)  But for the CORE protocol I would think it
would be pretty straightforward to add a new packet type that a client
could send and it could be tracked. I can work on a PR for it if everyone
agrees it makes sense to track it.

I don't currently have a JIRA created as I wanted to get a discussion going
first.  Not sure if it makes sense to create individual JIRAs or create one
JIRA for advisory support with sub tasks.


On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor  wrote:

> Christopher do you have a list of missing notifications, is it mainly the
> producer notifications?
>
> I'm all for adding these where they make sense, but there maybe places
> where the notifications don't quite make sense to do at the Artemis Core
> level.  I suspect then, that we'll need to do some notifications on a per
> protocol basis.  In the producer case, protocols handlers layer the
> functionality on top of the CORE model, the concept of a broker side
> producer is not something we have in Artemis Core.  OpenWire has a
> ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> "producer" state is kept in the protocol module itself, MQTT, STOMP and
> CORE don't have such things and I'm not sure a notification makes sense to
> send notifications for these.
>
> We probably need to address these one by one.  Do you have a JIRA where we
> can track this?
>
> On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > I would say that for JMS (and certainly OpenWire) a producer should be
> > considered created when making that create producer call on a JMS client.
> > At least with OpenWire that ProducerInfo object is sent immediately on
> > creation and is tracked.
> >
> > However for other protocols that isn't the case and lazy notification
> might
> > make more sense but it would be different behavior than 5.x which may or
> > may not be ok.  So really we need to decide what our strategy is and
> > whether or not we try to make advisory processing uniform across all
> > protocols like 5.x or if we leave something like when a producer advisory
> > is sent up to each individual protocol.
> >
> >
> > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes  wrote:
> >
> > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > supports.
> > >
> > > As for when the advisory message is sent for a Producer, I'm not sure
> > there
> > > is a specific guarantee about that. If a Producer is 'created', but a
> > > message is never sent, was it actually created? I'm not necessarily
> > opposed
> > > to the lazy notification strategy.
> > >
> > >
> > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > > > Also as a follow up, I noticed that the OpenWireProtocalManager
> already
> > > > fires a couple advisories for new connections/destinations.  I can
> > > > certainly create a PR to add more advisories but I guess really the
> > > > question is whether or not we should support the advisories across
> any
> > > > protocol or not.
> > > >
> > > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > > christopher.l.shan...@gmail.com> wrote:
> > > >
> > > > > In general it would be nice if all of the current advisories that
> are
> > > > > supported in 5.x could eventually be supported in Artemis as well.
> > >  As I
> > > > > was looking at Artemis's notifications to see what currently
> existed
> > > one
> > > > > thing I noticed was that there is a lack of producer notifications.
> > > > Having
> > > > > an advisory sent when a producer is created is something that I
> know
> > I
> > > > use
> > > > > all the time.
> > > > >
> > > > > I dug into this and it looks like the reason is because Artemis
> > doesn't
> > > > > actually track a producer until the first message is sent.  In fact
> > > > there's
> > > > > no notion of a producer on the core wire format at all (there's no
> > > packet
> > > > > type for it).
> > > > >
> > > > > I realize that 

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Christopher Shannon]

I would say that for JMS (and certainly OpenWire) a producer should be
considered created when making that create producer call on a JMS client.
At least with OpenWire that ProducerInfo object is sent immediately on
creation and is tracked.

However for other protocols that isn't the case and lazy notification might
make more sense but it would be different behavior than 5.x which may or
may not be ok.  So really we need to decide what our strategy is and
whether or not we try to make advisory processing uniform across all
protocols like 5.x or if we leave something like when a producer advisory
is sent up to each individual protocol.


On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes  wrote:

> +1 for supporting all the advisories that the current ActiveMQ 5.x
> supports.
>
> As for when the advisory message is sent for a Producer, I'm not sure there
> is a specific guarantee about that. If a Producer is 'created', but a
> message is never sent, was it actually created? I'm not necessarily opposed
> to the lazy notification strategy.
>
>
> On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Also as a follow up, I noticed that the OpenWireProtocalManager already
> > fires a couple advisories for new connections/destinations.  I can
> > certainly create a PR to add more advisories but I guess really the
> > question is whether or not we should support the advisories across any
> > protocol or not.
> >
> > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > In general it would be nice if all of the current advisories that are
> > > supported in 5.x could eventually be supported in Artemis as well.
>  As I
> > > was looking at Artemis's notifications to see what currently existed
> one
> > > thing I noticed was that there is a lack of producer notifications.
> > Having
> > > an advisory sent when a producer is created is something that I know I
> > use
> > > all the time.
> > >
> > > I dug into this and it looks like the reason is because Artemis doesn't
> > > actually track a producer until the first message is sent.  In fact
> > there's
> > > no notion of a producer on the core wire format at all (there's no
> packet
> > > type for it).
> > >
> > > I realize that many protocols don't have the notion of a producer...In
> > 5.x
> > > this is handled by just creating ProducerInfo objects on first
> connection
> > > when a protocol doesn't support it (ie Stomp, etc). However, the JMS
> API
> > > does have a specific call to create a producer so I find it useful to
> get
> > > an advisory message and to track when producers come online even if not
> > > every protocol supports this.
> > >
> > > So I guess I wanted to see what people thought about adding a
> > notification
> > > for producers and also trying to fill in the gaps for the rest of the
> > > advisory topics that are missing.
> > >
> >
>

Re: cannot access data: Input/output error

[Lily]

Does anyone get a chance to look at this issue? Thanks!



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/cannot-access-data-Input-output-error-tp4717750p4717835.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Jim Gomes]

+1 for supporting all the advisories that the current ActiveMQ 5.x supports.

As for when the advisory message is sent for a Producer, I'm not sure there
is a specific guarantee about that. If a Producer is 'created', but a
message is never sent, was it actually created? I'm not necessarily opposed
to the lazy notification strategy.


On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Also as a follow up, I noticed that the OpenWireProtocalManager already
> fires a couple advisories for new connections/destinations.  I can
> certainly create a PR to add more advisories but I guess really the
> question is whether or not we should support the advisories across any
> protocol or not.
>
> On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > In general it would be nice if all of the current advisories that are
> > supported in 5.x could eventually be supported in Artemis as well.   As I
> > was looking at Artemis's notifications to see what currently existed one
> > thing I noticed was that there is a lack of producer notifications.
> Having
> > an advisory sent when a producer is created is something that I know I
> use
> > all the time.
> >
> > I dug into this and it looks like the reason is because Artemis doesn't
> > actually track a producer until the first message is sent.  In fact
> there's
> > no notion of a producer on the core wire format at all (there's no packet
> > type for it).
> >
> > I realize that many protocols don't have the notion of a producer...In
> 5.x
> > this is handled by just creating ProducerInfo objects on first connection
> > when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
> > does have a specific call to create a producer so I find it useful to get
> > an advisory message and to track when producers come online even if not
> > every protocol supports this.
> >
> > So I guess I wanted to see what people thought about adding a
> notification
> > for producers and also trying to fill in the gaps for the rest of the
> > advisory topics that are missing.
> >
>

Re: [DISCUSS] Artemis missing advisories and producer tracking

[Christopher Shannon]

Also as a follow up, I noticed that the OpenWireProtocalManager already
fires a couple advisories for new connections/destinations.  I can
certainly create a PR to add more advisories but I guess really the
question is whether or not we should support the advisories across any
protocol or not.

On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> In general it would be nice if all of the current advisories that are
> supported in 5.x could eventually be supported in Artemis as well.   As I
> was looking at Artemis's notifications to see what currently existed one
> thing I noticed was that there is a lack of producer notifications. Having
> an advisory sent when a producer is created is something that I know I use
> all the time.
>
> I dug into this and it looks like the reason is because Artemis doesn't
> actually track a producer until the first message is sent.  In fact there's
> no notion of a producer on the core wire format at all (there's no packet
> type for it).
>
> I realize that many protocols don't have the notion of a producer...In 5.x
> this is handled by just creating ProducerInfo objects on first connection
> when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
> does have a specific call to create a producer so I find it useful to get
> an advisory message and to track when producers come online even if not
> every protocol supports this.
>
> So I guess I wanted to see what people thought about adding a notification
> for producers and also trying to fill in the gaps for the rest of the
> advisory topics that are missing.
>

[DISCUSS] Artemis missing advisories and producer tracking

[Christopher Shannon]

In general it would be nice if all of the current advisories that are
supported in 5.x could eventually be supported in Artemis as well.   As I
was looking at Artemis's notifications to see what currently existed one
thing I noticed was that there is a lack of producer notifications. Having
an advisory sent when a producer is created is something that I know I use
all the time.

I dug into this and it looks like the reason is because Artemis doesn't
actually track a producer until the first message is sent.  In fact there's
no notion of a producer on the core wire format at all (there's no packet
type for it).

I realize that many protocols don't have the notion of a producer...In 5.x
this is handled by just creating ProducerInfo objects on first connection
when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
does have a specific call to create a producer so I find it useful to get
an advisory message and to track when producers come online even if not
every protocol supports this.

So I guess I wanted to see what people thought about adding a notification
for producers and also trying to fill in the gaps for the rest of the
advisory topics that are missing.

Re: Active MQ Data.db got corrupted

[Christopher Shannon]

It's hard to say what caused the issue with the missing journal files.  The
version you are on is pretty old and there have been many fixes to KahaDB
in later versions of the broker.  One thing you can do is to set
the ignoreMissingJournalfiles flag to true as described here
http://activemq.apache.org/kahadb.html which will allow the broker to start
up and continue even with the missing files.

On Mon, Oct 10, 2016 at 5:59 AM, ramapriyan  wrote:

> We faced one production issue due to the below error. Can any one help on
> the
> reason for the error
>
> 2016-10-08 14:34:47,384 | INFO  | Refreshing
> org.apache.activemq.xbean.XBeanBrokerFactory$1@f356d114: startup date [Sat
> Oct 08 14:34:47 EAT 2016]; root of context hierarchy |
> org.apache.activemq.xbean.XBeanBrokerFactory$1 | main
> 2016-10-08 14:34:48,226 | INFO  |
> PListStore:[/opt/apache-activemq-5.9.1/data/localhost/tmp_storage]
> started |
> org.apache.activemq.store.kahadb.plist.PListStoreImpl | main
> 2016-10-08 14:34:48,497 | INFO  | Using Persistence Adapter:
> KahaDBPersistenceAdapter[/opt/apache-activemq-5.9.1/data/kahadb] |
> org.apache.activemq.broker.BrokerService | main
> 2016-10-08 14:34:53,113 | INFO  | KahaDB is version 5 |
> org.apache.activemq.store.kahadb.MessageDatabase | main
> 2016-10-08 14:34:53,154 | INFO  | Recovering from the journal ... |
> org.apache.activemq.store.kahadb.MessageDatabase | main
> 2016-10-08 14:34:53,213 | INFO  | Recovery replayed 1361 operations from
> the
> journal in 0.089 seconds. | org.apache.activemq.store.
> kahadb.MessageDatabase
> | main
> 2016-10-08 14:34:53,216 | INFO  | Some journal files are missing: [992,
> 993,
> 996, 997, 998, 999, 1001, 1002, 1003, 1006, 1007, 1008, 1009, 991] |
> org.apache.activemq.store.kahadb.MessageDatabase | main
> 2016-10-08 14:34:53,218 | ERROR | Failed to start Apache ActiveMQ
> ([localhost, null], java.io.IOException: Detected missing/corrupt journal
> files. 57 messages affected.) | org.apache.activemq.broker.BrokerService |
> main
> 2016-10-08 14:34:53,220 | INFO  | Apache ActiveMQ 5.9.1 (localhost, null)
> is
> shutting down | org.apache.activemq.broker.BrokerService | main
> 2016-10-08 14:34:53,221 | INFO  | Connector openwire stopped |
> org.apache.activemq.broker.TransportConnector | main
> 2016-10-08 14:34:53,221 | INFO  | Connector amqp stopped |
> org.apache.activemq.broker.TransportConnector | main
> 2016-10-08 14:34:53,221 | INFO  | Connector stomp stopped |
> org.apache.activemq.broker.TransportConnector | main
> 2016-10-08 14:34:53,222 | INFO  | Connector mqtt stopped |
> org.apache.activemq.broker.TransportConnector | main
> 2016-10-08 14:34:53,222 | INFO  | Connector ws stopped |
> org.apache.activemq.broker.TransportConnector | main
> 2016-10-08 14:34:53,223 | INFO  |
> PListStore:[/opt/apache-activemq-5.9.1/data/localhost/tmp_storage]
> stopped |
> org.apache.activemq.store.kahadb.plist.PListStoreImpl | main
> 2016-10-08 14:34:53,224 | INFO  | Stopping async queue tasks |
> org.apache.activemq.store.kahadb.KahaDBStore | main
> 2016-10-08 14:34:53,224 | INFO  | Stopping async topic tasks |
> org.apache.activemq.store.kahadb.KahaDBStore | main
> 2016-10-08 14:34:53,224 | INFO  | Stopped KahaDB |
> org.apache.activemq.store.kahadb.KahaDBStore | main
> 2016-10-08 14:34:53,635 | INFO  | Apache ActiveMQ 5.9.1 (localhost, null)
> uptime 5.404 seconds | org.apache.activemq.broker.BrokerService | main
> 2016-10-08 14:34:53,635 | INFO  | Apache ActiveMQ 5.9.1 (localhost, null)
> is
> shutdown | org.apache.activemq.broker.BrokerService | main
> 2016-10-08 14:34:53,635 | INFO  | Closing
> org.apache.activemq.xbean.XBeanBrokerFactory$1@f356d114: startup date [Sat
> Oct 08 14:34:47 EAT 2016]; root of context hierarchy |
> org.apache.activemq.xbean.XBeanBrokerFactory$1 | main
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-MQ-Data-db-got-corrupted-tp4717735.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>