RE: JMS messages replication

[Tim Bain]

On Jan 26, 2018 2:42 PM, "COURTAULT Francois" <
francois.courta...@gemalto.com> wrote:

Hello,

@Tim: should I consider that no solution to my problem exists using
ActiveMQ 5.x ?
   If the answer is yes at the previous question, does a
solution to my issue exists in Artemis ? If yes could you please provide me
some information (pointer, explanations, ...)  ?


I don't have personal experience with Artemis, but others on this list do.
And I'd be very surprised if the Artemis documentation on the ActiveMQ
website doesn't describe exactly how to configure a multi-node cluster,
since that's a feature that many users want from Artemis.

   I think I have seen some exchanges about that topic, sorry
to ask this again, but it is not so clear for me: will you release ActiveMQ
6.0 ? or Artemis will be ActiveMQ 6.0 ?


There's been lots of discussion, but as far as I know no decision yet.

@Jonathan:
Linked to the last question asked to Tim, will you consider to
replace/update ActiveMQ by Artemis in the TomEE next major release or
.. before ;-) ?


This question is probably better asked on a TomEE mailing list rather than
this one.

Beast Regards.

-Original Message-
From: Jonathan Gallimore [mailto:jgallim...@tomitribe.com]
Sent: vendredi 26 janvier 2018 19:23
To: users@activemq.apache.org
Subject: RE: JMS messages replication

Hey Francois,

I have successfully managed to get TomEE going with Artemis, but it isn't
very user friendly, and I'm sure the integration could be better.

If you're up for some hacking on that, let me know and I'd be happy to give
you some pointers.

Cheers

Jon

On 26 Jan 2018 17:29, "COURTAULT Francois" 
wrote:

Hello,

As we are using TomEE, I think ActiveMQ 5.x is quite mandatory.
I don't know so much about the TomEE roadmap but, for the TomEE Java EE 8
compliant version, they will perhaps use Artemis 

BTW, using ActiveMQ 5.x and digging further in the ActiveMQ documentation,
could the Networks of Brokers a solution for my problem ?

Best Regards.

-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: vendredi 26 janvier 2018 18:22
To: ActiveMQ Users 
Subject: Re: JMS messages replication

Have you considered using Artemis rather than ActiveMQ 5.x?

Tim

On Jan 26, 2018 10:02 AM, "COURTAULT Francois" <
francois.courta...@gemalto.com> wrote:

> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site,
> even if LevelDB store has been replaced by KahaDB, in order to see if
> it can solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not
> a solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 -->
> Location 1 JMS broker  Location 2 JMS broker  <- - JMS
> producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at
> Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or
> at persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion
> of Master and Slave, managed by ZooKeeper, and in the schema above,
> let's say that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able
> to accept any client connections, according to your documentation,
> right ? So It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found
> the fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the
sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the 

RE: JMS messages replication

[Tim Bain]

Each message exists on one and only one node at a time in a network of
brokers, and is forwarded from broker to broker based on demand. If you're
looking for replication, for example to protect you from messages being
unavailable if a broker goes offline, a NoB won't give you that.

And replicated LevelDB is only applicable in a master-slave pair, where
only one node at a time is accepting connections, which doesn't sound like
what you want either.

It sounds like what you want is clustered operation, and 5.x doesn't
support that. But Artemis does, if you feel up for following the
suggestions Jonathan offered to give you for how to integrate it into TomEE.

Tim

On Jan 26, 2018 10:08 AM, "COURTAULT Francois"  wrote:

> Hello,
>
> Digging further in the ActiveMQ documentation, could the Networks of
> Brokers a solution ?
>
> Best Regards.
>
> -Original Message-
> From: COURTAULT Francois [mailto:francois.courta...@gemalto.com]
> Sent: vendredi 26 janvier 2018 18:02
> To: users@activemq.apache.org
> Subject: [+SPAM+]: JMS messages replication
>
> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site, even
> if LevelDB store has been replaced by KahaDB, in order to see if it can
> solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not a
> solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 --> Location 1
> JMS broker
>  Location 2 JMS broker  <- - JMS producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or at
> persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion of
> Master and Slave, managed by ZooKeeper, and in the schema above, let's say
> that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able to
> accept any client connections, according to your documentation, right ? So
> It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found the
> fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: partially durable queue?

[Tim Bain]

It'll only throw away unconsumed messages. So a single event like a
whole-house power failure won't lose many messages, because the consumer
will probably be up to date and there won't be any messages on the broker.
You're only at risk of data loss if there are multiple failures separated
by a significant amount of time (the consumer dies, and then substantially
later the broker dies due to something unrelated). It might be that the
odds of that are low enough and the consequences reasonable enough that you
can accept that risk, or maybe not.

Also, keep in mind that if you're keeping data in memory until you fill
memory, your messages are non-persistent and will be lost when the message
broker cycles. That's true for any messaging product configured the way
you've said you want it, so it's not unique to ActiveMQ 5.x. If losing most
or all of your unconsumed messages is a problem, you need to be storing
them on disk even if it wears out your cheap SSDs, or you need to stand up
a central broker on something with an attached spinning disk.

Tim

On Jan 26, 2018 10:51 AM, "Noel Grandin"  wrote:

On Fri, 26 Jan 2018 at 19:22, Tim Bain  wrote:

>
> 5.x can also do in-memory-till-full-then-spool-to-disk when using
> non-persistent messages (which go to the memory store and then to the temp
> store if the memory store is full).
>

That’s useful info thanks. But non persistent means that the broker will
throw away the messages on a reboot? Which wouldn’t be good for me.
I can lose a small window of data, but if the wan disconnects for a while
and then the machine reboots I need to keep most of the data.




>

Hawtio service destroyed on slave after master server restart

[ravirake]

Hi,

We have master and slave failover configuration. So when master goes down
the slave pick up but In a particular case when master is back online after
the failure, the slave hands over and in this case hawtio service is being
destroyed as seen in the logs below. Therefore the hawtio console doesn't
show up.

Is this a known issue? If not when can we expect the fix?

FYI: This issue is in *ActiveMQ Artemis 2.4.0*

11:46:16,478 INFO  [io.hawt.web.AuthenticationFilter] Destroying hawtio
authentication filter
11:46:16,479 INFO  [io.hawt.HawtioContextListener] *Destroying hawtio
services*
11:46:16,853 INFO  [org.apache.activemq.hawtio.plugin.PluginContextListener]
Destroyed artemis-plugin plugin
11:46:16,864 INFO 
[org.apache.activemq.hawtio.branding.PluginContextListener] Destroyed
activemq-branding plugin
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221002:
Apache ActiveMQ Artemis Message Broker version 2.4.0
[67ff7eb6-e67c-11e7-ae7e-9801a79ac3c9] stopped, uptime 1 minute
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221039:
Restarting as Replicating backup server after live restart
11:46:16,878 INFO  [org.apache.activemq.artemis.core.server] AMQ221000:
backup Message Broker is starting with configuration Broker Configuration
(clustered=true,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging)

Thanks,
Ravi 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Hawtio service destroyed on slave after master server restart

[ravirake]

Hi,

We have master and slave failover configuration. So when master goes down
the slave pick up but In a particular case when master is back online after
the failure, the slave hands over and in this case hawtio service is being
destroyed as seen in the logs below. Therefore the hawtio console doesn't
show up.

Is this a known issue? If not when can we expect the fix?

FYI: This issue is in *ActiveMQ Artemis 2.4.0*

11:46:16,478 INFO  [io.hawt.web.AuthenticationFilter] Destroying hawtio
authentication filter
11:46:16,479 INFO  [io.hawt.HawtioContextListener] *Destroying hawtio
services*
11:46:16,853 INFO  [org.apache.activemq.hawtio.plugin.PluginContextListener]
Destroyed artemis-plugin plugin
11:46:16,864 INFO 
[org.apache.activemq.hawtio.branding.PluginContextListener] Destroyed
activemq-branding plugin
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221002:
Apache ActiveMQ Artemis Message Broker version 2.4.0
[67ff7eb6-e67c-11e7-ae7e-9801a79ac3c9] stopped, uptime 1 minute
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221039:
Restarting as Replicating backup server after live restart
11:46:16,878 INFO  [org.apache.activemq.artemis.core.server] AMQ221000:
backup Message Broker is starting with configuration Broker Configuration
(clustered=true,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging)

Thanks,
Ravi 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Hawtio service destroyed on slave after master server restart

[ravirake]

Hi,

We have master and slave failover configuration. So when master goes down
the slave pick up but In a particular case when master is back online after
the failure, the slave hands over and in this case hawtio service is being
destroyed as seen in the logs below. Therefore the hawtio console doesn't
show up. 

Is this a known issue? If not when can we expect the fix?

FYI: This issue is in *ActiveMQ Artemis 2.4.0*

11:46:16,478 INFO  [io.hawt.web.AuthenticationFilter] Destroying hawtio
authentication filter
11:46:16,479 INFO  [io.hawt.HawtioContextListener] *Destroying hawtio
services*
11:46:16,853 INFO  [org.apache.activemq.hawtio.plugin.PluginContextListener]
Destroyed artemis-plugin plugin
11:46:16,864 INFO 
[org.apache.activemq.hawtio.branding.PluginContextListener] Destroyed
activemq-branding plugin
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221002:
Apache ActiveMQ Artemis Message Broker version 2.4.0
[67ff7eb6-e67c-11e7-ae7e-9801a79ac3c9] stopped, uptime 1 minute
11:46:16,877 INFO  [org.apache.activemq.artemis.core.server] AMQ221039:
Restarting as Replicating backup server after live restart
11:46:16,878 INFO  [org.apache.activemq.artemis.core.server] AMQ221000:
backup Message Broker is starting with configuration Broker Configuration
(clustered=true,journalDirectory=./data/journal,bindingsDirectory=./data/bindings,largeMessagesDirectory=./data/large-messages,pagingDirectory=./data/paging)

Thanks,
Ravi



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

RE: JMS messages replication

[COURTAULT Francois]

Hello,

@Tim: should I consider that no solution to my problem exists using ActiveMQ 
5.x ?
   If the answer is yes at the previous question, does a solution 
to my issue exists in Artemis ? If yes could you please provide me some 
information (pointer, explanations, ...)  ?
   I think I have seen some exchanges about that topic, sorry to 
ask this again, but it is not so clear for me: will you release ActiveMQ 6.0 ? 
or Artemis will be ActiveMQ 6.0 ?

@Jonathan:
Linked to the last question asked to Tim, will you consider to 
replace/update ActiveMQ by Artemis in the TomEE next major release or  .. 
before ;-) ?

Beast Regards.

-Original Message-
From: Jonathan Gallimore [mailto:jgallim...@tomitribe.com]
Sent: vendredi 26 janvier 2018 19:23
To: users@activemq.apache.org
Subject: RE: JMS messages replication

Hey Francois,

I have successfully managed to get TomEE going with Artemis, but it isn't very 
user friendly, and I'm sure the integration could be better.

If you're up for some hacking on that, let me know and I'd be happy to give you 
some pointers.

Cheers

Jon

On 26 Jan 2018 17:29, "COURTAULT Francois" 
wrote:

Hello,

As we are using TomEE, I think ActiveMQ 5.x is quite mandatory.
I don't know so much about the TomEE roadmap but, for the TomEE Java EE 8 
compliant version, they will perhaps use Artemis 

BTW, using ActiveMQ 5.x and digging further in the ActiveMQ documentation, 
could the Networks of Brokers a solution for my problem ?

Best Regards.

-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: vendredi 26 janvier 2018 18:22
To: ActiveMQ Users 
Subject: Re: JMS messages replication

Have you considered using Artemis rather than ActiveMQ 5.x?

Tim

On Jan 26, 2018 10:02 AM, "COURTAULT Francois" < 
francois.courta...@gemalto.com> wrote:

> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site,
> even if LevelDB store has been replaced by KahaDB, in order to see if
> it can solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not
> a solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 -->
> Location 1 JMS broker  Location 2 JMS broker  <- - JMS
> producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at
> Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or
> at persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion
> of Master and Slave, managed by ZooKeeper, and in the schema above,
> let's say that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able
> to accept any client connections, according to your documentation,
> right ? So It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found
> the fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the
sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: partially durable queue?

[Clebert Suconic]

It will work with artemis. It will start to steam to disk when beyond
configured limit.

On Fri, Jan 26, 2018 at 2:12 PM Noel Grandin  wrote:

> On 26 January 2018 at 20:58, Clebert Suconic 
> wrote:
>
> > With artemis you can simply disable syncs on producer and you would get
> > similar performance numbers. Usually people turn of persistence to gain
> >
>
> Ah, it's not perf I'm after, think of this as a kind of IOT/sensor device,
> I want to preserve my rather cheap SSD device from wearing out.
>
> I'm producing a number of measurements on 24/7 basis (10-50 messages / sec)
>
> In the common case I should be able to stream this out without ever hitting
> disk, but for backup I need to spool messages if the consumer becomes
> temporarily unreachable.
>
> This is an abnormal use-case, so I'm not surprised it's not readily
> available.
>
> But I figured
> (a) I might get lucky
> (b) if not, it might be worth adding the feature to ActiveMQ myself to
> avoid re-inventing all the other parts
>
-- 
Clebert Suconic

Re: partially durable queue?

[Noel Grandin]

On 26 January 2018 at 20:58, Clebert Suconic 
wrote:

> With artemis you can simply disable syncs on producer and you would get
> similar performance numbers. Usually people turn of persistence to gain
>

Ah, it's not perf I'm after, think of this as a kind of IOT/sensor device,
I want to preserve my rather cheap SSD device from wearing out.

I'm producing a number of measurements on 24/7 basis (10-50 messages / sec)

In the common case I should be able to stream this out without ever hitting
disk, but for backup I need to spool messages if the consumer becomes
temporarily unreachable.

This is an abnormal use-case, so I'm not surprised it's not readily
available.

But I figured
(a) I might get lucky
(b) if not, it might be worth adding the feature to ActiveMQ myself to
avoid re-inventing all the other parts

Re: partially durable queue?

[Clebert Suconic]

With artemis you can simply disable syncs on producer and you would get
similar performance numbers. Usually people turn of persistence to gain
some performance.  With artemis you can just always persist and increase
perf by batching multiple writes. SyncOnDurable=false on the connection
factory.

On Fri, Jan 26, 2018 at 12:51 PM Noel Grandin  wrote:

> On Fri, 26 Jan 2018 at 19:22, Tim Bain  wrote:
>
> >
> > 5.x can also do in-memory-till-full-then-spool-to-disk when using
> > non-persistent messages (which go to the memory store and then to the
> temp
> > store if the memory store is full).
> >
>
> That’s useful info thanks. But non persistent means that the broker will
> throw away the messages on a reboot? Which wouldn’t be good for me.
> I can lose a small window of data, but if the wan disconnects for a while
> and then the machine reboots I need to keep most of the data.
>
>
>
>
> >
>
-- 
Clebert Suconic

RE: JMS messages replication

[Jonathan Gallimore]

Hey Francois,

I have successfully managed to get TomEE going with Artemis, but it isn't
very user friendly, and I'm sure the integration could be better.

If you're up for some hacking on that, let me know and I'd be happy to give
you some pointers.

Cheers

Jon

On 26 Jan 2018 17:29, "COURTAULT Francois" 
wrote:

Hello,

As we are using TomEE, I think ActiveMQ 5.x is quite mandatory.
I don't know so much about the TomEE roadmap but, for the TomEE Java EE 8
compliant version, they will perhaps use Artemis 

BTW, using ActiveMQ 5.x and digging further in the ActiveMQ documentation,
could the Networks of Brokers a solution for my problem ?

Best Regards.

-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: vendredi 26 janvier 2018 18:22
To: ActiveMQ Users 
Subject: Re: JMS messages replication

Have you considered using Artemis rather than ActiveMQ 5.x?

Tim

On Jan 26, 2018 10:02 AM, "COURTAULT Francois" <
francois.courta...@gemalto.com> wrote:

> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site,
> even if LevelDB store has been replaced by KahaDB, in order to see if
> it can solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not
> a solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 -->
> Location 1 JMS broker  Location 2 JMS broker  <- - JMS
> producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at
> Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or
> at persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion
> of Master and Slave, managed by ZooKeeper, and in the schema above,
> let's say that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able
> to accept any client connections, according to your documentation,
> right ? So It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found
> the fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the
sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the addressees
and may contain confidential information. Any unauthorized use or
disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for
the message if altered, changed or falsified. If you are not the intended
recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission
free from viruses, the sender will not be liable for damages caused by a
transmitted virus.

Re: partially durable queue?

[Noel Grandin]

On Fri, 26 Jan 2018 at 19:22, Tim Bain  wrote:

>
> 5.x can also do in-memory-till-full-then-spool-to-disk when using
> non-persistent messages (which go to the memory store and then to the temp
> store if the memory store is full).
>

That’s useful info thanks. But non persistent means that the broker will
throw away the messages on a reboot? Which wouldn’t be good for me.
I can lose a small window of data, but if the wan disconnects for a while
and then the machine reboots I need to keep most of the data.




>

RE: JMS messages replication

[COURTAULT Francois]

Hello,

As we are using TomEE, I think ActiveMQ 5.x is quite mandatory.
I don't know so much about the TomEE roadmap but, for the TomEE Java EE 8 
compliant version, they will perhaps use Artemis 

BTW, using ActiveMQ 5.x and digging further in the ActiveMQ documentation, 
could the Networks of Brokers a solution for my problem ?

Best Regards.

-Original Message-
From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf Of Tim Bain
Sent: vendredi 26 janvier 2018 18:22
To: ActiveMQ Users 
Subject: Re: JMS messages replication

Have you considered using Artemis rather than ActiveMQ 5.x?

Tim

On Jan 26, 2018 10:02 AM, "COURTAULT Francois" < 
francois.courta...@gemalto.com> wrote:

> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site,
> even if LevelDB store has been replaced by KahaDB, in order to see if
> it can solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not
> a solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 -->
> Location 1 JMS broker  Location 2 JMS broker  <- - JMS
> producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at
> Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or
> at persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion
> of Master and Slave, managed by ZooKeeper, and in the schema above,
> let's say that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able
> to accept any client connections, according to your documentation,
> right ? So It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found
> the fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: partially durable queue?

[Tim Bain]

This mailing list is for the two ActiveMQ forks: 5.x and Artemis (which is
expected to become 6.x). RabbitMQ and all other message brokers are
unrelated products.

5.x can also do in-memory-till-full-then-spool-to-disk when using
non-persistent messages (which go to the memory store and then to the temp
store if the memory store is full).

Pro tip: spending two minutes Googling products you've never heard of is a
much better use of everyone's time than just replying to say you don't know
what they are.

Tim

On Jan 26, 2018 9:49 AM, "Noel Grandin"  wrote:

> On Fri, 26 Jan 2018 at 17:59, Justin Bertram  wrote:
>
> >
> > If you're asking about ActiveMQ, can you clarify if you're asking about
> the
> > 5.x or Artemis broker?
> >
>
>
> I’ve only just started looking at tech options, so I don’t even know what
> those are. I assume different forks of active mq?
>

Re: JMS messages replication

[Tim Bain]

Have you considered using Artemis rather than ActiveMQ 5.x?

Tim

On Jan 26, 2018 10:02 AM, "COURTAULT Francois" <
francois.courta...@gemalto.com> wrote:

> Hello,
>
> I have looked at Replicated LevelDB Store page on ActiveMQ web site, even
> if LevelDB store has been replaced by KahaDB, in order to see if it can
> solve the technical issue I have.
> But, as far as I have understood this solution won't solve my problem.
>
> Let me describe it, in order to really see if the LevelDB Store is not a
> solution.
>
> What I want to have is:
>JMS producers & consumers at Location 1 --> Location 1
> JMS broker
>  Location 2 JMS broker  <- - JMS producers & Consumers at
> Location2
>
>|
>
>|
>
>Persisted messages at Location 1
>  Persisted messages at Location 2
>
> But also persisted messages at location 2 replicated at Location 1 and
> vice versa , thanks to a synchronization between the 2 JMS brokers or at
> persistent level.
>
> My understanding of Replicated LevelDB Store is that we have a notion of
> Master and Slave, managed by ZooKeeper, and in the schema above, let's say
> that Location 1 JMS broker is the Master.
> In such case, the second JMS broker, Location 2 JMS broker is not able to
> accept any client connections, according to your documentation, right ? So
> It can't consume JMS producers messages at Location2, right ?
> This is why I think I can't use this solution.
>
> So, is there a solution to my problem using Active MQ ? Yes, using,
> instead of KahaDB, a database with a built-in replication.
> Cassandra could be used for example, but unfortunately I haven't found the
> fact that Cassandra is supported by ActiveMQ.
>
> Still a blocking point.
>
> Does it exist a solution to my technical problem using ActiveMQ ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

RE: JMS messages replication

[COURTAULT Francois]

Hello,

Digging further in the ActiveMQ documentation, could the Networks of Brokers a 
solution ?

Best Regards.

-Original Message-
From: COURTAULT Francois [mailto:francois.courta...@gemalto.com]
Sent: vendredi 26 janvier 2018 18:02
To: users@activemq.apache.org
Subject: [+SPAM+]: JMS messages replication

Hello,

I have looked at Replicated LevelDB Store page on ActiveMQ web site, even if 
LevelDB store has been replaced by KahaDB, in order to see if it can solve the 
technical issue I have.
But, as far as I have understood this solution won't solve my problem.

Let me describe it, in order to really see if the LevelDB Store is not a 
solution.

What I want to have is:
   JMS producers & consumers at Location 1 --> Location 1 JMS 
broker Location 
2 JMS broker  <- - JMS producers & Consumers at Location2

 |  

 |

 Persisted messages at Location 1   
  Persisted messages at Location 2

But also persisted messages at location 2 replicated at Location 1 and vice 
versa , thanks to a synchronization between the 2 JMS brokers or at persistent 
level.

My understanding of Replicated LevelDB Store is that we have a notion of Master 
and Slave, managed by ZooKeeper, and in the schema above, let's say that 
Location 1 JMS broker is the Master.
In such case, the second JMS broker, Location 2 JMS broker is not able to 
accept any client connections, according to your documentation, right ? So It 
can't consume JMS producers messages at Location2, right ?
This is why I think I can't use this solution.

So, is there a solution to my problem using Active MQ ? Yes, using, instead of 
KahaDB, a database with a built-in replication.
Cassandra could be used for example, but unfortunately I haven't found the fact 
that Cassandra is supported by ActiveMQ.

Still a blocking point.

Does it exist a solution to my technical problem using ActiveMQ ?

Best Regards.

This message and any attachments are intended solely for the addressees and may 
contain confidential information. Any unauthorized use or disclosure, either 
whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

JMS messages replication

[COURTAULT Francois]

Hello,

I have looked at Replicated LevelDB Store page on ActiveMQ web site, even if 
LevelDB store has been replaced by KahaDB, in order to see if it can solve the 
technical issue I have.
But, as far as I have understood this solution won't solve my problem.

Let me describe it, in order to really see if the LevelDB Store is not a 
solution.

What I want to have is:
   JMS producers & consumers at Location 1 --> Location 1 JMS 
broker Location 
2 JMS broker  <- - JMS producers & Consumers at Location2

 |  

 |

 Persisted messages at Location 1   
  Persisted messages at Location 2

But also persisted messages at location 2 replicated at Location 1 and vice 
versa , thanks to a synchronization between the 2 JMS brokers or at persistent 
level.

My understanding of Replicated LevelDB Store is that we have a notion of Master 
and Slave, managed by ZooKeeper, and in the schema above, let's say that 
Location 1 JMS broker is the Master.
In such case, the second JMS broker, Location 2 JMS broker is not able to 
accept any client connections, according to your documentation, right ? So It 
can't consume JMS producers messages at Location2, right ?
This is why I think I can't use this solution.

So, is there a solution to my problem using Active MQ ? Yes, using, instead of 
KahaDB, a database with a built-in replication.
Cassandra could be used for example, but unfortunately I haven't found the fact 
that Cassandra is supported by ActiveMQ.

Still a blocking point.

Does it exist a solution to my technical problem using ActiveMQ ?

Best Regards.

This message and any attachments are intended solely for the addressees and may 
contain confidential information. Any unauthorized use or disclosure, either 
whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: partially durable queue?

[Noel Grandin]

On Fri, 26 Jan 2018 at 17:59, Justin Bertram  wrote:

>
> If you're asking about ActiveMQ, can you clarify if you're asking about the
> 5.x or Artemis broker?
>


I’ve only just started looking at tech options, so I don’t even know what
those are. I assume different forks of active mq?

Re: partially durable queue?

[Clebert Suconic]

You can do that with Artemis and Paging.. I'm not sure about Rabbit :)

On Fri, Jan 26, 2018 at 10:15 AM, Noel Grandin  wrote:
>
> Hi
>
> I have a need for a queue that operates purely in-memory until the
> consumer(s) can't keep up, and only then starts spooling to disk.
> I'm ok with losing some messages in the event of a hardware or software
> crash.
>
> Is there such a configuration in RabbitMQ? If not, could one be created with
> a plugin?
>
> For context, the requirement is slightly weird in that I'm
> (a) wanting to push some data back over a flakey WAN
> (b) from an underpowered piece of hardware that doesn't like it's little SSD
> drive being written too hard
> :-)
>
> Thanks, Noel Grandin
>



-- 
Clebert Suconic

Re: partially durable queue?

[Justin Bertram]

Are you asking about RabbitMQ?  If so, the ActiveMQ user list might not be
the best place to get answers about RabbitMQ.

If you're asking about ActiveMQ, can you clarify if you're asking about the
5.x or Artemis broker?


Justin

On Fri, Jan 26, 2018 at 9:15 AM, Noel Grandin  wrote:

>
> Hi
>
> I have a need for a queue that operates purely in-memory until the
> consumer(s) can't keep up, and only then starts spooling to disk.
> I'm ok with losing some messages in the event of a hardware or software
> crash.
>
> Is there such a configuration in RabbitMQ? If not, could one be created
> with a plugin?
>
> For context, the requirement is slightly weird in that I'm
> (a) wanting to push some data back over a flakey WAN
> (b) from an underpowered piece of hardware that doesn't like it's little
> SSD drive being written too hard
> :-)
>
> Thanks, Noel Grandin
>
>

partially durable queue?

[Noel Grandin]

Hi

I have a need for a queue that operates purely in-memory until the consumer(s) can't keep up, and only then starts 
spooling to disk.

I'm ok with losing some messages in the event of a hardware or software crash.

Is there such a configuration in RabbitMQ? If not, could one be created with a 
plugin?

For context, the requirement is slightly weird in that I'm
(a) wanting to push some data back over a flakey WAN
(b) from an underpowered piece of hardware that doesn't like it's little SSD 
drive being written too hard
:-)

Thanks, Noel Grandin

[ARTEMIS] Messages with same group-id are received by multiple consumers

[Ogi]

I have two deployed apps, one on my local machine and one on the server and
both apps are communicating through the same Artemis client which is
installed on the server. Artemis version is 1.5.5. Problem occurs when I
execute simple test that sends 1000 messages divided into multiple groups,
in this case 50 groups (numbers are not important, it happens no matter the
number of messages or groups) from the server app. Local app consumer
receives every group and almost all messages. It's because server app
consumer receives for example only one message from let's say group number 5
and that behavior is repeated in multiple groups. 

Why is this happening, am I missing something ? Again, both consumers and
producers are working on same Artemis.

Thank you in advance,
Ognjen



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Francesco Nigro]

> BTW: I currenty own the required grants since oracle is running on my own
laptop. But I know that this will cause trouble when installing Artemis in
our production environment.

Probably it could be a latency issue too: there are several configuration
properties
 that
could be tuned to allow working with high latency connection (but it is not
reccomended TBH):

   - *jdbc-lock-acquisition-timeout* The max allowed time in milliseconds
   while trying to acquire a JDBC lock. The default value is 6
   milliseconds (ie 60 seconds).
   - *jdbc-lock-renew-period* The period in milliseconds of the keep alive
   service of a JDBC lock. The default value is 2000 milliseconds (ie 2
   seconds).
   - *jdbc-lock-expiration* The time in milliseconds a JDBC lock is
   considered valid without keeping it alive. The default value is 2
   milliseconds (ie 20 seconds).

*jdbc-lock-acquisition-timeout *could be turned to -1 ie infinite and the
others could be raised to appropiate values considering the DBMS latencies
(eg I would say renew to 10 seconds and expiration to 60 seconds).

> 3) no I haven't tried the latest master. But since I do not find a related
issue in JIRA I assume that it still exist.

Some time ago I've opened (and it is already merged on master) Make the
JDBC Node Manager more resilient on failures
 to address cases like
this, hopefully it will solve it.

> And I can see that the broker is holding a lock on that table. So it
tries to
insert something which fails but does not properly rollback...

That's strange but not impossible: there is a rare case of a leaking and
unkilleable Oracle driver thread called:
oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser
.
It could be the one actually locking that table.

Cheers,
Franz



Il giorno ven 26 gen 2018 alle ore 14:44 Archibald  ha
scritto:

> And I can see that the broker is holding a lock on that table. So it tries
> to
> insert something which fails but does not properly rollback...
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Artemis 2.1.0 compatibility with 1.5.x

[hcrobison]

We really need the backwards comparability. Please let me know whether and
how I can create a jira for this issue.
Thanks.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Archibald]

And I can see that the broker is holding a lock on that table. So it tries to
insert something which fails but does not properly rollback...



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: [ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Archibald]

Hi Franz, 

to your questions:
1) Oracle Database 12c Standard Edition Release 12.2.0.1.0 - 64bit
Production
2) not more is being written to the log (not even in debug)
3) no I haven't tried the latest master. But since I do not find a related
issue in JIRA I assume that it still exist.

BTW: I currenty own the required grants since oracle is running on my own
laptop. But I know that this will cause trouble when installing Artemis in
our production environment.

HTH,
Archibald



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Artemis Connection failure has been detected

[Raul Valdoleiros]

Hi,

Thanks for your help :)

2018-01-26 9:10 GMT+00:00 Francesco Nigro :

> Hi,
>
> as Miroslav said, that warnings aren't a sign of any lost message, but I
> agree that they are somehow scary :)
> Maybe could worth to lower the log level to INFO.
>
> Thanks,
> Franz
>
>
> Il giorno ven 26 gen 2018 alle ore 09:28 Miroslav Novak  >
> ha scritto:
>
> > Hi,
> >
> > those messages are normal when server in Artemis cluster is shutdown. You
> > will not loose messages if you start the broker again. Note that messages
> > are usually load-balanced (distributed) to all nodes in cluster in round
> > robin fashion. So shutting down node in cluster (without proper scale
> down)
> > will cause that messages on shutdown node cannot be processed.
> >
> > Thanks,
> > Mirek
> >
> > - Original Message -
> > > From: "Raul Valdoleiros" 
> > > To: users@activemq.apache.org
> > > Sent: Thursday, January 25, 2018 6:34:11 PM
> > > Subject: Artemis Connection failure has been detected
> > >
> > > Hi,
> > >
> > > I'm trying to create a dynamic cluster of artemis brokers. I'm getting
> > the
> > > following messages when I shutdown one of the brokers.
> > >
> > > 17:24:47,747 WARN  [org.apache.activemq.artemis.core.client]
> AMQ212037:
> > > Connection failure has been detected: AMQ119015: The connection was
> > > disconnected because of server shutdown [code=DISCONNECTED]
> > > 17:24:47,763 WARN  [org.apache.activemq.artemis.core.client]
> AMQ212037:
> > > Connection failure has been detected: AMQ119015: The connection was
> > > disconnected because of server shutdown [code=DISCONNECTED]
> > > 17:24:47,755 WARN  [org.apache.activemq.artemis.core.client]
> AMQ212037:
> > > Connection failure has been detected: AMQ119015: The connection was
> > > disconnected because of server shutdown [code=DISCONNECTED]
> > > 17:24:47,769 WARN  [org.apache.activemq.artemis.core.server]
> AMQ222095:
> > > Connection failed with failedOver=false
> > > 17:24:47,797 WARN  [org.apache.activemq.artemis.core.server]
> AMQ222095:
> > > Connection failed with failedOver=false
> > > 17:24:47,801 INFO  [org.apache.activemq.artemis.core.server]
> AMQ221029:
> > > stopped bridge
> > > $.artemis.internal.sf.my-cluster.23bc5035-d11d-11e7-b017-8c705a641428
> > > 17:24:57,973 WARN  [org.apache.activemq.artemis.core.client]
> AMQ212034:
> > > There are more than one servers on the network broadcasting the same
> node
> > > id. You will see this message exactly once (per node) if a node is
> > > restarted, in which case it can be safely ignored. But if it is logged
> > > continuously it means you really do have more than one node on the same
> > > network active concurrently with the same node id. This could occur if
> > you
> > > have a backup node active at the same time as its live node.
> > > nodeID=23bc5035-d11d-11e7-b017-8c705a641428
> > >
> > > I suspect that this behavior makes the brokers lost messages.
> > >
> > > I attached the brokers configurations. Can someone help me understand
> > what
> > > is wrong?
> > >
> > > Thanks in advance,
> > > Raul
> > >
> >
>

Re: [ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Francesco Nigro]

I understand; to help i need a couple of other things too:

1) which DB vendor has been used
2) a more verbose log of the error, if possible
3) have you tried the last master too?

All these 3 questions obviously will fall if you could raise the privileges
of the DB user :)

Cheers,
Franz




Il giorno ven 26 gen 2018 alle ore 11:41 Archibald  ha
scritto:

> Thanks Franz,
>
> the other tables do work pretty well if they already exist but are empty.
> It
> is just the NODE_MANAGE_STORE which somehow "picky"...
>
> Br,
> Archibald
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: [ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Archibald]

Thanks Franz, 

the other tables do work pretty well if they already exist but are empty. It
is just the NODE_MANAGE_STORE which somehow "picky"...

Br,
Archibald 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Security

[Lionel van den Berg]

What is recommended to use with ActiveMQ (5.14/5.15) for security?

We've started dabling with the authentication, which seems fine, but we
would also like to consider encryption.

Will we lose the ability to use XML filters if encrypted?

Thanks

Lionel.

Re: Artemis Connection failure has been detected

[Francesco Nigro]

Hi,

as Miroslav said, that warnings aren't a sign of any lost message, but I
agree that they are somehow scary :)
Maybe could worth to lower the log level to INFO.

Thanks,
Franz


Il giorno ven 26 gen 2018 alle ore 09:28 Miroslav Novak 
ha scritto:

> Hi,
>
> those messages are normal when server in Artemis cluster is shutdown. You
> will not loose messages if you start the broker again. Note that messages
> are usually load-balanced (distributed) to all nodes in cluster in round
> robin fashion. So shutting down node in cluster (without proper scale down)
> will cause that messages on shutdown node cannot be processed.
>
> Thanks,
> Mirek
>
> - Original Message -
> > From: "Raul Valdoleiros" 
> > To: users@activemq.apache.org
> > Sent: Thursday, January 25, 2018 6:34:11 PM
> > Subject: Artemis Connection failure has been detected
> >
> > Hi,
> >
> > I'm trying to create a dynamic cluster of artemis brokers. I'm getting
> the
> > following messages when I shutdown one of the brokers.
> >
> > 17:24:47,747 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> > Connection failure has been detected: AMQ119015: The connection was
> > disconnected because of server shutdown [code=DISCONNECTED]
> > 17:24:47,763 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> > Connection failure has been detected: AMQ119015: The connection was
> > disconnected because of server shutdown [code=DISCONNECTED]
> > 17:24:47,755 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> > Connection failure has been detected: AMQ119015: The connection was
> > disconnected because of server shutdown [code=DISCONNECTED]
> > 17:24:47,769 WARN  [org.apache.activemq.artemis.core.server] AMQ222095:
> > Connection failed with failedOver=false
> > 17:24:47,797 WARN  [org.apache.activemq.artemis.core.server] AMQ222095:
> > Connection failed with failedOver=false
> > 17:24:47,801 INFO  [org.apache.activemq.artemis.core.server] AMQ221029:
> > stopped bridge
> > $.artemis.internal.sf.my-cluster.23bc5035-d11d-11e7-b017-8c705a641428
> > 17:24:57,973 WARN  [org.apache.activemq.artemis.core.client] AMQ212034:
> > There are more than one servers on the network broadcasting the same node
> > id. You will see this message exactly once (per node) if a node is
> > restarted, in which case it can be safely ignored. But if it is logged
> > continuously it means you really do have more than one node on the same
> > network active concurrently with the same node id. This could occur if
> you
> > have a backup node active at the same time as its live node.
> > nodeID=23bc5035-d11d-11e7-b017-8c705a641428
> >
> > I suspect that this behavior makes the brokers lost messages.
> >
> > I attached the brokers configurations. Can someone help me understand
> what
> > is wrong?
> >
> > Thanks in advance,
> > Raul
> >
>

[ARTEMIS] Server doesn't start if JDBC store is used and table NODE_MANAGER_STORE is empty

[Archibald]

Hi all, 

2.4.0 introduced a new table NODE_MANAGER_STORE. This table is being created
on startup if it doesn't exist.
But if it does exist but is empty server fails to start (seen on a oracle
database) with

08:43:20,510 INFO  [org.apache.activemq.artemis.integration.bootstrap]
AMQ101000: Starting ActiveMQ Artemis Server
activemq_1  | can't write NODE_ID on the JDBC Node Manager Store!

The issue is that the database user it is not always allowed (has the proper
grants) to create/modify a schema. 

Can this be fixed?

Thanks, 
Archibald



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Artemis Connection failure has been detected

[Miroslav Novak]

Hi,

those messages are normal when server in Artemis cluster is shutdown. You will 
not loose messages if you start the broker again. Note that messages are 
usually load-balanced (distributed) to all nodes in cluster in round robin 
fashion. So shutting down node in cluster (without proper scale down) will 
cause that messages on shutdown node cannot be processed. 

Thanks,
Mirek

- Original Message -
> From: "Raul Valdoleiros" 
> To: users@activemq.apache.org
> Sent: Thursday, January 25, 2018 6:34:11 PM
> Subject: Artemis Connection failure has been detected
> 
> Hi,
> 
> I'm trying to create a dynamic cluster of artemis brokers. I'm getting the
> following messages when I shutdown one of the brokers.
> 
> 17:24:47,747 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> Connection failure has been detected: AMQ119015: The connection was
> disconnected because of server shutdown [code=DISCONNECTED]
> 17:24:47,763 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> Connection failure has been detected: AMQ119015: The connection was
> disconnected because of server shutdown [code=DISCONNECTED]
> 17:24:47,755 WARN  [org.apache.activemq.artemis.core.client] AMQ212037:
> Connection failure has been detected: AMQ119015: The connection was
> disconnected because of server shutdown [code=DISCONNECTED]
> 17:24:47,769 WARN  [org.apache.activemq.artemis.core.server] AMQ222095:
> Connection failed with failedOver=false
> 17:24:47,797 WARN  [org.apache.activemq.artemis.core.server] AMQ222095:
> Connection failed with failedOver=false
> 17:24:47,801 INFO  [org.apache.activemq.artemis.core.server] AMQ221029:
> stopped bridge
> $.artemis.internal.sf.my-cluster.23bc5035-d11d-11e7-b017-8c705a641428
> 17:24:57,973 WARN  [org.apache.activemq.artemis.core.client] AMQ212034:
> There are more than one servers on the network broadcasting the same node
> id. You will see this message exactly once (per node) if a node is
> restarted, in which case it can be safely ignored. But if it is logged
> continuously it means you really do have more than one node on the same
> network active concurrently with the same node id. This could occur if you
> have a backup node active at the same time as its live node.
> nodeID=23bc5035-d11d-11e7-b017-8c705a641428
> 
> I suspect that this behavior makes the brokers lost messages.
> 
> I attached the brokers configurations. Can someone help me understand what
> is wrong?
> 
> Thanks in advance,
> Raul
>