[ 
https://issues.apache.org/jira/browse/QPID-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443628#comment-17443628
 ] 

ASF GitHub Bot commented on QPID-8558:
--------------------------------------

vavrtom merged pull request #106:
URL: https://github.com/apache/qpid-broker-j/pull/106


   


-- 
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: dev-unsubscr...@qpid.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Enhancement of sole connection enforcement policy evaluation
> -----------------------------------------------------------------------
>
>                 Key: QPID-8558
>                 URL: https://issues.apache.org/jira/browse/QPID-8558
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>            Reporter: Marek Laca
>            Priority: Minor
>              Labels: Broker, Java
>
> Java broker implements the sole connection enforcement policy extension of 
> the AMQP 1.0 protocol. The extension ensures that the remote container can 
> open only one active connection to the broker at the same time.
> The implementation is ineffective. When a new connection is opened the 
> IO-thread transfer the check to the virtual host configuration thread. The 
> configuration thread iterates throw all registered connections and checks 
> their remote container id and the policy. This technique ensures exclusive 
> access to the collection of the connections and nothing can be added or 
> removed during the check. Hence, the configuration thread works as a master 
> thread and every IO-thread has to wait till it receives a permission to go. 
> The waiting time increases with the number of open connections. The 
> processing of the messages is degraded, even when the user does not utilize 
> the sole connection enforcement policy.
> The policy can be implemented as a connection limiter and there is no need 
> for a global lock or the usage of configuration thread. The limiter can check 
> the connections from different remote containers in parallel. If user does 
> not utilize the sole connection enforcement policy then every connection will 
> have a unique container id and the processing of a new incoming connection 
> will not be block by another connections.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to