[
https://issues.apache.org/jira/browse/ARTEMIS-3243?focusedWorklogId=627741&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-627741
]
ASF GitHub Bot logged work on ARTEMIS-3243:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 26/Jul/21 13:28
Start Date: 26/Jul/21 13:28
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3633:
URL: https://github.com/apache/activemq-artemis/pull/3633#discussion_r676602783
##########
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/AMQPBrokerConnection.java
##########
@@ -511,22 +534,88 @@ private void connectSender(Queue queue,
sender.setProperties(mapProperties);
}
+ if (desiredCapabilities != null) {
+ sender.setDesiredCapabilities(desiredCapabilities);
+ }
+
AMQPOutgoingController outgoingInitializer = new
AMQPOutgoingController(queue, sender, sessionContext.getSessionSPI());
+ sender.open();
+
ProtonServerSenderContext senderContext = new
ProtonServerSenderContext(protonRemotingConnection.getAmqpConnection(), sender,
sessionContext, sessionContext.getSessionSPI(),
outgoingInitializer).setBeforeDelivery(beforeDeliver);
+ // This will be done on the remote open
+ sender.setContext(new Runnable() {
+ @Override
+ public void run() {
Review comment:
https://github.com/gemmellr/activemq-artemis/commit/58b65283fdb1462c6ac01708ecfc4141dd079ea7
including a new debug test to show the issues, it manipulates a delay between
the 'refusing attach' and the detach such that the broker actually fires up a
consumer on the queue, and also flows credit (unusual during a refusal but
possible) so it even sends messages across before it gets the detach. It should
instead notice the refusal and skip doing anything. The debug test also (if the
noted code is commented out) highlights the way the broker falls over the lack
of caps/props due to overlooking the refusal, whereas it wouldn't if it handled
the refusal (e.g set a limit on how long it will wait for the detach to explain
the issue, then kill the bits if it doesnt happen in that time).
I noticed when creating it that that the test sometimes failed due to
receiving more than the expected number of retries, particularly when that code
was uncommented, so I think there may be some issues lurking in the reconnect
stuff. Some of the other tests you have might be useful to find them if they
more precisely track the total number of connections rather than just the
number of disconnects that occur.
The commit also has a couple cleanup suggestions for other tests (which
could apply to some of the others as well)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 627741)
Time Spent: 29h (was: 28h 50m)
> Enhance AMQP Mirror support with dual mirror
> --------------------------------------------
>
> Key: ARTEMIS-3243
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3243
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.17.0
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.18.0
>
> Time Spent: 29h
> Remaining Estimate: 0h
>
> at the current Mirror version, we can only mirror into a single direction.
> With this enhancement the two (or more brokers) would be connected to each
> other, each one having its own ID, and each one would send updates to the
> other broker.
> The outcome is that if you just transferred producers and consumers from one
> broker into the other, the fallback would be automatic and simple. No need to
> disable and enable mirror options.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
