from:"prateekjai...@gmail.com"

Hi All,

  How are you? I am trying to deploy artemis on kubernetes (k8s) cluster. I
would like to know if any of you can share any thoughts or experience while
doing similar tasks. Especially, if I choose this to be a statefulset; what
will be the impacts while monitoring and backup.

 My current approach is to create cluster (with shared persistence) and
stateful pods of artemis. I also looked at this project
https://github.com/artemiscloud but couldn't decide as that is based upon
the operator approach.

Any thoughts would be appreciated.

Regards
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

Re: cloud-native deployment

Thanks for the feedback, Ephemeris. Did you do anything special to avoid
split brain scenarios?

Regards,
Prateek Jain



--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 13, 2023 at 10:08 AM Ephemeris Lappis <
ephemeris.lap...@gmail.com> wrote:

> Hello.
>
> We've not experienced deployment of Artemis yet, but for our last works
> we use "classic" ActiveMQ 5.17.x on our K8s clusters. Our PODs are
> stateless, since we use JDBC (postgresql) persistence instead of KahaDB.
> We've also tested 2 PODs configurations.
>
> In both cases Openwire and HTTP connectors are exposed to other PODs as
> K8s services and endpoints. All seems to work as expected.
>
> Regards.
>
> Ephemeris Lappis
>
> Le 13/03/2023 à 10:45, prateekjai...@gmail.com a écrit :
> > Hi All,
> >
> >How are you? I am trying to deploy artemis on kubernetes (k8s)
> cluster. I
> > would like to know if any of you can share any thoughts or experience
> while
> > doing similar tasks. Especially, if I choose this to be a statefulset;
> what
> > will be the impacts while monitoring and backup.
> >
> >   My current approach is to create cluster (with shared persistence) and
> > stateful pods of artemis. I also looked at this project
> > https://github.com/artemiscloud but couldn't decide as that is based
> upon
> > the operator approach.
> >
> > Any thoughts would be appreciated.
> >
> > Regards
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>
> --
> Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
> www.avast.com
>

Re: cloud-native deployment

Thanks Vilius and Ephemeris for your input.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 13, 2023 at 11:07 AM Vilius Šumskas 
wrote:

> Hi,
>
> check the mailing list archives. This question comes up regulary.
>
> --
> Vilius
>
> -Original Message-
> From: prateekjai...@gmail.com 
> Sent: Monday, March 13, 2023 11:46 AM
> To: users@activemq.apache.org
> Subject: cloud-native deployment
>
> Hi All,
>
>   How are you? I am trying to deploy artemis on kubernetes (k8s) cluster.
> I would like to know if any of you can share any thoughts or experience
> while doing similar tasks. Especially, if I choose this to be a
> statefulset; what will be the impacts while monitoring and backup.
>
>  My current approach is to create cluster (with shared persistence) and
> stateful pods of artemis. I also looked at this project
> https://github.com/artemiscloud but couldn't decide as that is based upon
> the operator approach.
>
> Any thoughts would be appreciated.
>
> Regards
> Prateek Jain
>
> --
> EXPECTATION : Causes all troubles..
> --
>

Re: cloud-native deployment

Hi Tobias,

 I have already looked at this project and I mentioned it in my original
email. Unfortunately, I don't see any commercial support (apart from
Redhat) around that project and documentation is not very good. I have got
enough information for now to proceed with my POC. In case you faced any
specific issues on cloud, that I should be aware of; please let me know.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 13, 2023 at 1:34 PM Tobias Letschka  wrote:

> Hi,
>
> have a look to below project https://artemiscloud.io/
>
> we using artemis in azure aks environment. do you have questions?
>
> Regards
>
> Tobias
> ____
> Von: prateekjai...@gmail.com 
> Gesendet: Montag, 13. März 2023 12:28
> An: users@activemq.apache.org 
> Betreff: Re: cloud-native deployment
>
> Thanks Vilius and Ephemeris for your input.
>
> Regards,
> Prateek Jain
>
> --
> EXPECTATION : Causes all troubles..
> --
>
>
> On Mon, Mar 13, 2023 at 11:07 AM Vilius Šumskas 
> wrote:
>
> > Hi,
> >
> > check the mailing list archives. This question comes up regulary.
> >
> > --
> > Vilius
> >
> > -Original Message-
> > From: prateekjai...@gmail.com 
> > Sent: Monday, March 13, 2023 11:46 AM
> > To: users@activemq.apache.org
> > Subject: cloud-native deployment
> >
> > Hi All,
> >
> >   How are you? I am trying to deploy artemis on kubernetes (k8s) cluster.
> > I would like to know if any of you can share any thoughts or experience
> > while doing similar tasks. Especially, if I choose this to be a
> > statefulset; what will be the impacts while monitoring and backup.
> >
> >  My current approach is to create cluster (with shared persistence) and
> > stateful pods of artemis. I also looked at this project
> >
> https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fartemiscloud&data=05%7C01%7Ctle%40covernet.de%7C2187c99af2a64f2cc23d08db23b624c7%7C208430bc6bc34416b38372f0236b7581%7C0%7C0%7C638143037421773884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uo3%2BMC2STZ1DH7Yt3hfwel24EfGCspQqWsF1P%2Bfz%2BEU%3D&reserved=0
> but couldn't decide as that is based upon
> > the operator approach.
> >
> > Any thoughts would be appreciated.
> >
> > Regards
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>

artemis slave errors | jgroups | k8s

2023-03-15 Thread prateekjai...@gmail.com

Hi All,

How are you? I am a bit confused about the errors reported by artemis slave
instance (running in clustered mode using jgroups). I might be missing
something here so please bear with me.

Deployment details: I am running 2 pods of artemis in master/slave
configuration in k8s. It supports NFS v4. I am using jgroups configuration
(same file which is supplied in examples of artemis) and I can see that
correct pod names and IPs are updated in share directory

output from jgroups file
root@jms-01-deployment-6d7dcb8ccd-2t9g2:/opt# cat
/usr/share/artemis-jgroups/active_broadcast_channel/ab62408d-6a7a-4894-9923-2649d8bf3b28.jms-01-deployment-6d7dcb8ccd-2t9g2-29095.list

jms-01-deployment-6d7dcb8ccd-2t9g2-29095
ab62408d-6a7a-4894-9923-2649d8bf3b28 192.168.48.154:7800 T
jms-01-deployment-6d7dcb8ccd-j7pxl-34353
5b3d099b-8e5f-4dd0-ab43-604ad1ae87c3 192.168.199.2:7800 F

POD "jms-01-deployment-6d7dcb8ccd-2t9g2" is the master and another is
slave. Correct POD ips are listed there. But in log/artemis.log file of
slave pod, I see these logs

---
2023-03-15 11:29:51,519 ERROR [org.apache.activemq.artemis.core.client]
AMQ214016: Failed to create netty connection
java.net.UnknownHostException: jms-01-deployment-6d7dcb8ccd-2t9g2
at java.net.InetAddress$CachedAddresses.get(InetAddress.java:797) ~[?:?]
at java.net.InetAddress.getAllByName0(InetAddress.java:1524) ~[?:?]
at java.net.InetAddress.getAllByName(InetAddress.java:1382) ~[?:?]
---

jgroups is correctly creating and updating files. IPs of master/slave pods
are visible from each other. I have tested them using command

"./artemis check node".
Right now I have created deployment objects. Is it necessary to create
stateful sets?

Am I missing something here? Let me know if you need more information on
this.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

Re: artemis slave errors | jgroups | k8s

2023-03-15 Thread prateekjai...@gmail.com

.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
~[artemis-commons-2.28.0.jar:?]
2023-03-15 10:04:10,868 ERROR [org.apache.activemq.artemis.core.client]
AMQ214016: Failed to create netty connection
java.net.UnknownHostException: jms-01-deployment-6d7dcb8ccd-2t9g2
at java.net.InetAddress$CachedAddresses.get(InetAddress.java:797)
~[?:?]
at java.net.InetAddress.getAllByName0(InetAddress.java:1524) ~[?:?]
at java.net.InetAddress.getAllByName(InetAddress.java:1382) ~[?:?]
at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]

IMO, I need to find some way in which the pod name resolves to pod ip. If
you have any recommendations, let me know.

Regards,
Prateek Jain


--
EXPECTATION : Causes all troubles..
--


On Wed, Mar 15, 2023 at 2:23 PM Justin Bertram  wrote:

> ActiveMQ Artemis offers JGroups integration for cloud use-cases such as
> yours, but, generally speaking, we don't really provide support for JGroups
> in the ActiveMQ community since we don't maintain the JGroups code-base and
> don't know its inner workings.
>
> That said, I would suggest that the JGroups configuration using FILE_PING
> shipped in the examples may not be the best for your use-case. We chose the
> FILE_PING configuration because it was the simplest for the use-cases in
> the examples (i.e. where all the nodes are running on the same machine on
> different ports with access to the same disk). However, something like
> KUBE_PING [1] would probably be a better fit for your use-case since you
> are, in fact, using Kubernetes.
>
> In any event, it's hard to comment on what may be happening without more
> information. You've only provided a snippet of the stack-trace for the
> UnknownHostException so it's not clear what class is actually attempting
> that operation.
>
>
> Justin
>
> [1] https://github.com/jgroups-extras/jgroups-kubernetes
>
> On Wed, Mar 15, 2023 at 7:27 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi All,
> >
> > How are you? I am a bit confused about the errors reported by artemis
> slave
> > instance (running in clustered mode using jgroups). I might be missing
> > something here so please bear with me.
> >
> > Deployment details: I am running 2 pods of artemis in master/slave
> > configuration in k8s. It supports NFS v4. I am using jgroups
> configuration
> > (same file which is supplied in examples of artemis) and I can see that
> > correct pod names and IPs are updated in share directory
> >
> >  output from jgroups file 
> > root@jms-01-deployment-6d7dcb8ccd-2t9g2:/opt# cat
> >
> >
> /usr/share/artemis-jgroups/active_broadcast_channel/ab62408d-6a7a-4894-9923-2649d8bf3b28.jms-01-deployment-6d7dcb8ccd-2t9g2-29095.list
> >
> > jms-01-deployment-6d7dcb8ccd-2t9g2-29095
> > ab62408d-6a7a-4894-9923-2649d8bf3b28 192.168.48.154:7800 T
> > jms-01-deployment-6d7dcb8ccd-j7pxl-34353
> > 5b3d099b-8e5f-4dd0-ab43-604ad1ae87c3 192.168.199.2:7800 F
> > 
> >
> > POD "jms-01-deployment-6d7dcb8ccd-2t9g2" is the master and another is
> > slave. Correct POD ips are listed there. But in log/artemis.log file of
> > slave pod, I see these logs
> >
> > ---
> > 2023-03-15 11:29:51,519 ERROR [org.apache.activemq.artemis.core.client]
> > AMQ214016: Failed to create netty connection
> > java.net.UnknownHostException: jms-01-deployment-6d7dcb8ccd-2t9g2
> > at java.net.InetAddress$CachedAddresses.get(InetAddress.java:797) ~[?:?]
> > at java.net.InetAddress.getAllByName0(InetAddress.java:1524) ~[?:?]
> > at java.net.InetAddress.getAllByName(InetAddress.java:1382) ~[?:?]
> > ---
> >
> > jgroups is correctly creating and updating files. IPs of master/slave
> pods
> > are visible from each other. I have tested them using command
> >
> > "./artemis check node".
> > Right now I have created deployment objects. Is it necessary to create
> > stateful sets?
> >
> > Am I missing something here? Let me know if you need more information on
> > this.
> >
> >
> > Regards,
> > Prateek Jain
> >
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>

Re: artemis slave errors | jgroups | k8s

2023-03-15 Thread prateekjai...@gmail.com

Hi All,

 I am able to fix this issue. Posting my solution here, just in case anyone
else faces a similar issue. I converted deployment to a statefulset (to get
predictable names). Then used headless services for each pod. This enabled
both master and slave pods to lookup each other just by pod name. In case
anyone is looking for more details, feel free to connect.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Wed, Mar 15, 2023 at 3:54 PM prateekjai...@gmail.com <
prateekjai...@gmail.com> wrote:

>
> Hi Justin,
>
>  Thanks for replying, I think artemis is failing to lookup POD by its name
> because we cannot just get POD IP just by its name. Given below is the
> error which is getting repeated in logs:
>
> 2023-03-15 10:04:06,611 INFO  [org.apache.activemq.artemis] AMQ241002:
> Artemis Jolokia REST API available at
> http://jms-01-deployment-6d7dcb8ccd-j7pxl:8161/console/jolokia
> 2023-03-15 10:04:06,611 INFO  [org.apache.activemq.artemis] AMQ241004:
> Artemis Console available at
> http://jms-01-deployment-6d7dcb8ccd-j7pxl:8161/console
> 2023-03-15 10:04:10,868 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214016: Failed to create netty connection
> java.net.UnknownHostException: jms-01-deployment-6d7dcb8ccd-2t9g2
> at java.net.InetAddress$CachedAddresses.get(InetAddress.java:797)
> ~[?:?]
> at java.net.InetAddress.getAllByName0(InetAddress.java:1524) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1382) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:156)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:153)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at java.security.AccessController.doPrivileged(Native Method)
> ~[?:?]
> at
> io.netty.util.internal.SocketUtils.addressByName(SocketUtils.java:153)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.DefaultNameResolver.doResolve(DefaultNameResolver.java:41)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:61)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.SimpleNameResolver.resolve(SimpleNameResolver.java:53)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:55)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.InetSocketAddressResolver.doResolve(InetSocketAddressResolver.java:31)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.resolver.AbstractAddressResolver.resolve(AbstractAddressResolver.java:106)
> ~[netty-resolver-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:206)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at io.netty.bootstrap.Bootstrap.access$000(Bootstrap.java:46)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:180)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.bootstrap.Bootstrap$1.operationComplete(Bootstrap.java:166)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:557)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.setSuccess0(DefaultPromise.java:625)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:105)
> ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:84)
> ~[netty-transport-4.1.86.Final.jar:4.1.86.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe

Re: disconnect recovery issue

2023-03-24 Thread prateekjai...@gmail.com

Yes, I too faced similar issues while randomly killing artemis instances.
The pattern which I observed was mainly, when you kill live instances in a
cluster w/o running backup node. So, in our case we incorporated *client
side failover* detection. IMO, most of the times; failover happens
transparently when going from live to backup nodes. But at the same time,
we couldn't replicate it everytime. So, to keep things save; it is better
to have a safety net designed.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Thu, Mar 23, 2023 at 8:27 PM John Lilley
 wrote:

> We’ve added a chaos monkey to randomly disconnect Artemis clients from
> broker.
>
> This mostly works, however, we do get occasional errors that are not
> retried by the AMQ JMS client.
>
> This manifests with the exception: AMQ219016: Connection failure detected.
> Unblocking a blocking call that will never get a response.
>
> I don’t know why the AMQ client thinks it will never get a response.
> Shouldn’t the client reconnect and continue without error?  Do we need to
> retry explicitly?
>
>
>
> This is using version 2.28.0.  Example stack trace:
>
>
>
> 2023-03-23T14:19:54.666 [Schedule-Runner] LazyStartPeriodicThread.run:97
> [] ERROR - Exception in interval action RpcException: httpCode=500,
> errorMessage=error sending message: AMQ219016: Connection failure detected.
> Unblocking a blocking call that will never get a response
>
> errorFrames:
>
> javax.jms.JMSException: AMQ219016: Connection failure detected. Unblocking
> a blocking call that will never get a response
>
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:558)
>
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:450)
>
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendFullMessage(ActiveMQSessionContext.java:583)
>
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:305)
>
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:277)
>
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:147)
>
> at
> org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:129)
>
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:483)
>
> at
> org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:221)
>
> at net.redpoint.ipc.jms.JmsProducerPool.send_(JmsProducerPool.java:351)
>
> at
> net.redpoint.ipc.jms.JmsProducerPool.sendRequest(JmsProducerPool.java:289)
>
> at
> net.redpoint.ipc.jms.JmsRpcClientChannel.sendRequest(JmsRpcClientChannel.java:217)
>
> at
> net.redpoint.ipc.jms.JmsRpcClientChannel.invokeRaw(JmsRpcClientChannel.java:194)
>
> at
> net.redpoint.ipc.jms.JmsRpcClientChannel.call(JmsRpcClientChannel.java:98)
>
> at net.redpoint.ipc.clients.RpcClientBase._sync(RpcClientBase.java:165)
>
> at net.redpoint.ipc.clients.RpcClientBase._rpc(RpcClientBase.java:231)
>
> at
> net.redpoint.rpdm.ipc.clients.PermissionsClient.doesUserHavePermission(PermissionsClient.java:178)
>
> at
> net.redpoint.rpdm.services.SecurityControlImpl.doesUserHavePermission(SecurityControlImpl.java:205)
>
> at
> net.redpoint.ipc.SecurityControl.checkUserHasPermission(SecurityControl.java:387)
>
> at
> net.redpoint.rpdm.ipc.servers.SchedulerServer.checkUserHasPermission(SchedulerServer.java:325)
>
> at
> net.redpoint.rpdm.ipc.servers.SchedulerServer.list(SchedulerServer.java:264)
>
> at
> net.redpoint.rpdm.scheduler.SchedulerlServerImpl._doSchedule(SchedulerlServerImpl.java:407)
>
> at
> net.redpoint.rpdm.scheduler.SchedulerlServerImpl.doSchedule(SchedulerlServerImpl.java:360)
>
> at
> net.redpoint.rpdm.scheduler.SchedulerlServerImpl$Runner.lambda$action$0(SchedulerlServerImpl.java:511)
>
> at net.redpoint.ipc.SecurityControl.runAsNoThrow(SecurityControl.java:315)
>
> at
> net.redpoint.rpdm.scheduler.SchedulerlServerImpl$Runner.action(SchedulerlServerImpl.java:510)
>
> at
> net.redpoint.rpdm.services.LazyStartPeriodicThread.run(LazyStartPeriodicThread.java:95)
>
> at java.base/java.lang.Thread.run(Thread.java:833)
>
> Caused by: ActiveMQUnBlockedException[errorType=UNBLOCKED
> message=AMQ219016: Connection failure detected. Unblocking a blocking call
> that will never get a response]
>
> ... 28 more
>
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED
> message=AMQ219006: Channel disconnected]
>
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:383)
>
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1240)
>

custom settings in broker.xml

Hi All,

 My requirement is to start/create a new broker with custom settings which
are specified in the broker.xml file. These settings include things like,

1. Specifying/adding new queues and topics.
2. Specifying custom broadcast settings like jgroups settings

 
  
5000

* test-jgroups_ping.xml
active_broadcast_channel*
artemis
 
 

3. Specifying address settings like,
0

 I saw some threads like
https://stackoverflow.com/questions/71149959/how-to-provide-a-custom-broker-xml-to-activemq-artemis-broker-instance

But answer provided doesn't run.

Any clues, how this can be achieved? Any command line flags that can be
used to achieve the same, for example I found this,

./artemis create test-broker-01 \
--http-host $HOSTNAME \
--host $HOSTNAME \
--aio \
--clustered \
--cluster-user administrator \
--cluster-password TestPassw0rd \
--name live-broker-01 \
--max-hops 1 \
--user administrator \
--password TestPassw0rd \
--require-login \
--port-offset 0 \
--no-autocreate \
--data /usr/shared/artemis-data/$HOSTNAME \
--shared-store \
--failover-on-shutdown


Regards,

Prateek Jain
--
EXPECTATION : Causes all troubles..
--

Re: custom settings in broker.xml

Hi Justin,

  Yes, I could have done that but I wanted to know if there are straight
forward ways of doing such things. Just for the sake of other/future users,
I found an approach of achieving this in a project on github

https://deviceinsight.github.io/activemq-artemis-helm


Although, I wont be using it as-it-is but yes, it does answer most of my
questions.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 27, 2023 at 3:22 PM Justin Bertram  wrote:

> The "create" command only supports a handful of customizable configuration
> options. It is meant to be a simple tool to perform simple customizations.
>
> For more advanced use-cases you simply need to provide your own broker.xml.
> I recommend you use the "create" command to create a default broker.xml and
> then modify it as needed. Then you can save that and copy it to any
> instance you need. It should be really straightforward.
>
>
> Justin
>
> On Mon, Mar 27, 2023 at 7:02 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi All,
> >
> >  My requirement is to start/create a new broker with custom settings
> which
> > are specified in the broker.xml file. These settings include things like,
> >
> > 1. Specifying/adding new queues and topics.
> > 2. Specifying custom broadcast settings like jgroups settings
> >
> >  
> >   
> > 5000
> >
> > * test-jgroups_ping.xml
> > active_broadcast_channel*
> > artemis
> >  
> >  
> >
> > 3. Specifying address settings like,
> > 0
> >
> >  I saw some threads like
> >
> >
> https://stackoverflow.com/questions/71149959/how-to-provide-a-custom-broker-xml-to-activemq-artemis-broker-instance
> >
> > But answer provided doesn't run.
> >
> > Any clues, how this can be achieved? Any command line flags that can be
> > used to achieve the same, for example I found this,
> >
> > ./artemis create test-broker-01 \
> > --http-host $HOSTNAME \
> > --host $HOSTNAME \
> > --aio \
> > --clustered \
> > --cluster-user administrator \
> > --cluster-password TestPassw0rd \
> > --name live-broker-01 \
> > --max-hops 1 \
> > --user administrator \
> > --password TestPassw0rd \
> > --require-login \
> > --port-offset 0 \
> > --no-autocreate \
> > --data /usr/shared/artemis-data/$HOSTNAME \
> > --shared-store \
> > --failover-on-shutdown
> >
> >
> > Regards,
> >
> > Prateek Jain
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>

Re: Co Located Backups Question

Hi Roy,

 I dont exactly know your usecase or constraints but IMO, shared store
would have been a better option. As I didnt worked/explored 1.x version so,
wont comment on it. But you should be able to reference examples under
artemis directory:

   *examples\features\ha\colocated-failover*

Hope it helps.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 27, 2023 at 3:27 PM Roy Cohen  wrote:

> Anyone has any thoughts on the below ?
>
> On 23 Mar 2023, at 12:37, Roy Cohen  wrote:
>
>  Hello everyone
>
> We have a setup of three Artemis brokers (very old version don’t ask :))
>
> We would like to configure the co located backups such that the backups
> are sent in this order:
>
> Broker01 -> Broker02
> Broker02 -> Broker03
> Broker03 -> Broker01
>
>
> I was reading on co located backups here:
> https://activemq.apache.org/components/artemis/documentation/1.0.0/ha.html
> however not sure I fully understand how to configure the xml section to
> achieve that.
>
> Shall I add excludes in each broker, i.e.
>
>   
>  
> ...
>  
>
> Any help would be appreciated.
>
> Many thanks in advance !
>
>
>

Re: Co Located Backups Question

IMO, the only change would be changing broker (61616 to something like
61618) port. I would expect everything should work after that.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Mar 27, 2023 at 3:56 PM Roy Cohen  wrote:

> Hi Prateek
>
> Thanks, however that example is for two brokers, which we already have
> working.
>
> We are now adding a third broker to the cluster and want to understand how
> to change the co located backups according to my original post.
>
> Is that possible ?
>
> Regards
> Roy
>
>
>
>
> > On 27 Mar 2023, at 15:46, prateekjai...@gmail.com wrote:
> >
> > Hi Roy,
> >
> > I dont exactly know your usecase or constraints but IMO, shared store
> > would have been a better option. As I didnt worked/explored 1.x version
> so,
> > wont comment on it. But you should be able to reference examples under
> > artemis directory:
> >
> >   *examples\features\ha\colocated-failover*
> >
> > Hope it helps.
> >
> > Regards,
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
> >
> > On Mon, Mar 27, 2023 at 3:27 PM Roy Cohen  wrote:
> >
> >> Anyone has any thoughts on the below ?
> >>
> >> On 23 Mar 2023, at 12:37, Roy Cohen  wrote:
> >>
> >>  Hello everyone
> >>
> >> We have a setup of three Artemis brokers (very old version don’t ask :))
> >>
> >> We would like to configure the co located backups such that the backups
> >> are sent in this order:
> >>
> >> Broker01 -> Broker02
> >> Broker02 -> Broker03
> >> Broker03 -> Broker01
> >>
> >>
> >> I was reading on co located backups here:
> >>
> https://activemq.apache.org/components/artemis/documentation/1.0.0/ha.html
> >> however not sure I fully understand how to configure the xml section to
> >> achieve that.
> >>
> >> Shall I add excludes in each broker, i.e.
> >>
> >>  
> >> 
> >>...
> >> 
> >>
> >> Any help would be appreciated.
> >>
> >> Many thanks in advance !
> >>
> >>
> >>
>
>

jmslistener | message routing

2023-04-06 Thread prateekjai...@gmail.com

Hi All,

  I am running 6 brokers/instances of artemis ( 3 master/live, 3 slave).
While sending messages to them, everything works fine as messages are
loadbalanced. For example, if I send 1000 messages each node will get 333.
All 3 master/live nodes form a cluster and I can see that via the web
console.

 I am facing an issue while trying to receive those messages, it appears
that I am only getting messages that got delivered to connected node only.
I am using code like below:


@JmsListener(destination = "exampleQueue", containerFactory =
"jmsListenerContainerFactory")
 public void myMessageReceiver(Message msg) {
  messageCounter++;
}
-

@Bean

public JmsListenerContainerFactory jmsListenerContainerFactory() {

DefaultJmsListenerContainerFactory factory = new
DefaultJmsListenerContainerFactory();

factory.setConnectionFactory(connectionFactory());

return factory;

}

@Bean

public ConnectionFactory connectionFactory() {

return new ActiveMQConnectionFactory(this.brokerUrl, this.brokerUserName,
this.brokerPassword);

}

-

value of broker.url in application.properties is

broker.url=
(tcp://jms-master-0:61616,tcp://jms-master1-0:61616,tcp://jms-master2-0:61616,tcp://jms-slave-0:61616,tcp://jms-slave1-0:61616,tcp://jms-slave2-0:61616)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1


Also, I have added following line to ""

0


My expectation was, all messages on exampleQueue from other nodes would get
routed to this node; where the consumer is connected. Am I missing
something here?

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

Re: jmslistener | message routing

2023-04-07 Thread prateekjai...@gmail.com

STRICT

Is the value in broker.xml

On Fri 7 Apr 2023, 09:54 Roskvist Anton,  wrote:

> Hello,
>
> In your cluster configuration, what "message-load-balancing"-type have you
> configured?
>
> Br,
> Anton
>
> This email message (including its attachments) is confidential and may
> contain privileged information and is intended solely for the use of the
> individual and/or entity to whom it is addressed. If you are not the
> intended recipient of this e-mail you may not disseminate, distribute or
> copy this e-mail (including its attachments), or any part thereof. If this
> e-mail is received in error, please notify the sender immediately by return
> e-mail and make sure that this e-mail (including its attachments), and all
> copies thereof, are immediately deleted from your system. Please further
> note that when you communicate with us via email or visit our website we
> process your personal data. See our privacy policy for more information
> about how we process it: https://www.volvogroup.com/en-en/privacy.html
>

Re: jmslistener | message routing

2023-04-07 Thread prateekjai...@gmail.com

Hi Roskvist,

 I tried the ON_DEMAND value but still it doesnt work. Infact, with
on_demand value the loadbalancing stops and the whole scalability feature
in the cluster becomes irrelevant.

 IMO, if the client for a queue/topic is connected to any of the broker
instances then; messages should get routed to it. So, in nutshell; what I
am trying to achieve here is -

1. Deploy cluster in such a way that it should be easy to scale.
2. Scalability should be transparent to the client code. Clients should
only know about broker IPs and Ports.
3. A Client should be able to send and receive messages w/o taking into
consideration; to which broker they are connected to.

I am able to achieve most of them. It is only the receiving part which is
not working as desired. In the clustered queue example, something very
similar is achieved but it requires, client to be connected to both
instances. But in my case, I am trying to achieve it by connecting to any
instance (live) in the cluster.

Regards,
Prateek

On Fri 7 Apr 2023, 12:56 Roskvist Anton,  wrote:

> Right, so as far as I am aware the STRICT load balancing policy does not
> allow for message redistribution, it's purpose is to divide incoming
> messages evenly across the cluster regardless of client/consumer state.
> Perhaps ON_DEMAND might be better suited for your needs, or possibly
> OFF_WITH_REDISTRIBUTION and handling initial distribution of messages via
> client side load balancing?
>
> 
>
> This email message (including its attachments) is confidential and may
> contain privileged information and is intended solely for the use of the
> individual and/or entity to whom it is addressed. If you are not the
> intended recipient of this e-mail you may not disseminate, distribute or
> copy this e-mail (including its attachments), or any part thereof. If this
> e-mail is received in error, please notify the sender immediately by return
> e-mail and make sure that this e-mail (including its attachments), and all
> copies thereof, are immediately deleted from your system. Please further
> note that when you communicate with us via email or visit our website we
> process your personal data. See our privacy policy for more information
> about how we process it: https://www.volvogroup.com/en-en/privacy.html
>

Re: jmslistener | message routing

2023-04-10 Thread prateekjai...@gmail.com

Hi Justin,

 Thanks for replying. There is a reason why I don't want to create a
consumer per broker/instance of artemis. I am trying to come up with an
architecture for a product where an artemis cluster can expand or shrink
but it shouldn't have any impact on client code.

Considering the suggested approach, client code has to be updated according
to the size of the cluster. So, I was thinking, could this be possible that
client can connect to any of the broker and then messages could be routed
because consumers might not always be online. Consumers can connect once in
a while. This case becomes especially important, while upgrading clusers.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Apr 10, 2023 at 4:39 PM Justin Bertram  wrote:

> While it's true that with ON_DEMAND you don't get the same behavior as
> STRICT (as one would expect), you still get the benefit of load-balancing
> because messages will be initially distributed to nodes that have
> consumers. This is why it's called "on demand" - messages are distributed
> to where the consumers are rather than strictly round-robined across all
> cluster nodes.
>
> You can achieve 1, 2, & 3 with ON_DEMAND and a redistribution-delay > 0
> [1]. This is the most common configuration.
>
> That said, clustering is all about increasing overall message throughput
> via horizontal scaling. In order to optimize performance you really don't
> ever want to move messages between nodes as that adds latency. You want
> every node in the cluster to have enough consumers to process all the
> messages sent to that node. If that's not the case that's an indication
> that the cluster is, in fact, too large and you're wasting resources. I
> recently added a new section to the cluster documentation [2] discussing
> this very thing.
>
>
> Justin
>
> [1]
>
> https://activemq.apache.org/components/artemis/documentation/latest/clusters.html#message-redistribution
> [2]
>
> https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/clusters.md#performance-considerations
>
> On Fri, Apr 7, 2023 at 7:51 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi Roskvist,
> >
> >  I tried the ON_DEMAND value but still it doesnt work. Infact, with
> > on_demand value the loadbalancing stops and the whole scalability feature
> > in the cluster becomes irrelevant.
> >
> >  IMO, if the client for a queue/topic is connected to any of the broker
> > instances then; messages should get routed to it. So, in nutshell; what I
> > am trying to achieve here is -
> >
> > 1. Deploy cluster in such a way that it should be easy to scale.
> > 2. Scalability should be transparent to the client code. Clients should
> > only know about broker IPs and Ports.
> > 3. A Client should be able to send and receive messages w/o taking into
> > consideration; to which broker they are connected to.
> >
> > I am able to achieve most of them. It is only the receiving part which is
> > not working as desired. In the clustered queue example, something very
> > similar is achieved but it requires, client to be connected to both
> > instances. But in my case, I am trying to achieve it by connecting to any
> > instance (live) in the cluster.
> >
> > Regards,
> > Prateek
> >
> >
> > On Fri 7 Apr 2023, 12:56 Roskvist Anton, 
> wrote:
> >
> > > Right, so as far as I am aware the STRICT load balancing policy does
> not
> > > allow for message redistribution, it's purpose is to divide incoming
> > > messages evenly across the cluster regardless of client/consumer state.
> > > Perhaps ON_DEMAND might be better suited for your needs, or possibly
> > > OFF_WITH_REDISTRIBUTION and handling initial distribution of messages
> via
> > > client side load balancing?
> > >
> > > 
> > >
> > > This email message (including its attachments) is confidential and may
> > > contain privileged information and is intended solely for the use of
> the
> > > individual and/or entity to whom it is addressed. If you are not the
> > > intended recipient of this e-mail you may not disseminate, distribute
> or
> > > copy this e-mail (including its attachments), or any part thereof. If
> > this
> > > e-mail is received in error, please notify the sender immediately by
> > return
> > > e-mail and make sure that this e-mail (including its attachments), and
> > all
> > > copies thereof, are immediately deleted from your system. Please
> further
> > > note that when you communicate with us via email or visit our website
> we
> > > process your personal data. See our privacy policy for more information
> > > about how we process it: https://www.volvogroup.com/en-en/privacy.html
> > >
> >
>

Re: jmslistener | message routing

2023-04-10 Thread prateekjai...@gmail.com

Hi Justin,

Our product is sold to clients based on load. They usually dont scale
up/down clusters (for scalability). And we dont want to make application
code dependent on cluster size. Because for some clients, there could be 2
node cluster but for some it could be 6 node cluster.

Regards,
Prateek Jain
--
EXPECTATION : Causes all troubles..
--


On Mon, Apr 10, 2023 at 6:45 PM Justin Bertram  wrote:

> I think perhaps you misunderstood what I was recommending. You shouldn't
> need to adjust any client code. You certainly don't *need* to create a
> consumer on every node of the cluster as you imply. Using ON_DEMAND with a
> redistribution-delay > 0 will allow clients to connect to any node of the
> cluster and consume messages sent to any other node in the cluster - at any
> time.
>
> My point was that in order to optimize performance (i.e. the whole point of
> clustering in the first place) then you should to size your cluster based
> on the actual client load. To reiterate, if you don't have enough clients
> to avoid moving messages between cluster nodes then your cluster is likely
> too large. Another way to think about it is that if consumers are starving
> then your cluster is likely too large. Again, this goes back to using your
> resources effectively and efficiently. This is especially important in
> cloud use-cases where you may be paying by the hour to use a machine that
> isn't really necessary, but it's also important for bare-metal uses-cases
> as well to avoid expenditure to acquire the nodes in the first place. The
> simplest architecture possible is always preferable as it reduces costs for
> development, deployment, and maintenance.
>
> If you're using a cluster of 3 pairs simply to establish a quorum to avoid
> split-brain with replication then switch to the pluggable quorum voting and
> use ZooKeeper instead.
>
>
> Justin
>
> On Mon, Apr 10, 2023 at 11:57 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi Justin,
> >
> >  Thanks for replying. There is a reason why I don't want to create a
> > consumer per broker/instance of artemis. I am trying to come up with an
> > architecture for a product where an artemis cluster can expand or shrink
> > but it shouldn't have any impact on client code.
> >
> > Considering the suggested approach, client code has to be updated
> according
> > to the size of the cluster. So, I was thinking, could this be possible
> that
> > client can connect to any of the broker and then messages could be routed
> > because consumers might not always be online. Consumers can connect once
> in
> > a while. This case becomes especially important, while upgrading clusers.
> >
> > Regards,
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
> >
> > On Mon, Apr 10, 2023 at 4:39 PM Justin Bertram 
> > wrote:
> >
> > > While it's true that with ON_DEMAND you don't get the same behavior as
> > > STRICT (as one would expect), you still get the benefit of
> load-balancing
> > > because messages will be initially distributed to nodes that have
> > > consumers. This is why it's called "on demand" - messages are
> distributed
> > > to where the consumers are rather than strictly round-robined across
> all
> > > cluster nodes.
> > >
> > > You can achieve 1, 2, & 3 with ON_DEMAND and a redistribution-delay > 0
> > > [1]. This is the most common configuration.
> > >
> > > That said, clustering is all about increasing overall message
> throughput
> > > via horizontal scaling. In order to optimize performance you really
> don't
> > > ever want to move messages between nodes as that adds latency. You want
> > > every node in the cluster to have enough consumers to process all the
> > > messages sent to that node. If that's not the case that's an indication
> > > that the cluster is, in fact, too large and you're wasting resources. I
> > > recently added a new section to the cluster documentation [2]
> discussing
> > > this very thing.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> > >
> >
> https://activemq.apache.org/components/artemis/documentation/latest/clusters.html#message-redistribution
> > >

Re: jmslistener | message routing

2023-04-10 Thread prateekjai...@gmail.com

Hi Justin,

 Yes, I can clarify the idea.

 The product is configured and sold based on the load it can handle. For
example, one client can come and ask for this product to handle 20K
requests but another client can ask for 200K requests. Here the load is
pre-determined by clients. Although the product is allowed to scale down
and up (if required) but while the product scales itself, it should prove
that it is safe to do so and ask for verification. This rarely happens in
production.

 My issue here while trying to test *ON_DEMAND* policy is, it is hard to
show/see scalability working. I am not sure after how many messages/load,
it decides to send messages to another artemis instance. We want cluster
resources to be used fairly. With the ON_DEMAND policy, I am afraid that it
will lead to higher usage of some instances than others. For example,

If we are using this url connection string

 tcp(node1:61611),tcp(node2:61616), tcp(node3:61616)

then node1 might be loaded as compared to node3.

Let me know if I am missing something here.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Mon, Apr 10, 2023 at 9:01 PM Justin Bertram  wrote:

> No one is suggesting that you make your application code dependent on
> cluster size. I'm not sure where you're getting that idea.
>
> As noted, using ON_DEMAND with a redistribution-delay > 0 will allow
> clients to connect to any node of the cluster and consume messages sent to
> any other node in the cluster - at any time. This is the most flexible
> configuration for your clients as it makes them completely agnostic about
> the size of the cluster.
>
> I'm not sure what you mean that your clients don't scale the cluster up or
> down "for scalability." Can you clarify this?
>
>
> Justin
>
> On Mon, Apr 10, 2023 at 2:31 PM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi Justin,
> >
> > Our product is sold to clients based on load. They usually dont scale
> > up/down clusters (for scalability). And we dont want to make application
> > code dependent on cluster size. Because for some clients, there could be
> 2
> > node cluster but for some it could be 6 node cluster.
> >
> > Regards,
> > Prateek Jain
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
> >
> > On Mon, Apr 10, 2023 at 6:45 PM Justin Bertram 
> > wrote:
> >
> > > I think perhaps you misunderstood what I was recommending. You
> shouldn't
> > > need to adjust any client code. You certainly don't *need* to create a
> > > consumer on every node of the cluster as you imply. Using ON_DEMAND
> with
> > a
> > > redistribution-delay > 0 will allow clients to connect to any node of
> the
> > > cluster and consume messages sent to any other node in the cluster - at
> > any
> > > time.
> > >
> > > My point was that in order to optimize performance (i.e. the whole
> point
> > of
> > > clustering in the first place) then you should to size your cluster
> based
> > > on the actual client load. To reiterate, if you don't have enough
> clients
> > > to avoid moving messages between cluster nodes then your cluster is
> > likely
> > > too large. Another way to think about it is that if consumers are
> > starving
> > > then your cluster is likely too large. Again, this goes back to using
> > your
> > > resources effectively and efficiently. This is especially important in
> > > cloud use-cases where you may be paying by the hour to use a machine
> that
> > > isn't really necessary, but it's also important for bare-metal
> uses-cases
> > > as well to avoid expenditure to acquire the nodes in the first place.
> The
> > > simplest architecture possible is always preferable as it reduces costs
> > for
> > > development, deployment, and maintenance.
> > >
> > > If you're using a cluster of 3 pairs simply to establish a quorum to
> > avoid
> > > split-brain with replication then switch to the pluggable quorum voting
> > and
> > > use ZooKeeper instead.
> > >
> > >
> > > Justin
> > >
> > > On Mon, Apr 10, 2023 at 11:57 AM prateekjai...@gmail.com <
> > > prateekjai...@gmail.com> wrote:
> > >
> > > > Hi Justin,
> > > >
> > > >  Thanks

Re: Artemis Version 2.28.0

2023-06-01 Thread prateekjai...@gmail.com

seems like you have enabled security or it is not properly configured in
the cluster.

Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Thu, Jun 1, 2023 at 1:27 PM Shivang Modi  wrote:

> Hi Team,
>
>
>
> I am upgrading my application from activemq to artemis 2.28.0 version and I
> am getting below error in one of microservice. Can you help me with same
>
>
>
> javax.jms.JMSException: Could not connect to broker URL: tcp://queue:61616.
> Reason: java.net.ConnectException: Connection refused (Connection refused)
>
> at
>
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
>
> at
>
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:374)
>
> at
>
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:304)
>
> at
>
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:244)
>
> at
>
> org.springframework.boot.actuate.jms.JmsHealthIndicator.doHealthCheck(JmsHealthIndicator.java:52)
>
> at
>
> org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:82)
>
> at
>
> org.springframework.boot.actuate.health.HealthIndicator.getHealth(HealthIndicator.java:37)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointWebExtension.getHealth(HealthEndpointWebExtension.java:85)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointWebExtension.getHealth(HealthEndpointWebExtension.java:44)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointSupport.getContribution(HealthEndpointSupport.java:99)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointSupport.getAggregateHealth(HealthEndpointSupport.java:110)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointSupport.getContribution(HealthEndpointSupport.java:96)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointSupport.getHealth(HealthEndpointSupport.java:74)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointSupport.getHealth(HealthEndpointSupport.java:61)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointWebExtension.health(HealthEndpointWebExtension.java:71)
>
> at
>
> org.springframework.boot.actuate.health.HealthEndpointWebExtension.health(HealthEndpointWebExtension.java:60)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at
>
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282)
>
> at
>
> org.springframework.boot.actuate.endpoint.invoke.reflect.ReflectiveOperationInvoker.invoke(ReflectiveOperationInvoker.java:77)
>
> at
>
> org.springframework.boot.actuate.endpoint.annotation.AbstractDiscoveredOperation.invoke(AbstractDiscoveredOperation.java:60)
>
> at
>
> org.springframework.boot.actuate.endpoint.web.servlet.AbstractWebMvcEndpointHandlerMapping$ServletWebOperationAdapter.handle(AbstractWebMvcEndpointHandlerMapping.java:305)
>
> at
>
> org.springframework.boot.actuate.endpoint.web.servlet.AbstractWebMvcEndpointHandlerMapping$OperationHandler.handle(AbstractWebMvcEndpointHandlerMapping.java:388)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at
>
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
>
> at
>
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
>
> at
>
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:105)
>
> at
>
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:878)
>
> at
>
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:792)
>
> at
>
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
>
> at
>
> org.springframework.web.servlet.DispatcherSe

Clustering | diverts

2023-06-11 Thread prateekjai...@gmail.com

Hi All,

 I have a question on the behavior of diverts in activemq. Here is what I
read in documentation:

*A divert will only divert a message to an address on the same server. If
you want to divert to an address on a different server, a common pattern
would be to divert to a local store-and-forward queue, then set up a bridge
that consumes from that queue and forwards to an address on a different
server.*

My query is, if we have a cluster setup where message re-distribution is
happening between activemq nodes. What is the expected behavior? Will the
messages get routed to nodes where consumers are attached or they endup on
the same server/node?

 In my case, I see that routing is not happening. Anything that can be done
in a generic way which would enable redistribution for all diverts in the
same cluster?

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

Re: Clustering | diverts

2023-06-13 Thread prateekjai...@gmail.com

Hi Justin,

 Thanks for responding, in my scenario; I have created a cluster of 2
activemq instances (active/active). Both are on physically different nodes
but they are running in cluster. Now, for normal queues; redistribution is
happening properly. But I read this description about diverts

*A divert will only divert a message to an address on the same server. If
you want to divert to an address on a different server, a common pattern
would be to divert to a local store-and-forward queue, then set up a bridge
that consumes from that queue and forwards to an address on a different
server.*

As per my understanding of the above paragraph, messages sent to the
destination of a divert will endup on the same activemq instance. They
won't be *redistributed *even if a consumer is present on another node. A
bridge has to be set up for this. If my understanding is correct, I just
wanted to know, if there is some generic mechanism that can be implemented
to achieve the same. So that we dont have to set up a separate bridge for
each queue.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

On Mon, Jun 12, 2023 at 3:35 PM Justin Bertram  wrote:

> I don't understand how divert behavior and message redistribution are
> related in your use-case. Can you elaborate on this?
>
>
> Justin
>
> On Sun, Jun 11, 2023 at 5:54 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi All,
> >
> >  I have a question on the behavior of diverts in activemq. Here is what I
> > read in documentation:
> >
> > *A divert will only divert a message to an address on the same server. If
> > you want to divert to an address on a different server, a common pattern
> > would be to divert to a local store-and-forward queue, then set up a
> bridge
> > that consumes from that queue and forwards to an address on a different
> > server.*
> >
> > My query is, if we have a cluster setup where message re-distribution is
> > happening between activemq nodes. What is the expected behavior? Will the
> > messages get routed to nodes where consumers are attached or they endup
> on
> > the same server/node?
> >
> >  In my case, I see that routing is not happening. Anything that can be
> done
> > in a generic way which would enable redistribution for all diverts in the
> > same cluster?
> >
> > Regards,
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>

activemq | cluster | metrics

Hi All,

 I am working on an application which is right now running a single
instance of activemq. Now, due to increase in load and to improve
availability; I am testing active/active cluster topology of activemq. I
am successfully running a cluster (active/active) now.

 My question is, what are the key metrics that can be looked at from the
observability perspective of this cluster. Basically, I am looking at areas
that can be looked at, if I suspect that it is clustering which is causing
the issue or, to prove that clustering functionality is not at fault. Any
suggestions are welcome.


Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--

Re: activemq | cluster | metrics

Thanks a lot, Erwin! Yes, we do have a JMX based metrics setup. I will
compare and see if we are missing anything from a cluster metric
perspective.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Fri, Jul 7, 2023 at 12:35 PM Dondorp, Erwin
 wrote:

> Prateek,
>
> Due to the design of the Artemis GUI, all data that you can see there can
> be retrieved using:
> * Java JMX
> * Jolokia (a REST interface on Java JMX)
>
> Additionally, you can use a Prometheus plugin to allow data collection.
> Many other applications (e.g. all java applications) use that, or have a
> plugin to use it.
> You need a data collector application to pick up all that data and store
> it in a (Prometheus) database.
> Then use Grafana dashboards for visualization. And you can choose to build
> alerting rules on this all.
> This allows a more common approach in your landscape.
>
> https://github.com/rh-messaging/artemis-prometheus-metrics-plugin
> my system just returned the following metrics for Prometheus:
> * artemis_address_memory_usage
> * artemis_address_memory_usage_percentage
> * artemis_address_size
> * artemis_connection_count
> * artemis_consumer_count
> * artemis_delivering_durable_message_count
> * artemis_delivering_durable_persistent_size
> * artemis_delivering_message_count
> * artemis_delivering_persistent_size
> * artemis_disk_store_usage
> * artemis_durable_message_count
> * artemis_durable_persistent_size
> * artemis_message_count
> * artemis_messages_acknowledged
> * artemis_messages_added
> * artemis_messages_expired
> * artemis_messages_killed
> * artemis_number_of_pages
> * artemis_persistent_size
> * artemis_routed_message_count
> * artemis_scheduled_durable_message_count
> * artemis_scheduled_durable_persistent_size
> * artemis_scheduled_message_count
> * artemis_scheduled_persistent_size
> * artemis_total_connection_count
> * artemis_unrouted_message_count
>
> Erwin
>
> -Original Message-
> From: prateekjai...@gmail.com 
> Sent: vrijdag 7 juli 2023 11:47
> To: users@activemq.apache.org
> Subject: activemq | cluster | metrics
>
>
> EXTERNAL SENDER:   Do not click any links or open any attachments unless
> you trust the sender and know the content is safe.
> EXPÉDITEUR EXTERNE:Ne cliquez sur aucun lien et n’ouvrez aucune pièce
> jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous
> ayez l'assurance que le contenu provient d'une source sûre.
>
> Hi All,
>
>  I am working on an application which is right now running a single
> instance of activemq. Now, due to increase in load and to improve
> availability; I am testing active/active cluster topology of activemq. I am
> successfully running a cluster (active/active) now.
>
>  My question is, what are the key metrics that can be looked at from the
> observability perspective of this cluster. Basically, I am looking at areas
> that can be looked at, if I suspect that it is clustering which is causing
> the issue or, to prove that clustering functionality is not at fault. Any
> suggestions are welcome.
>
>
> Regards,
> Prateek Jain
>
> --
> EXPECTATION : Causes all troubles..
> --
>

Re: activemq | cluster | metrics

Hi Justin,

 I am using a slightly older version of artemis (2.9.0). This is the
version which is used under jboss EAP version 7.3.

Regards,
Prateek Jain

--
EXPECTATION : Causes all troubles..
--


On Fri, Jul 7, 2023 at 1:28 PM Justin Bertram  wrote:

> What version of ActiveMQ are you using?
>
>
> Justin
>
> On Fri, Jul 7, 2023 at 4:47 AM prateekjai...@gmail.com <
> prateekjai...@gmail.com> wrote:
>
> > Hi All,
> >
> >  I am working on an application which is right now running a single
> > instance of activemq. Now, due to increase in load and to improve
> > availability; I am testing active/active cluster topology of activemq. I
> > am successfully running a cluster (active/active) now.
> >
> >  My question is, what are the key metrics that can be looked at from the
> > observability perspective of this cluster. Basically, I am looking at
> areas
> > that can be looked at, if I suspect that it is clustering which is
> causing
> > the issue or, to prove that clustering functionality is not at fault. Any
> > suggestions are welcome.
> >
> >
> > Regards,
> > Prateek Jain
> >
> > --
> > EXPECTATION : Causes all troubles..
> > --
> >
>

Re: activemq | cluster | metrics