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 2014/05/29 15:17:01 UTC
[jira] [Comment Edited] (QPID-5715) [Java Broker] Introduce
VirtualHostNode into model
[ https://issues.apache.org/jira/browse/QPID-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012342#comment-14012342 ]
Keith Wall edited comment on QPID-5715 at 5/29/14 1:16 PM:
-----------------------------------------------------------
Hi Alex,
Re. r1597801.
This is not as I understood how we wanted things to be. I thought, from the *user* perspective (i.e. model upwards), the default replication policy attributes would be:
localTransactionSyncronizationPolicy=SYNC
remoteTransactionSyncronizationPolicy=NO_SYNC
acknowledgmentPolicy=SIMPLE_MAJORITY
However, the implementation would be do things slightly differently
Local sync policy
=============
If the user chooses a local sync policy of SYNC, we are to implement this as JE WRITE_NO_SYNC but with the coalescing committer to give the effect of SYNC but in a more efficient manner.
If the user chooses a local sync policy of WRITE_NO_SYNC, normal JE rules would apply. The transaction is written but the data would be committed to the disk later. Coalescing committer would not be used. JE would perform the sync later.
If the user chooses a local sync policy of NO_SYNC, normal JE rules would apply. The transaction is neither written nor synced. Coalescing committer would not be used. JE would perform the write/sync later.
Remote sync policy
===============
Normal JE rules apply.
I think we should expose replicaAcknowledgmentPolicy as far as the model (just in case). It should default to SIMPLE_MAJORITY.
was (Author: k-wall):
Hi Alex,
Re. r1597801.
This is not as I understood how we wanted things to be. I thought, from the *user* perspective (i.e. model upwards), the default replication policy attributes would be:
localTransactionSyncronizationPolicy=SYNC
remoteTransactionSyncronizationPolicy=NO_SYNC
remoteAcknowledgmentPolicy=SIMPLE_MAJORITY
However, the implementation would be do things slightly differently
Local sync policy
=============
If the user chooses a local sync policy of SYNC, we are to implement this as JE WRITE_NO_SYNC but with the coalescing committer to give the effect of SYNC but in a more efficient manner.
If the user chooses a local sync policy of WRITE_NO_SYNC, normal JE rules would apply. The transaction is written but the data would be committed to the disk later. Coalescing committer would not be used. JE would perform the sync later.
If the user chooses a local sync policy of NO_SYNC, normal JE rules would apply. The transaction is neither written nor synced. Coalescing committer would not be used. JE would perform the write/sync later.
Remote sync policy
===============
Normal JE rules apply.
I think we should expose replicaAcknowledgmentPolicy as far as the model (just in case). It should default to SIMPLE_MAJORITY.
> [Java Broker] Introduce VirtualHostNode into model
> --------------------------------------------------
>
> Key: QPID-5715
> URL: https://issues.apache.org/jira/browse/QPID-5715
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Keith Wall
> Attachments: 0001-QPID-5715-Java-Broker-Make-virtualhosts-respect-the-.patch
>
>
> In order to support the HA use-case, a new object, VirtualHostNode will be added into the Broker model. The Broker will support zero or more virtual host nodes. Each virtual host node may have zero or one virtual hosts.
> Virtualhostnode will be responsible for
> * the lifecycle of the durable configuration store
> * the recovery of its children (that is, the virtual host and its object descendants (exchanges, queues etc) but not messages/message instances etc).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org