[jira] [Work logged] (ARTEMIS-3759) Allow for Mirroring (Broker Connections) to specify a specific set of addresses to send events, as is done for a cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3759?focusedWorklogId=765282=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765282 ] ASF GitHub Bot logged work on ARTEMIS-3759: --- Author: ASF GitHub Bot Created on: 03/May/22 04:12 Start Date: 03/May/22 04:12 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4054: URL: https://github.com/apache/activemq-artemis/pull/4054#issuecomment-1115724471 I will spend some time reviewing this tomorrow after I finish the release on 2.22. it seems in good shape. Issue Time Tracking --- Worklog Id: (was: 765282) Time Spent: 2h 20m (was: 2h 10m) > Allow for Mirroring (Broker Connections) to specify a specific set of > addresses to send events, as is done for a cluster connection > - > > Key: ARTEMIS-3759 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3759 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.19.1, 2.21.0 >Reporter: Mikhail Lukyanov >Priority: Major > Attachments: ImageAddressSyntax.png, ImageInternalQueues.png > > Time Spent: 2h 20m > Remaining Estimate: 0h > > If a target broker of mirroring is in a cluster, then mirroring of the > broker's internal queues also occurs, and often messages accumulate in such > queues. In theory, internal cluster queues should not be mirrored, this does > not make much sense. > Therefore, it would be convenient to allow you to configure for which > addresses and their queues mirroring will be performed, events will be sent > (message-acknowledgements, queue-removal, queue-creation). The syntax that is > used to specify the *_addresses_* of the *_cluster connection_* is well > suited for this. > Mirrored internal cluster queues > !ImageInternalQueues.png! > Address syntax > !ImageAddressSyntax.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765271=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765271 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 03/May/22 03:44 Start Date: 03/May/22 03:44 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#issuecomment-1115690368 I will test tomorrow.. (including on stopping from the console) Issue Time Tracking --- Worklog Id: (was: 765271) Time Spent: 1h 40m (was: 1.5h) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[
https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765270=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765270
]
ASF GitHub Bot logged work on ARTEMIS-3808:
---
Author: ASF GitHub Bot
Created on: 03/May/22 03:42
Start Date: 03/May/22 03:42
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4061:
URL: https://github.com/apache/activemq-artemis/pull/4061#discussion_r863437999
##
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java:
##
@@ -4479,5 +4482,39 @@ public void replay(String startScan, String endScan,
String address, String targ
server.replay(startScanDate, endScanDate, address, target, filter);
}
+
+ @Override
+ public void stopEmbeddedWebServer() throws Exception {
+ for (ActiveMQComponent component : server.getExternalComponents()) {
Review Comment:
shouldn't this be on its own thread as well? what if you stop from the
console?
don't make sense I know, but wouldn't be broken if a user do it?
Issue Time Tracking
---
Worklog Id: (was: 765270)
Time Spent: 1.5h (was: 1h 20m)
> Support starting/stopping the embedded web server via mangement
> ---
>
> Key: ARTEMIS-3808
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3808
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It would be useful to be able to cycle the embedded web server if, for
> example, one needed to renew the SSL certificates.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531018#comment-17531018
]
Justin Bertram commented on ARTEMIS-3809:
-
bq. And from reading the code, it looks like a NEW instance of
LargeMessageControllerImpl is instantiated for each large message as it is
being received. I therefore conclude that this thread remained blocked on the
same message well beyond any kind of reasonable timeout.
Since the {{wait}} happens in a {{while}} loop it could be looping on the same
{{LargeMessageControllerImpl}} instance. So the lock ID in itself is not
sufficient to say that execution of that thread has not proceeded in anyway
between thread dumps.
bq. The "blocking call timeout" settable via the serverLocator.setCallTimeout()
method is at its default of 0 (at least I didn't set any value prior to this
problem).
The default call timeout on the {{ServerLocator}} should be {{3}}
milliseconds. Therefore, if you are not setting it to {{0}} I don't see how a
value of {{0}} could be used here.
bq. I adjusted the org.apache.activemq.artemis to TRACE and did this run. It
produced a LOT of logging.
The main thing I'm interested in at this point is {{TRACE}} logging on
{{org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl}}.
This will show what packets are arriving to the client. Specifically I want to
see packets of the type {{SESS_RECEIVE_LARGE_MSG}} and
{{SESS_RECEIVE_CONTINUATION}}.
Ultimately the best way to proceed is for you to provide a way to reproduce the
problem. That way I can put a debugger on it and really see what's happening.
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Priority: Major
> Labels: test-stability
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765256=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765256 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 03/May/22 01:26 Start Date: 03/May/22 01:26 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#issuecomment-1115526289 @clebertsuconic looks like that was the culprit. Try now. In my testing it's reliable now from JConsole and the web console as well. Issue Time Tracking --- Worklog Id: (was: 765256) Time Spent: 1h 20m (was: 1h 10m) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530988#comment-17530988
]
David Bennion commented on ARTEMIS-3809:
I have logs and I was able to identify the last time the message consumer gets
called:
{code:java}
05/02/2022 15:19:10.440 TRACE (global-threads)) [ClientConsumerImpl ]
org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl@4e3abde6{consumerContext=ActiveMQConsumerContext{id=0},
queueName=analyze}::Calling handler.onMessage
{code}
The blocked consumer is on a queue called 'analyze'. We have another queue
called 'Stats' that I believe is still pushing messages.
{noformat}
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [InVMConnection ]
InVMConnection [serverID=0, id=1e5a49e7-ca54-11ec-99a3-0050568ed7da]::Sending
inVM packet
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [motingConnectionImpl]
RemotingConnectionID=1e5a49e7-ca54-11ec-99a3-0050568ed7da handling packet
SessionIndividualAcknowledgeMessage[type=81, channelID=23, responseAsync=false,
requiresResponse=false, correlationID=-1, consumerID=0, messageID=34369871410,
requiresResponse=false]
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [InVMConnection ]
InVMConnection [serverID=0, id=1e5a49e7-ca54-11ec-99a3-0050568ed7da]::packet
sent done
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [InVMConnection ]
InVMConnection [serverID=0, id=1e5a49e7-ca54-11ec-99a3-0050568ed7da]::Sending
inVM packet
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [motingConnectionImpl]
RemotingConnectionID=1e5a49e7-ca54-11ec-99a3-0050568ed7da handling packet
SessionSendMessage_V2[type=71, channelID=14, responseAsync=true,
requiresResponse=false, correlationID=0,
message=CoreMessage[messageID=0,durable=false,userID=null,priority=4,
timestamp=Mon May 02 15:19:10 CDT 2022,expiration=Mon May 02 15:19:12 CDT 2022,
durable=false,
address=Stats,size=1552,properties=TypedProperties[...SNIPPED...]]@1327958296,
requiresResponse=false, correlationID=0, requiresResponse=false]
05/02/2022 15:19:10.440 TRACE (0.0-2081182161)) [InVMConnection ]
InVMConnection [serverID=0, id=1e5a49e7-ca54-11ec-99a3-0050568ed7da]::packet
sent done
05/02/2022 15:19:10.440 TRACE (Impl$6@f15a0d8)) [SessionPacketHandler]
ServerSessionPacketHandler::handlePacket,SessionIndividualAcknowledgeMessage[type=81,
channelID=23, responseAsync=false, requiresResponse=false, correlationID=-1,
consumerID=0, messageID=34369871410, requiresResponse=false]
05/02/2022 15:19:10.440 TRACE (Impl$6@f15a0d8)) [ServerConsumerImpl ]
individualACK messageID=34369871410
05/02/2022 15:19:10.440 TRACE (Impl$6@f15a0d8)) [ServerConsumerImpl ]
individualACK starting new TX
05/02/2022 15:19:10.440 TRACE (Impl$6@f15a0d8)) [ServerConsumerImpl ] ACKing
ref
Reference[34369871410]:NON-RELIABLE:CoreMessage[messageID=34369871410,durable=false,userID=null,priority=5,
timestamp=Mon May 02 15:19:09 CDT 2022,expiration=Mon May 02 15:20:09 CDT
2022, durable=false,
address=analyze,size=9014,properties=TypedProperties[...SNIPPED...]]@1054124345
on tx= TransactionImpl [xid=null, txID=34369871912, xid=null, state=ACTIVE,
createTime=1651522750440(Mon May 02 15:19:10 CDT 2022), timeoutSeconds=-1, nr
operations = 0]@1df2cdae, consumer=ServerConsumerImpl [id=0, filter=null,
binding=LocalQueueBinding [address=analyze, queue=QueueImpl[name=analyze,
postOffice=PostOfficeImpl [server=ActiveMQServerImpl::name=0.0.0.0],
temp=false]@1199309c, filter=null, name=analyze,
clusterName=analyze5aa9778c-98de-11ec-b671-0050568ed7da]]
05/02/2022 15:19:10.440 TRACE (Impl$6@f15a0d8)) [QueueImpl ]
QueueImpl[name=analyze, postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::name=0.0.0.0], temp=false]@1199309c acknowledge
tx=true
ref=Reference[34369871410]:NON-RELIABLE:CoreMessage[messageID=34369871410,durable=false,userID=null,priority=5,
timestamp=Mon May 02 15:19:09 CDT 2022,expiration=Mon May 02 15:20:09 CDT
2022, durable=false,
address=analyze,size=9014,properties=TypedProperties[...SNIPPED...]]@1054124345,
reason=NORMAL, consumer=ServerConsumerImpl [id=0, filter=null,
binding=LocalQueueBinding [address=analyze, queue=QueueImpl[name=analyze,
postOffice=PostOfficeImpl [server=ActiveMQServerImpl::name=0.0.0.0],
temp=false]@1199309c, filter=null, name=analyze,
clusterName=analyze5aa9778c-98de-11ec-b671-0050568ed7da]]
05/02/2022 15:19:10.440 INFO (Impl$6@f15a0d8)) [message ]
AMQ601502: User guest(guest)@invm:0 is acknowledging a message from analyze:
CoreMessage[messageID=34369871410,durable=false,userID=null,priority=5,
timestamp=Mon May 02 15:19:09 CDT 2022,expiration=Mon May 02 15:20:09 CDT 2022,
durable=false,
address=analyze,size=9014,properties=TypedProperties[...SNIPPED...]]@1054124345
05/02/2022 15:19:10.440 DEBUG (Impl$6@f15a0d8)) [impl ]
AMQ843014: acknowledged message:
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765223=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765223 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 03/May/22 00:02 Start Date: 03/May/22 00:02 Worklog Time Spent: 10m Work Description: jbertram commented on PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#issuecomment-1115479957 If I run `restartEmbeddedWebServer` from JConsole everything works just fine. However, if I run it from the web console it doesn't work. The web server never restarts. I think the problem is that the thread servicing the request from the web console is controlled by Jetty and since Jetty is shutting down the thread just halts. It's a catch-22. I'll try running it in its own thread and see if that works. Issue Time Tracking --- Worklog Id: (was: 765223) Time Spent: 1h 10m (was: 1h) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530948#comment-17530948
]
David Bennion commented on ARTEMIS-3809:
Thanks for following up, Justin.
Answers to questions:
1) We have one particular machine where this seems to happen. I have reports
of it happening very sporadically other places, but it seems to be reliable on
this particular machine. I am able to create it by running a process which
causes a lot of messages to flow through the system and at a certain point it
will hang.
2) I will see what I can do on this one for you. This actually is embedded and
configured programmatically, so I don't have a broker.xml – just settings in
the code.
3) I believe I can confirm that it is stuck indefinitely in this manner, and
you can verify my thinking. Before writing this response I went and reproduced
it again. I have the ability to get a threaddump from the system after the
consumer has hung.
At 2:22 PM as the issue started happening I took a threaddump. And then again
at 3:10 PM so around 50 minutes later, the threaddump had locks on the same
object for a wait notify. So the state of this thread is the same 50 minutes
apart.
Thread-2 (ActiveMQ-client-global-threads) id=154 state=TIMED_WAITING
- waiting on <{color:#FF}0x3a62856c{color}> (a
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
- locked <{color:#FF}0x3a62856c{color}> (a
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
at java.base@17.0.1/java.lang.Object.wait(Native Method)
at
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
at
org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
And from reading the code, it looks like a NEW instance of
LargeMessageControllerImpl is instantiated for each large message as it is
being received. I therefore conclude that this thread remained blocked on the
same message well beyond any kind of reasonable timeout.
The "blocking call timeout" settable via the serverLocator.setCallTimeout()
method is at its default of 0 (at least I didn't set any value prior to this
problem).
4) I adjusted the org.apache.activemq.artemis to TRACE and did this run. It
produced a LOT of logging. I am going to parse through it and see if I can
find relevant stuff for you relative the time when "the train left the track".
:) Will post back with more details as I can find them.
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Priority: Major
> Labels: test-stability
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765129=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765129 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 20:54 Start Date: 02/May/22 20:54 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#issuecomment-1115357313 @jbertram I did some simple testing.. and the console would not work after a restart: ``` 022-05-02 16:52:16,600 INFO [org.apache.activemq.hawtio.branding.PluginContextListener] Destroyed activemq-branding plugin 2022-05-02 16:52:31,616 INFO [io.hawt.web.auth.AuthenticationFilter] Failed to invoke action /exec/org.apache.activemq.artemis:broker="0.0.0.0"/restartEmbeddedWebServer() due to:: java.security.PrivilegedActionException: org.eclipse.jetty.io.EofException at java.base/java.security.AccessController.doPrivileged(Native Method) [java.base:] at java.base/javax.security.auth.Subject.doAs(Subject.java:423) [java.base:] at io.hawt.web.auth.AuthenticationFilter.executeAs(AuthenticationFilter.java:104) [hawtio-system-2.14.2.jar:2.14.2] at io.hawt.web.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:72) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601) at io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43) [hawtio-system-2.14.2.jar:2.14.2] ``` I don't think this is related to the restart method. I think there's something else happening there. Issue Time Tracking --- Worklog Id: (was: 765129) Time Spent: 1h (was: 50m) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765114=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765114 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 19:50 Start Date: 02/May/22 19:50 Worklog Time Spent: 10m Work Description: jbertram commented on code in PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#discussion_r863136705 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java: ## @@ -1971,5 +1971,11 @@ void replay(@Parameter(name = "startScanDate", desc = "Start date where we will @Parameter(name = "address", desc = "Name of the address to replay") String address, @Parameter(name = "target", desc = "Where the replay data should be sent") String target, @Parameter(name = "filter", desc = "Filter to apply on message selection. Null means everything matching the address") String filter) throws Exception; + + @Operation(desc = "stop the embedded web server", impact = MBeanOperationInfo.ACTION) + void stopEmbeddedWebServer() throws Exception; Review Comment: @clebertsuconic done Issue Time Tracking --- Worklog Id: (was: 765114) Time Spent: 50m (was: 40m) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765110=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765110 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 19:08 Start Date: 02/May/22 19:08 Worklog Time Spent: 10m Work Description: clebertsuconic commented on code in PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#discussion_r863108348 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java: ## @@ -1971,5 +1971,11 @@ void replay(@Parameter(name = "startScanDate", desc = "Start date where we will @Parameter(name = "address", desc = "Name of the address to replay") String address, @Parameter(name = "target", desc = "Where the replay data should be sent") String target, @Parameter(name = "filter", desc = "Filter to apply on message selection. Null means everything matching the address") String filter) throws Exception; + + @Operation(desc = "stop the embedded web server", impact = MBeanOperationInfo.ACTION) + void stopEmbeddedWebServer() throws Exception; Review Comment: @jbertram Yeah.. It would be nice (and I think simple) to have it. Issue Time Tracking --- Worklog Id: (was: 765110) Time Spent: 40m (was: 0.5h) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765097=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765097 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 18:47 Start Date: 02/May/22 18:47 Worklog Time Spent: 10m Work Description: jbertram commented on code in PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#discussion_r863094171 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java: ## @@ -1971,5 +1971,11 @@ void replay(@Parameter(name = "startScanDate", desc = "Start date where we will @Parameter(name = "address", desc = "Name of the address to replay") String address, @Parameter(name = "target", desc = "Where the replay data should be sent") String target, @Parameter(name = "filter", desc = "Filter to apply on message selection. Null means everything matching the address") String filter) throws Exception; + + @Operation(desc = "stop the embedded web server", impact = MBeanOperationInfo.ACTION) + void stopEmbeddedWebServer() throws Exception; Review Comment: With the current change, if you were using the web console to stop the embedded web server then you'd have to use something _other_ than the web console to start it again (e.g. JConsole, Jolokia, etc.). However, it does make sense to have a method to both stop & start it. The user experience would certainly be better with that method in most circumstances. I'll add that. Issue Time Tracking --- Worklog Id: (was: 765097) Time Spent: 0.5h (was: 20m) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3810) XID Resumes on already Active Transactions should not throw any error
[ https://issues.apache.org/jira/browse/ARTEMIS-3810?focusedWorklogId=765094=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765094 ] ASF GitHub Bot logged work on ARTEMIS-3810: --- Author: ASF GitHub Bot Created on: 02/May/22 18:45 Start Date: 02/May/22 18:45 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4062: URL: https://github.com/apache/activemq-artemis/pull/4062 Issue Time Tracking --- Worklog Id: (was: 765094) Remaining Estimate: 0h Time Spent: 10m > XID Resumes on already Active Transactions should not throw any error > - > > Key: ARTEMIS-3810 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3810 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.22.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.23.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3810) XID Resumes on already Active Transactions should not throw any error
[ https://issues.apache.org/jira/browse/ARTEMIS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530897#comment-17530897 ] ASF subversion and git services commented on ARTEMIS-3810: -- Commit 784b0e967e3443f0fa093860d2560740b3f1e515 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=784b0e967e ] ARTEMIS-3810 Do not throw error resuming already active XA Transaction > XID Resumes on already Active Transactions should not throw any error > - > > Key: ARTEMIS-3810 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3810 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.22.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.23.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=765093=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-765093 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 18:42 Start Date: 02/May/22 18:42 Worklog Time Spent: 10m Work Description: clebertsuconic commented on code in PR #4061: URL: https://github.com/apache/activemq-artemis/pull/4061#discussion_r863090610 ## artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java: ## @@ -1971,5 +1971,11 @@ void replay(@Parameter(name = "startScanDate", desc = "Start date where we will @Parameter(name = "address", desc = "Name of the address to replay") String address, @Parameter(name = "target", desc = "Where the replay data should be sent") String target, @Parameter(name = "filter", desc = "Filter to apply on message selection. Null means everything matching the address") String filter) throws Exception; + + @Operation(desc = "stop the embedded web server", impact = MBeanOperationInfo.ACTION) + void stopEmbeddedWebServer() throws Exception; Review Comment: can you add a method to restart the WebServer? if you wanted to restart with a web console, how would you get it back running? maybe restartEmbeddedWebServer(int timeoutSeconds); Such method would stop it... wait a few seconds.. and restart it. Issue Time Tracking --- Worklog Id: (was: 765093) Time Spent: 20m (was: 10m) > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530887#comment-17530887
]
Justin Bertram commented on ARTEMIS-3809:
-
Couple of question...
# Is this something you can reproduce?
# Can you paste or attach your {{broker.xml}}?
# Can you confirm that the client is stuck indefinitely? Is it possible that
the large message packets are simply being consumed very slowly?
# Have you enabled TRACE logging for the client? If so, what did it show during
the time the client was stalled?
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Priority: Major
> Labels: test-stability
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes across the
> threshold to become large it appears to hang the consumer indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (ARTEMIS-3810) XID Resumes on already Activ
Clebert Suconic created ARTEMIS-3810: Summary: XID Resumes on already Activ Key: ARTEMIS-3810 URL: https://issues.apache.org/jira/browse/ARTEMIS-3810 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ARTEMIS-3810) XID Resumes on already Active Transactions should not throw any error
[ https://issues.apache.org/jira/browse/ARTEMIS-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-3810: - Fix Version/s: 2.23.0 Affects Version/s: 2.22.0 Summary: XID Resumes on already Active Transactions should not throw any error (was: XID Resumes on already Activ) > XID Resumes on already Active Transactions should not throw any error > - > > Key: ARTEMIS-3810 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3810 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.22.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.23.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3808) Support starting/stopping the embedded web server via mangement
[ https://issues.apache.org/jira/browse/ARTEMIS-3808?focusedWorklogId=764989=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-764989 ] ASF GitHub Bot logged work on ARTEMIS-3808: --- Author: ASF GitHub Bot Created on: 02/May/22 15:25 Start Date: 02/May/22 15:25 Worklog Time Spent: 10m Work Description: jbertram opened a new pull request, #4061: URL: https://github.com/apache/activemq-artemis/pull/4061 It would be useful to be able to cycle the embedded web server if, for example, one needed to renew the SSL certificates. Supporting this functionality required a number of changes such as: - Adding `getName()` to `ActiveMQComponent` along with a default implementation. This was necessary in order to actually find the `WebServerComponent` in the broker's list of components. Many classes which implement `ActiveMQComponent` already had `getName()` but a handful of them were returning `String` rather than `SimpleString` so they had to be updated. - Refactoring `WebServerComponent` so that all the necessary configuration would happen in the `start()` method. - Refactoring `WebServerComponentTest` to re-use code. Issue Time Tracking --- Worklog Id: (was: 764989) Remaining Estimate: 0h Time Spent: 10m > Support starting/stopping the embedded web server via mangement > --- > > Key: ARTEMIS-3808 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3808 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It would be useful to be able to cycle the embedded web server if, for > example, one needed to renew the SSL certificates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (AMQ-8593) Deprecate masterslave discovery agent and add a new leaderfollower discovery agent
[ https://issues.apache.org/jira/browse/AMQ-8593?focusedWorklogId=764973=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-764973 ] ASF GitHub Bot logged work on AMQ-8593: --- Author: ASF GitHub Bot Created on: 02/May/22 14:19 Start Date: 02/May/22 14:19 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #835: URL: https://github.com/apache/activemq/pull/835#issuecomment-1114951122 @lucastetreault thanks for updating to include deprecated for masterslave. In terms of naming Issue Time Tracking --- Worklog Id: (was: 764973) Time Spent: 20m (was: 10m) > Deprecate masterslave discovery agent and add a new leaderfollower discovery > agent > -- > > Key: AMQ-8593 > URL: https://issues.apache.org/jira/browse/AMQ-8593 > Project: ActiveMQ > Issue Type: Task > Components: Network of Brokers >Affects Versions: 5.17.2 >Reporter: Lucas Tétreault >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > This [tweet|https://twitter.com/owenblacker/status/1517156221207212032] > raised the issue of non-inclusive terminology in the [AWS > docs|https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-network-of-brokers.html#creating-configuring-network-of-brokers-configure-network-connectors] > and suggested that we should replace masterslave with an more inclusive name > for the network connector transport. The AWS docs refer to a feature of > ActiveMQ that is a convenience discovery agent: > [https://activemq.apache.org/networks-of-brokers#masterslave-discovery] > Replacing master/slave nomenclature in ActiveMQ was raised in July 2020 > AMQ-7514 and there have been some attempts at making some changes > ([#679|https://github.com/apache/activemq/pull/679], > [#714|https://github.com/apache/activemq/pull/714], > [#788|https://github.com/apache/activemq/pull/788]) however we have not been > able to come to an agreement on nomenclature so these efforts seem to have > stalled out. > If we are able to come to an agreement on nomenclature in this PR, we can > move forward with removing more non-inclusive terminology on the website (I > will follow up with some PRs to the website), in discussions with the > community and of course in this codebase. This will remove adoption barriers > and make ActiveMQ a more approachable and inclusive project for everyone! > Other Apache projects such as Solr and Kafka have moved from master/slave to > leader/follower. Leader/follower is also recommended by the > [IETF|https://tools.ietf.org/id/draft-knodel-terminology-02.html] and > [inclusivenaming.org|https://inclusivenaming.org/word-lists/tier-1/] which is > supported by companies such as Cisco, Intel, and RedHat. > If we can't come to an agreement on Leader/Follower or some other > nomenclature I will, at the very least, create a follow up PR to remove the > masterslave transport since it is just a convenience method to use > static+failover with ?randomize=false=0. > This change leaves the masterslave: transport in place but provides a new > alias leaderfollower: for now but we can easily remove it in 5.18.0. > PR: https://github.com/apache/activemq/pull/835 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (AMQ-8593) Deprecate masterslave discovery agent and add a new leaderfollower discovery agent
[ https://issues.apache.org/jira/browse/AMQ-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530752#comment-17530752 ] Matt Pavlovich commented on AMQ-8593: - I think we should use "ha://". This transport is really just 'failover', but 'failover' is already taken. We don't need to indicate anything about the architecture, b/c they are not related. > Deprecate masterslave discovery agent and add a new leaderfollower discovery > agent > -- > > Key: AMQ-8593 > URL: https://issues.apache.org/jira/browse/AMQ-8593 > Project: ActiveMQ > Issue Type: Task > Components: Network of Brokers >Affects Versions: 5.17.2 >Reporter: Lucas Tétreault >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This [tweet|https://twitter.com/owenblacker/status/1517156221207212032] > raised the issue of non-inclusive terminology in the [AWS > docs|https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-network-of-brokers.html#creating-configuring-network-of-brokers-configure-network-connectors] > and suggested that we should replace masterslave with an more inclusive name > for the network connector transport. The AWS docs refer to a feature of > ActiveMQ that is a convenience discovery agent: > [https://activemq.apache.org/networks-of-brokers#masterslave-discovery] > Replacing master/slave nomenclature in ActiveMQ was raised in July 2020 > AMQ-7514 and there have been some attempts at making some changes > ([#679|https://github.com/apache/activemq/pull/679], > [#714|https://github.com/apache/activemq/pull/714], > [#788|https://github.com/apache/activemq/pull/788]) however we have not been > able to come to an agreement on nomenclature so these efforts seem to have > stalled out. > If we are able to come to an agreement on nomenclature in this PR, we can > move forward with removing more non-inclusive terminology on the website (I > will follow up with some PRs to the website), in discussions with the > community and of course in this codebase. This will remove adoption barriers > and make ActiveMQ a more approachable and inclusive project for everyone! > Other Apache projects such as Solr and Kafka have moved from master/slave to > leader/follower. Leader/follower is also recommended by the > [IETF|https://tools.ietf.org/id/draft-knodel-terminology-02.html] and > [inclusivenaming.org|https://inclusivenaming.org/word-lists/tier-1/] which is > supported by companies such as Cisco, Intel, and RedHat. > If we can't come to an agreement on Leader/Follower or some other > nomenclature I will, at the very least, create a follow up PR to remove the > masterslave transport since it is just a convenience method to use > static+failover with ?randomize=false=0. > This change leaves the masterslave: transport in place but provides a new > alias leaderfollower: for now but we can easily remove it in 5.18.0. > PR: https://github.com/apache/activemq/pull/835 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ARTEMIS-3767) Rolling upgrade from 2.17 and older broken since 2.18
[
https://issues.apache.org/jira/browse/ARTEMIS-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Šmucr updated ARTEMIS-3767:
---
Affects Version/s: 2.21.0
2.20.0
2.19.1
2.19.0
> Rolling upgrade from 2.17 and older broken since 2.18
> -
>
> Key: ARTEMIS-3767
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3767
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0, 2.19.0, 2.19.1, 2.20.0, 2.21.0
> Environment: AWS EC2 t3a.large
> CentOS Linux release 7.9.2009
> OpenJDK 8, OpenJDK 11
>Reporter: Jan Šmucr
>Priority: Major
> Attachments: broker-master.log, broker-slave.log
>
>
> It's not possible to perform a rolling upgrade in replication environment.
> After upgrading the *slave* from 2.17 to 2.18 it reports:
> {noformat}
> AMQ214013: Failed to decode packet: java.lang.IndexOutOfBoundsException:
> readerIndex(57) + length(1) exceeds writerIndex(57):
> PooledUnsafeDirectByteBuf(ridx: 57, widx: 57, cap: 57) {noformat}
> The 2.17 *master* then crashes with an exception:
> {noformat}
> 2022-04-07 10:01:23,032 WARN [org.apache.activemq.artemis.core.server]
> AMQ222010: Critical IO Error, shutting down the server. file=NULL,
> message=AMQ229114: Replication synchronization process timed out after
> waiting 30,000 milliseconds:
> ActiveMQReplicationTimeooutException[errorType=REPLICATION_TIMEOUT_ERROR
> message=AMQ229114: Replication synchronization process timed out after
> waiting 30,000 milliseconds]
> at
> org.apache.activemq.artemis.core.replication.ReplicationManager.sendSynchronizationDone(ReplicationManager.java:660)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:717)
> [artemis-server-2.17.0.jar:2.17.0]
> at
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:180)
> [artemis-server-2.17.0.jar:2.17.0]
> at java.base/java.lang.Thread.run(Thread.java:829) [java.base:]
> {noformat}
> Upgrades from lower versions (or to higher versions) aren't possible either.
> Steps to replicate the issue:
> # Create a master instance (replace the IPs to match your setup):
> {noformat}
> apache-artemis-2.17.0/bin/artemis create --aio --allow-anonymous --user admin
> --password admin --clustered --cluster-user admin --cluster-password admin
> --host 10.35.4.16 --http-host 10.35.4.16 --replicated --staticCluster
> tcp://10.35.4.211:61616 -- broker-master {noformat}
> # Start the instance:
> {noformat}
> broker-master/bin/artemis run{noformat}
> # Create a slave instance (it's fine to start the 2.18 right away, no need
> for a real upgrade):
> {noformat}
> apache-artemis-2.18.0/bin/artemis create --aio --allow-anonymous --user admin
> --password admin --clustered --slave --cluster-user admin --cluster-password
> admin --host 10.35.4.211 --http-host 10.35.4.211 --replicated --staticCluster
> tcp://10.35.4.16:61616 -- broker-slave{noformat}
> # Start the instance:
> {noformat}
> broker-slave/bin/artemis run {noformat}
> # The master crashes while the slave keeps running doing nothing.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
