[ 
https://issues.apache.org/jira/browse/ARTEMIS-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated ARTEMIS-2756:
--------------------------------
    Description: 
Artemis already has an extension point, ConnectorServiceFactory, that allows a 
user provided plugin to connect Artemis to services in different ways.  In our 
use case, we use ConnectorServiceFactory to initiate outbound AMQP connections 
and in some cases initiate AMQP sending and receiving too.

In the case where the plugin initiates a link, there is currently a problem.  
The AMQP partner's attach 'response' may change the source (in the case of 
sending link initiated by the plugin) or target (in the case receiving link).  
Currently Artemis internally has no way to distinguish between a link initiated 
by a partner from one itself (well, a plugin) has initiated so it treats the 
partner's view of the link as definitive.  If the partner has not reflected the 
source/target fully this may mean a link to the wrong destination is formed.

Here's an example protocol trace where this has happened.  In this case a 
receiving link initiated by the Broker (EnMasse plugin) is wrongly 
reinterpreted as a link to the anonymous terminus.

[https://github.com/EnMasseProject/enmasse/issues/4442]

In the case where the Broker (or its plugin) is initiating links, Artemis view 
of the target (for receiving links)  and of the source (for sending links) is 
*definitive*.  We need a mechanism to prevent the definitive view being 
overwritten by the view of its partner.

 

 

Source (sending links) and target (receiving links)

  was:
Artemis already has an extension point, ConnectorServiceFactory, that allows a 
user provided plugin to connect Artemis to services in different ways.  In our 
use case, we use ConnectorServiceFactory to initiate outbound AMQP connections 
and in some cases initiate AMQP sending and receiving too.

In the case where the plugin initiates a link, there is currently a problem.  
The AMQP partner's attach 'response' may change the source (in the case of 
sending link initiated by the plugin) or target (in the case receiving link).  
Currently Artemis internally has no way to distinguish between a link initiated 
by a partner from one itself (well, a plugin) has initiated so it treats the 
partner's view of the link as definitive.  If the partner has not reflected the 
source/target fully this may mean a link to the wrong destination is formed.

Here's an example protocol trace where this has happened.  In this case a 
receiving link initiated by the Broker is wrong reinterpreted as a link to the 
anonymous terminus.

[https://github.com/EnMasseProject/enmasse/issues/4442]

In the case where the Broker (or its plugin) is initiating links, Artemis view 
of the target (for receiving links)  and of the source (for sending links) is 
*definitive*.  We need a mechanism to prevent the definitive view being 
overwritten by the view of its partner.

 

 

Source (sending links) and target (receiving links)


> Protect source/target information of links initiated by a 
> ConnectorServiceFactory implementations
> -------------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-2756
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2756
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Keith Wall
>            Priority: Major
>
> Artemis already has an extension point, ConnectorServiceFactory, that allows 
> a user provided plugin to connect Artemis to services in different ways.  In 
> our use case, we use ConnectorServiceFactory to initiate outbound AMQP 
> connections and in some cases initiate AMQP sending and receiving too.
> In the case where the plugin initiates a link, there is currently a problem.  
> The AMQP partner's attach 'response' may change the source (in the case of 
> sending link initiated by the plugin) or target (in the case receiving link). 
>  Currently Artemis internally has no way to distinguish between a link 
> initiated by a partner from one itself (well, a plugin) has initiated so it 
> treats the partner's view of the link as definitive.  If the partner has not 
> reflected the source/target fully this may mean a link to the wrong 
> destination is formed.
> Here's an example protocol trace where this has happened.  In this case a 
> receiving link initiated by the Broker (EnMasse plugin) is wrongly 
> reinterpreted as a link to the anonymous terminus.
> [https://github.com/EnMasseProject/enmasse/issues/4442]
> In the case where the Broker (or its plugin) is initiating links, Artemis 
> view of the target (for receiving links)  and of the source (for sending 
> links) is *definitive*.  We need a mechanism to prevent the definitive view 
> being overwritten by the view of its partner.
>  
>  
> Source (sending links) and target (receiving links)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to