February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1691) Add test if Mechansim Database cover cipher suites from JDK

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1691?page=com.atlassian.jira.plugin.s... ] Farah Juma commented on ELY-1691: --------------------------------- Just discussed this one with [~dvilkola] and adding some notes here: Since support for TLS 1.3 (ELY-1706) has not been added yet, the [new TLS 1.3 cipher suites|https://tools.ietf.org/html/rfc8446#appendix-B.4] from JDK 11 are not part of Elytron's Mechanism Database yet. Thus, this test will fail when these specific cipher suites are checked. For now, we could exclude these specific cipher suites from the test and then add them back once TLS 1.3 support has been added. > Add test if Mechansim Database cover cipher suites from JDK > ----------------------------------------------------------- > > Key: ELY-1691 > URL: https://issues.jboss.org/browse/ELY-1691 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Assignee: Diana Vilkolakova > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Richard Achmatowicz edited comment on WFLY-11682 at 2/11/19 11:55 AM: ---------------------------------------------------------------------- Managed to recreate the error with Jorg's reproducer. It looks as though nodes which are kicked out of the cluster do not get a chance to send updates to the client before being kicked out. So the last node to leave has no opportunity to advise the client of its leaving. Which is why the client believes the last node to leave is still alive. In the attached logs, node3 sees removal of client mappings entries entries for node1 and node2, but does not receive notification of its own client mapping entries. The server side code has changed a lot due to the new EJBClient/Elytron/Remoting implementation, and some EJB client related features which did appear there (in VersionOneChannelProtocolHandler) were not ported over (to AssociationImpl); specifically EJB client related responses to suspend and resume. These should be added back in. This is one place where it would be possible to send a notification to a client if the last node was going down (set a flag indicating we are the last node and we are being suspended; if the server is not resumed, use the flag to send a message before the EJBServerChannel connections to the clients are shut down). was (Author: rachmato): Managed to recreate the error with Jorg's reproducer. It looks as though nodes which are kicked out of the cluster do not get a chance to send updates to the client before being kicked out. So the last node to leave has no opportunity to advise the client of its leaving. Which is why the client believes the last node to leave is still alive. The server side code has changed a lot due to the new EJBClient/Elytron/Remoting implementation, and some EJB client related features which did appear there (in VersionOneChannelProtocolHandler) were not ported over (to AssociationImpl); specifically EJB client related responses to suspend and resume. These should be added back in. This is one place where it would be possible to send a notification to a client if the last node was going down (set a flag indicating we are the last node and we are being suspended; if the server is not resumed, use the flag to send a message before the EJBServerChannel connections to the clients are shut down). > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: node1.txt, node12.txt, node2.txt, node3.txt, playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Richard Achmatowicz updated WFLY-11682: --------------------------------------- Attachment: (was: Notes.txt) > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: node1.txt, node12.txt, node2.txt, node3.txt, playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ] Richard Achmatowicz updated WFLY-11682: --------------------------------------- Attachment: Notes.txt node12.txt node3.txt node2.txt node1.txt > Clustered SLSB membership anomalies when all cluster members removed > -------------------------------------------------------------------- > > Key: WFLY-11682 > URL: https://issues.jboss.org/browse/WFLY-11682 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 15.0.1.Final > Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down. > Reporter: Jörg Bäsner > Assignee: Richard Achmatowicz > Priority: Major > Attachments: Notes.txt, node1.txt, node12.txt, node2.txt, node3.txt, playground.zip > > > This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not. > The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing. > As long as all nodes are up and running the client is calling EJBs in a balanced way. > When node1 is shut down, the client get the notification below: > {code}... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1) > ... > {code} > Then node2 is shut down. Again the client get the information, see: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2) > ... > {code} > Finally node3 is being shut down. Now the client only get the following information: > {code} > ... > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground > ... > {code} > This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped. > From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}} > Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}: > {code} > ... > INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]' > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1691) Add test if Mechansim Database cover cipher suites from JDK

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/ELY-1691?page=com.atlassian.jira.plugin.s... ] Diana Vilkolakova reassigned ELY-1691: -------------------------------------- Assignee: Diana Vilkolakova > Add test if Mechansim Database cover cipher suites from JDK > ----------------------------------------------------------- > > Key: ELY-1691 > URL: https://issues.jboss.org/browse/ELY-1691 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Assignee: Diana Vilkolakova > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

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

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Martin Choma commented on WFLY-11604: ------------------------------------- Last time I was talking with Nikoleta, this is happening also with Elytron default security domain turned on. > 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-589) Author - [hhovsepy] - testcases update

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-589?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan resolved SWSQE-589. ---------------------------------- Resolution: Done > Author - [hhovsepy] - testcases update > --------------------------------------- > > Key: SWSQE-589 > URL: https://issues.jboss.org/browse/SWSQE-589 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4309) Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/WFCORE-4309?page=com.atlassian.jira.plugi... ] Diana Vilkolakova reassigned WFCORE-4309: ----------------------------------------- Assignee: Diana Vilkolakova > Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource > ------------------------------------------------------------------------------------- > > Key: WFCORE-4309 > URL: https://issues.jboss.org/browse/WFCORE-4309 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Reporter: Jan Stourac > Assignee: Diana Vilkolakova > Priority: Minor > > There is not validation for 'host-context-map' property values on key side. There is validation for the values that represents 'server-ssl-contexts', although, there is no validation for host matching part. E.g. writing attribute of this value is possible: > {code} > /subsystem=elytron/server-ssl-sni-context=serverSslSniCtx:write-attribute(name=host-context-map,value={"\\?.example.com"=validSslContext,"..example.com"="validSslContext", "\\*\\*.example.com"=validSslContext}) > {code} > {code} > "\\?.example.com" > "..example.com" > "\\*\\*.example.com" > {code} > even though, these are invalid host name matchers IMHO. It would be nice to identify these and report those to user immediately during the configuration attempt. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-534) [RS] Operators

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-534?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-534: ------------------------------------------ Summary: [RS] Operators (was: [RS] Operators - Istio + Kiali) > [RS] Operators > -------------- > > Key: SWSQE-534 > URL: https://issues.jboss.org/browse/SWSQE-534 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Minor > > Create an operator for installing Test Mesh -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-534) [RS] Operators - Istio + Kiali

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-534?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-534: ------------------------------------------ Description: Create an operator for installing Test Mesh > [RS] Operators - Istio + Kiali > ------------------------------ > > Key: SWSQE-534 > URL: https://issues.jboss.org/browse/SWSQE-534 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Minor > > Create an operator for installing Test Mesh -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019