December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall edited comment on WFLY-9641 at 12/27/19 11:31 AM: --------------------------------------------------------------- This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. modcluster has been removed since we're using nginx load balancer in ip_hash mode. There are other timeout issues when nginx fails over to a different node despite the cluster view updating. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred and attempts to bind either the 172 or 10 ifc are failing to allow external access. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. was (Author: gregoryhall994): This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall edited comment on WFLY-9641 at 12/27/19 11:27 AM: --------------------------------------------------------------- This also affects Wildfly 16 (I'm trying to cluster keycloak 6.0.1 which is based on Wildfly 16) I'm running in a docker container hosted in AWS cloud where multicast isn't an option. I've configured external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. was (Author: gregoryhall994): I'm trying to cluster keycloak 6.0.1 based on Wildfly 16 in a docker container and having this issue. I've been setting external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9641) Cluster EJB can not work with "-b 0.0.0.0"

by Gregory Hall (Jira)

[ https://issues.redhat.com/browse/WFLY-9641?page=com.atlassian.jira.plugin... ] Gregory Hall commented on WFLY-9641: ------------------------------------ I'm trying to cluster keycloak 6.0.1 based on Wildfly 16 in a docker container and having this issue. I've been setting external addresses on all the JGroups TCPPING protocol options. Not sure what the best tactic as using 0.0.0.0 inside a container is definitely preferred. The basic pretense that the ejb cluster would second guess routability through an inadequate test sounds wrong. Due to NAT with/without docker containers and networks, the best practice would be to try to connect and if you throw a NoRouteToHost, deal with that. > Cluster EJB can not work with "-b 0.0.0.0" > ------------------------------------------ > > Key: WFLY-9641 > URL: https://issues.redhat.com/browse/WFLY-9641 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Fred Ling > Priority: Major > Labels: cluster, ejb, wildfly > > The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0. > The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0. > For more information please refer to the forum thread. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12912) Upgrade RESTEasy to 3.10.0.Final

by Ronald Sigal (Jira)

Ronald Sigal created WFLY-12912: ----------------------------------- Summary: Upgrade RESTEasy to 3.10.0.Final Key: WFLY-12912 URL: https://issues.redhat.com/browse/WFLY-12912 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Ivo Studensky Assignee: Alessio Soldano Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12912) Upgrade RESTEasy to 3.10.0.Final

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-12912?page=com.atlassian.jira.plugi... ] Ronald Sigal closed WFLY-12912. ------------------------------- Resolution: Duplicate Issue > Upgrade RESTEasy to 3.10.0.Final > -------------------------------- > > Key: WFLY-12912 > URL: https://issues.redhat.com/browse/WFLY-12912 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12779) Incorporate MicroProfile Config in RESTEasy

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-12779?page=com.atlassian.jira.plugi... ] Ronald Sigal commented on WFLY-12779: ------------------------------------- Additional information about https://github.com/resteasy/Resteasy/pull/2250 is given on the analysis document pull request (https://github.com/wildfly/wildfly-proposals/pull/262). > Incorporate MicroProfile Config in RESTEasy > ------------------------------------------- > > Key: WFLY-12779 > URL: https://issues.redhat.com/browse/WFLY-12779 > Project: WildFly > Issue Type: Feature Request > Reporter: Ronald Sigal > Assignee: Ronald Sigal > Priority: Major > > Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources: > * servlet init-params (ordinal 60) > * filter init-params (ordinal 50) > * servlet context-params (ordinal 40) > In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x. > In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true". -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2374?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2374: --------------------------- Fix Version/s: 4.1.9 (was: 5.1) > TCP/TCP_NIO2: add TLS > --------------------- > > Key: JGRP-2374 > URL: https://issues.redhat.com/browse/JGRP-2374 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.9 > > > Add TLS to the TCP and TCP_NIO2 transports. Look into wildfly-openssl [1] for the impl. > [1] https://github.com/wildfly-security/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2374?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2374: -------------------------------- Also important for xsite via TUNNEL and GossipRouter > TCP/TCP_NIO2: add TLS > --------------------- > > Key: JGRP-2374 > URL: https://issues.redhat.com/browse/JGRP-2374 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.9 > > > Add TLS to the TCP and TCP_NIO2 transports. Look into wildfly-openssl [1] for the impl. > [1] https://github.com/wildfly-security/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2420) Look at submariner for xsite traffic

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2420?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2420: --------------------------- Summary: Look at submariner for xsite traffic (was: Look at submarioner for xsite traffic) > Look at submariner for xsite traffic > ------------------------------------ > > Key: JGRP-2420 > URL: https://issues.redhat.com/browse/JGRP-2420 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.1.9 > > > See whether submariner can help with xsite (especially if we can avoid the LB issues). > [1] submariner.io -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4898) Accumulates: min does not work after retracting fact.

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4898?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-4898: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Accumulates: min does not work after retracting fact. > ----------------------------------------------------- > > Key: DROOLS-4898 > URL: https://issues.redhat.com/browse/DROOLS-4898 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.26.0.Final, 7.31.0.Final > Reporter: Hiroko Miura > Assignee: Mario Fusco > Priority: Major > Labels: support > > The following rules does not work with specific facts. > {noformat} > rule "rule1_long" > when > accumulate( Fact( $longVal: longVal), $minVal : min($longVal)) > accumulate( Fact( $longVal2: longVal, $longVal2 > $minVal), $minVal2 : min($longVal2)) > $minFact: Fact( longVal == $minVal) > $minFact2: Fact( longVal == $minVal2) > then > System.out.println("Rule ["+kcontext.getRule().getName()+ "] fires!"); > Long $diff = (Long)$minVal2 - (Long)$minVal; > $minFact2.setDiff($diff); > // update($minFact2); > String errmsg = $diff == 0? " !!!!! ERROR !!!!!" : ""; > System.out.println( drools.getRule().getName() + " diff：" + $minFact2.getLongVal() + " - " + $minFact.getLongVal() + " = " + $diff + errmsg); > System.out.println("\tretract <= "+$minFact ); > retract($minFact); > end > {noformat} > There seems to be 2 kind of issues (root cause might be same though). > - 2nd accumulate return same min value with 1st one. > - rule fire count is less than expected. > This does not work with specific set of facts, but works with another set of facts. > If update is called for the fact like above commented out line, this does not happen. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 December 2019