You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2016/11/02 11:58:58 UTC

[jira] [Comment Edited] (QPID-7477) [Java Broker] Recovery of Broker preferences should happen without holding VirtualHostPrincipal

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

Keith Wall edited comment on QPID-7477 at 11/2/16 11:58 AM:
------------------------------------------------------------

The problem is that whilst {{BrokerImpl#performActivation}} is being run by the Broker Config thread, the Subject attached to the thread erroneously includes the {{VirtualHostPrincipal}}.  This is causing the log messages that pertain to the Broker to be written to the wrong place. 

The problem arises as follows:

Broker is being started.

# VHN tries to attain its desired state
# VHN recovers the VH
# VHN opens the VH asynchronously (AbstractStandardVirtualHostNode.java:117). Note that the *VH open future* is returned as the *VHN's state change future*. 
# VH opens successfully
# VH open future completes (which is the VHN state future)
# Guava's future listening mechanics (SettableFuture/ExecutionList) which is *running on the VH config thread* cause the future callback (AbstractConfiguredObject.java:1030) to be submitted to the Broker-Config thread.    TaskExecutorImpl.java:397 constructs a Subject for the task, but as the thread's current context includes the VH principal, so does the Subject used for the execution of the Broker task.
# The VHN state future now complete, so other Broker objects proceed to attain their desired state too,
# The Broker children now have all attained state, so BrokerImpl#performActivation is run.  This is still the same task and still carries the erroneous VH Principal.




was (Author: k-wall):
The problem is that whilst {{BrokerImpl#performActivation}} is being run by the Broker Config thread, the Subject attached to the thread erroneously includes the {{VirtualHostPrincipal}}.  This is causing the log messages that pertain to the Broker to be written to the wrong place. 

The problem arises as follows:

Broker is being started.

# VHN tries to attain its desired state
# VHN recovers the VH
# VHN opens the VH asynchronously (AbstractStandardVirtualHostNode.java:117). Note that the *VH open future* is returned as the *VHN's state change future*. 
# VH opens successfully
# VH open future completes (which is the VHN state future)
# Guava's future listening mechanics (SettableFuture/ExecutionList) which is *running on the VH config thread* cause the future callback (AbstractConfiguredObject.java:1030) to be submitted to the Broker-Config thread.    TaskExecutorImpl.java:397 constructs a Subject for the task, but as the thread's current context includes the VH principal, so does the Subject used for the execution of the Broker task.
# The VHN state future now complete, so other Broker objects proceed to attain their desired state too,
# The Broker children now have all attained state, so BrokerImpl#performActivation is run.  This is still the same task and still carries the erroneous Principal.



> [Java Broker] Recovery of Broker preferences should happen without holding VirtualHostPrincipal
> -----------------------------------------------------------------------------------------------
>
>                 Key: QPID-7477
>                 URL: https://issues.apache.org/jira/browse/QPID-7477
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: qpid-java-6.1
>            Reporter: Lorenz Quack
>             Fix For: qpid-java-6.1, qpid-java-6.2
>
>
> If a {{VirtualHostLogger}} is configured it will log the recovery of Broker preferences on the Broker-Config thread. It should not do this.
> The cause seems to be that during execution of {{BrokerImpl#performActivation}} the {{Subject}} contains the {{VirtualHostPrincipal}}.
> I think this is related to the fact that the call stack shows that this code is called from the {{onSuccess}} callback of {{VirtualHostNode#doActivation}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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