[JBoss JIRA] (JGRP-2111) Sticky site masters
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2111?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2111.
--------------------------
Resolution: Done
> Sticky site masters
> -------------------
>
> Key: JGRP-2111
> URL: https://issues.jboss.org/browse/JGRP-2111
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2112) Sticky site masters
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2112:
---------------------------
Description:
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
h4. Design
* When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
* Note that this only applies when we have more than one site master.
* The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
h5. Transactions
* Transactions by different originators with overlapping key sets cannot be reliably ordered
* Transactional support therefore requires single site masters
* This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates
was:
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> Sticky site masters
> -------------------
>
> Key: JGRP-2112
> URL: https://issues.jboss.org/browse/JGRP-2112
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2112) Sticky site masters
by Bela Ban (JIRA)
Bela Ban created JGRP-2112:
------------------------------
Summary: Sticky site masters
Key: JGRP-2112
URL: https://issues.jboss.org/browse/JGRP-2112
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.12, 4.0
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2111) Sticky site masters
by Bela Ban (JIRA)
Bela Ban created JGRP-2111:
------------------------------
Summary: Sticky site masters
Key: JGRP-2111
URL: https://issues.jboss.org/browse/JGRP-2111
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.12, 4.0
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-663) LDAP referrals does not work - dir-context.referral-mode is always ignored
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-663:
---------------------------
Summary: LDAP referrals does not work - dir-context.referral-mode is always ignored (was: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored)
> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
> Key: ELY-663
> URL: https://issues.jboss.org/browse/ELY-663
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron.
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb147...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7320) LDAP referrals does not work - need to set custom filter
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7320:
-----------------------------
Summary: LDAP referrals does not work - need to set custom filter (was: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored)
> LDAP referrals does not work - need to set custom filter
> --------------------------------------------------------
>
> Key: WFLY-7320
> URL: https://issues.jboss.org/browse/WFLY-7320
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron.
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb147...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months