[
https://issues.apache.org/jira/browse/ARTEMIS-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224804#comment-17224804
]
ASF subversion and git services commented on ARTEMIS-2937:
----------------------------------------------------------
Commit fa4064cfd784e93a02a3905b16b8c9302fe105fc in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fa4064c ]
ARTEMIS-2969 / ARTEMIS-2937 RedoConnection should call
protonRemotingConnection.destroy
Instead of calling destroy, redo was closing the Netty connection directly
leaving the job of destroy delayed until TTL
> AMQP Server Connectivity
> ------------------------
>
> Key: ARTEMIS-2937
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2937
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: AMQP
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 35h 20m
> Remaining Estimate: 0h
>
> This feature adds server side connectivity.
>
> It is possible to link two brokers directly using AMQP with this feature, and
> have a Queue transferring messages to another broker directly.
>
> For this we would have options called <sender and <receiver
>
>
> it would also be possible to use qpid-dispatch as an intermediary between
> clients and the brokers (or eventually between brokers), on that case the
> option will be <peer
>
> it would also be possible to use <mirror with a few option to replicate data
> between two brokers, bringing the possibility of using it for Disaster &
> Recovery and Failover.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)