qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPID-5715) [Java Broker] Introduce VirtualHostNode into model
Date Thu, 29 May 2014 13:17:01 GMT

    [ 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:15 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
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.




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 would be:

SYNC, NO_SYNC, 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


Mime
View raw message