January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2293. ---------------------------- Resolution: Done > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2293: -------------------------------- OK [~rhusar] [~dan.berindei] I've fixed this issue, unit test is {{LeaveTest}}. Please let me know if this works for you. [~rhusar] Until I get the green light from Dan, I'm looking into the {{ASYM_ENCRYPT_LeaveTest}} (https://issues.jboss.org/browse/JGRP-2297). > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2293 at 1/22/19 7:14 AM: --------------------------------------------------------- Unit test is LeaveTest (formerly ConcurrentLeaversTest); using Byteman to simulate concurrent leaves where order between coord and next-in-line leaves is determine (coord -> next, next -> coord). Branch: JGRP-2293 was (Author: belaban): Unit test is LeaveTest (formerly ConcurrentLeaversTest); using Byteman to simulate concurrebt leaves where order between coord and next-in-line leaves is determine (coord -> next, next -> coord). Branch: JGRP-2293 > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2325) UNICAST3: change format of trace messages

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2325?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2325. ---------------------------- Resolution: Done > UNICAST3: change format of trace messages > ----------------------------------------- > > Key: JGRP-2325 > URL: https://issues.jboss.org/browse/JGRP-2325 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.0.17 > > > From > {{A --> DATA(B: #39, conn_id=2)}} > to > {{A --> B: DATA(#39, conn_id=2)}} > This provides better readability when looking at logs for message exchanges between members. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2326) NAKACK2: change format of trace messages

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2326?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2326. ---------------------------- Resolution: Done > NAKACK2: change format of trace messages > ---------------------------------------- > > Key: JGRP-2326 > URL: https://issues.jboss.org/browse/JGRP-2326 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.0.17 > > > From > {{A --> DATA(B: #39, conn_id=2)}} > to > {{A --> B: DATA(#39, conn_id=2)}} > This provides better readability when looking at logs for message exchanges between members. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Matej Novotny commented on WFLY-11604: -------------------------------------- The code I posted above checks firstly for Elytrron domain and tries to fetch Principal from there. From what I know, there is no other Elytron-specific class for this. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Matej Novotny > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-11604: ----------------------------------------- Is there an Elytron equivalent of that class? How is that working? > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Matej Novotny > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Matej Novotny commented on WFLY-11604: -------------------------------------- For the record, Weld is basically delegating the Principal retrieval to security subsystem and then the bean forwards any calls to the Principal it got. In WFLY this is implemented by [WeldSecurityServices|https://github.com/wildfly/wildfly/blob/master/weld/...]. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Matej Novotny > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1747) Programmatic web authentication does not save the password as a credential

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1747: ------------------------------------- Summary: Programmatic web authentication does not save the password as a credential Key: ELY-1747 URL: https://issues.jboss.org/browse/ELY-1747 Project: WildFly Elytron Issue Type: Bug Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.6.2.CR1, 1.8.0.CR2 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously

by Ian Rodgers (Jira)

[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ] Ian Rodgers commented on WFLY-11535: ------------------------------------ Other issues on the JBoss boards which may or may not be related: https://issues.jboss.org/browse/JGRP-2288 https://issues.jboss.org/browse/ISPN-9483 They apply to different Ping implementations (we're using JDBC_PING) but one refers to a fix coming in 4.0.16. > Cluster fails to merge if instances started simultaneously > ---------------------------------------------------------- > > Key: WFLY-11535 > URL: https://issues.jboss.org/browse/WFLY-11535 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Final > Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster > Reporter: Ian Rodgers > Assignee: Paul Ferraro > Priority: Major > Attachments: standalone-ha.xml > > > Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members). > We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join. > This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix. > On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 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 January 2019