extraproperties become string in expired messages

2021-11-12 Thread Dondorp, Erwin
Hello, On expiry of a (AMQP) message, some extra properties are added, which together with some application properties result in the table below, taken from screen "Browse Queue". The values from the "extraProperties" group of properties are all strings, which is unexpected for at least

Re: ArtemisMQ 2.15 Messages stuck internal cluster connection queue $artemis.internal...

2021-11-12 Thread foo bar
I can confirm 1.) we did not restore the journal 2.) we have not specified reconnect-attempts in the cluster connection which should default to -1 as you noted If we specify a finite value for reconnect-attempts will this also apply to the orphaned cluster connection? I ask because when I look

Re: ArtemisMQ 2.15 Messages stuck internal cluster connection queue $artemis.internal...

2021-11-12 Thread Justin Bertram
Based on your description of the problem it sounds like... 1) When you recreated your cluster node you didn't restore the journal from the node you lost which means the recreated node has a brand new node ID. 2) You're using -1 in your . Can you confirm this is actually the case? If so, you're

Re: ArtemisMQ 2.15 Messages stuck internal cluster connection queue $artemis.internal...

2021-11-12 Thread Gary Tully
I would have thought redistributionDelay > 0 would be the answer here, but I have not verified. On Fri, 12 Nov 2021 at 16:40, foo bar wrote: > > Hello, > > We lost one of the nodes in our cluster. After we recreated it, we noted > that there are cluster connection queues ($artemis.internal

ArtemisMQ 2.15 Messages stuck internal cluster connection queue $artemis.internal...

2021-11-12 Thread foo bar
Hello, We lost one of the nodes in our cluster. After we recreated it, we noted that there are cluster connection queues ($artemis.internal queues) from other nodes in the cluster that have messages that are stuck. Those cluster connection queues likely point to the old node which no longer

RE: Help - Authentication failed

2021-11-12 Thread Chintapanti, Sai
Thanks for your Reponses Tim and JB, it helps. We could see below error at cloud watch logs. Seems we were exceeded maximum connections. [cid:image001.jpg@01D7D811.8F86AA90] Thanks, Sai -Original Message- From: Tim Bain Sent: Friday, November 12, 2021 4:34 AM To: ActiveMQ Users

Re: Tunneling over HTTP or HTTPS not working as expected. "ping" packets blocked by firewall

2021-11-12 Thread Justin Bertram
I think you'd want to use the HTTP-specific configuration settings to control the keep-alive as noted in the docs [1]. On the client's URL: - httpClientIdleTime - httpClientIdleScanPeriod And on the acceptor's URL: - httpResponseTime - httpServerScanPeriod Disable these: - connectionTTL

Tunneling over HTTP or HTTPS not working as expected. "ping" packets blocked by firewall

2021-11-12 Thread Ben Amor, Moanes
Hello, tunneling over HTTP or HTTPS not working as expected. The client send automatically "ping" packets to prevent the server from closing down the connection. But these pings are non http conform (empty tcp requests) and has been blocked by the firewall of the Server. Am I missing

Re: ActiveMQ redeliveryPolicy not working as documented?

2021-11-12 Thread Gary Tully
note, in Artemis, there is only broker side redelivery, so it is easier to comprehend and configure at the address level https://activemq.apache.org/components/artemis/documentation/latest/undelivered-messages.html On Fri, 12 Nov 2021 at 10:10, Gary Tully wrote: > > the doc may not be in the

Re: ActiveMQ redeliveryPolicy not working as documented?

2021-11-12 Thread Gary Tully
the doc may not be in the correct place, your link if for client side redelivery. There are two types of redelivery, client side and server side via the plugin. Server side kicks in when the client side ends. Note from one of the tests, to have 'only' the server side plugin do work, the client