October 2016 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1867) Upgrade to WildFly Elytron 1.1.0.Beta11

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1867: ---------------------------------------- Summary: Upgrade to WildFly Elytron 1.1.0.Beta11 Key: WFCORE-1867 URL: https://issues.jboss.org/browse/WFCORE-1867 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-667) Release WildFly Elytron 1.1.0.Beta11

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-667: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta11 Key: ELY-667 URL: https://issues.jboss.org/browse/ELY-667 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta11 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ELY-666) LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored

by Jan Kalina (JIRA)

Jan Kalina created ELY-666: ------------------------------ Summary: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored Key: ELY-666 URL: https://issues.jboss.org/browse/ELY-666 Project: WildFly Elytron Issue Type: Bug 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

1
0
0 / 0

[JBoss JIRA] (WFLY-7320) LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.... ] Jan Kalina moved ELY-666 to WFLY-7320: -------------------------------------- Project: WildFly (was: WildFly Elytron) Key: WFLY-7320 (was: ELY-666) > LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7320 > URL: https://issues.jboss.org/browse/WFLY-7320 > Project: WildFly > Issue Type: Bug > 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016