September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13849) Decouple version.org.infinispan.server from version.org.infinispan

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13849?page=com.atlassian.jira.plugi... ] Radoslav Husar moved JBEAP-20184 to WFLY-13849: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13849 (was: JBEAP-20184) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System Clustering (was: Build System) (was: Clustering) Fix Version/s: (was: 7.4.0.CD21) > Decouple version.org.infinispan.server from version.org.infinispan > ------------------------------------------------------------------ > > Key: WFLY-13849 > URL: https://issues.redhat.com/browse/WFLY-13849 > Project: WildFly > Issue Type: Bug > Components: Build System, Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > With changes introduced in [1] we started to observe failures in _Building WildFly Test Suite: Integration - Clustering_ Maven step. > In our productized builds the _version.org.infinispan.server_ property value points to the unexisting URL (e.g. [2]). > Well, we might provide the value (aligned with the upstream version of infinispan server) and that would fix the build step - but we don't have an access to URL [3] in order to list available versions. > [1] - https://github.com/wildfly/wildfly/pull/13377/files#diff-3ddc6126e22d89cc... > [2] - https://downloads.jboss.org/infinispan/10.1.8.Final-redhat-00001/infinisp... > [3] - https://downloads.jboss.org/infinispan/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-114) Release Elytron Web 1.8.0.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-114?page=com.atlassian.jira.plugi... ] Farah Juma resolved ELYWEB-114. ------------------------------- Resolution: Done > Release Elytron Web 1.8.0.Final > ------------------------------- > > Key: ELYWEB-114 > URL: https://issues.redhat.com/browse/ELYWEB-114 > Project: Elytron Web > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.8.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13840) Problematic Language usage deprecation and replacement

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13840?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13840: ------------------------------ Description: The engineering performed preliminary analysis as per the guidance and then identified the following areas related to ejb to be replaced: blacklist in wildfly-naming-client repo (impact 1, maybe 2) blacklist in jboss-ejb-client (impact 1, 2) use of blacklist, whitelist, slave in ejb3 subsystem was: The engineering performed preliminary analysis as per the guidance [1] and then identified the following areas related to ejb to be replaced: blacklist in wildfly-naming-client repo (impact 1, maybe 2) blacklist in jboss-ejb-client (impact 1, 2) use of blacklist, whitelist, slave in ejb3 subsystem [1]https://docs.google.com/document/d/19KSYtmOKK9KQ0qHN6Ix338CrzcWbdQPZ1FI... > Problematic Language usage deprecation and replacement > ------------------------------------------------------ > > Key: WFLY-13840 > URL: https://issues.redhat.com/browse/WFLY-13840 > Project: WildFly > Issue Type: Task > Components: EJB > Affects Versions: 20.0.1.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > The engineering performed preliminary analysis as per the guidance and then identified the following areas related to ejb to be replaced: > blacklist in wildfly-naming-client repo (impact 1, maybe 2) > blacklist in jboss-ejb-client (impact 1, 2) > use of blacklist, whitelist, slave in ejb3 subsystem > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13848) Add a new security-plugins module

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13848: --------------------------------------- Summary: Add a new security-plugins module Key: WFLY-13848 URL: https://issues.redhat.com/browse/WFLY-13848 Project: WildFly Issue Type: Sub-task Components: Security Affects Versions: 20.0.1.Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 21.0.0.Beta1 The package "org.jboss.as.security.plugins" needs to be split out as the web services subsystem has a dependency on the legacy security subsystem module just to access this - if we split this out then webservices will not pull in the security subsystem module with it's layer. The new module should be marked as private This new module will also need to contain the "org.jboss.as.security.lru" package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2501) Jgroup view not stabilized after upgrading from 3.4.3 to 4.0.10

by Ajay Sharma (Jira)

[ https://issues.redhat.com/browse/JGRP-2501?page=com.atlassian.jira.plugin... ] Ajay Sharma updated JGRP-2501: ------------------------------ Summary: Jgroup view not stabilized after upgrading from 3.4.3 to 4.0.10 (was: Jgroup view not stabilized after upgrading from 3.4.3 to 4.01.0) > Jgroup view not stabilized after upgrading from 3.4.3 to 4.0.10 > --------------------------------------------------------------- > > Key: JGRP-2501 > URL: https://issues.redhat.com/browse/JGRP-2501 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.10 > Reporter: Ajay Sharma > Assignee: Bela Ban > Priority: Major > > Hi > we have 15 node cluster after upgrading Jgroup from 3.4.3 to 4.0.10, system is unstable and keep getting below logs > 2020-09-03 11:47:30.317 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|123]; discarding it > 2020-09-03 11:47:32.316 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([vmc0208-48939|123]) doesn't match the current view-id ([vmc0208-48939|122]); discarding delta view [vmc0208-48939|124], ref-view=[vmc0208-48939|123], joined=[vmc0198-5504] > 2020-09-03 11:47:32.323 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|124]; discarding it. > 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-63871: dropped message batch from non-member vmc0201-28703 (view=MergeView::[vmc0208-48939|140] (24) [ ***REMOVING MACHINE NAME AND PORT ***] ]) > 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-23411: dropped message batch from non-member vmc0201-28703 (view=[***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW ***] .]) > 2020-09-05 16:16:07.380 DEBUG org.jgroups.protocols.FD_ALL - haven't received a heartbeat from vmc0201-55458 for 12541 ms, adding it to suspect list > 2020-09-05 16:16:07.535 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: failed connecting to vmc0204-45403: connect timed out > 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: broadcasting suspect(vmc0204-45403) > 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: pingable_mbrs=[***REMOVING MACHINE NAME AND PORT ***], ping_dest=vmc0204-54485 > 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-52842: installing view [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ] > 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-24881: installing view [vmc0200-30543|2672] (184) [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ] > =================================== > To isolate the issue we have created a small program both in Jgroup 3.4.3 and Jgroups 4.0.10 > Both applications take IP addresses and the number of channels as arguments. We have run both applications in the following matrix and collected view data and timings. > Below are the stats: > Number of members (number of nodes x number of channels) Jgroups 3.4.3 Jgroup 4.0.10 > 225 (15x15) Simultaneous start 25 - 30 seconds* 15 minutes** > 225 (15x15) Rolling start (view after 15th node start) 20 seconds* 10 minutes** > 196 (14x14) Simultaneous start 25 seconds* 4 minutes** > 169 (13x13) Simultaneous start 30 - 31 seconds* 7 minutes** > 144 (12x12) Simultaneous start 27 seconds* 5 minutes** > 121 (11x11) Simultaneous start 22 seconds* 2 minutes** > 100 (10x10) Simultaneous start 20 seconds* 5 minutes** > ... > ... > 9 to 49 channels (3x3) to (7x7) almost immediate* almost immediate* > Note: Even after taking 15 minutes, views are not stable its keeps fluctuating. > ======= > Below are my protocols used with properties: > Protocol[] protocolStack={ > new UDP().setValue("bind_addr",InetAddress.getByName(myBindAddress)).setValue("mcast_port", 10600).setValue("bind_port", 10601) > .setValue("port_range", 100).setValue("diagnostics_bind_interfaces", parInterfaceList).setValue("diagnostics_port", 10599), > new PING(), > new MERGE3(), > new FD_SOCK().setValue("bind_addr", InetAddress.getByName(myBindAddress)), > new FD_ALL().setValue("timeout", 12000).setValue("interval", 3000), > new VERIFY_SUSPECT().setValue("bind_addr", InetAddress.getByName(myBindAddress)), > new BARRIER(), > new NAKACK2(), > new UNICAST3(), > new STABLE(), > new GMS().setValue("print_local_addr", true), > new UFC(), > new MFC(), > new FRAG2()}; > However, we tried to update below few properties value but no luck > thread_pool_max_threads = 200 in UDP() > Default values of FD_ALL() -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2501) Jgroup view not stabilized after upgrading from 3.4.3 to 4.01.0

by Ajay Sharma (Jira)

Ajay Sharma created JGRP-2501: --------------------------------- Summary: Jgroup view not stabilized after upgrading from 3.4.3 to 4.01.0 Key: JGRP-2501 URL: https://issues.redhat.com/browse/JGRP-2501 Project: JGroups Issue Type: Bug Affects Versions: 4.0.10 Reporter: Ajay Sharma Assignee: Bela Ban Hi we have 15 node cluster after upgrading Jgroup from 3.4.3 to 4.0.10, system is unstable and keep getting below logs 2020-09-03 11:47:30.317 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|123]; discarding it 2020-09-03 11:47:32.316 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([vmc0208-48939|123]) doesn't match the current view-id ([vmc0208-48939|122]); discarding delta view [vmc0208-48939|124], ref-view=[vmc0208-48939|123], joined=[vmc0198-5504] 2020-09-03 11:47:32.323 WARN org.jgroups.protocols.pbcast.GMS - vmc0198-27827: not member of view [vmc0208-48939|124]; discarding it. 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-63871: dropped message batch from non-member vmc0201-28703 (view=MergeView::[vmc0208-48939|140] (24) [ ***REMOVING MACHINE NAME AND PORT ***] ]) 2020-09-03 11:49:07.160 WARN org.jgroups.protocols.pbcast.NAKACK2 - JGRP000011: vmc0198-23411: dropped message batch from non-member vmc0201-28703 (view=[***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW ***] .]) 2020-09-05 16:16:07.380 DEBUG org.jgroups.protocols.FD_ALL - haven't received a heartbeat from vmc0201-55458 for 12541 ms, adding it to suspect list 2020-09-05 16:16:07.535 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: failed connecting to vmc0204-45403: connect timed out 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: broadcasting suspect(vmc0204-45403) 2020-09-05 16:16:07.536 DEBUG org.jgroups.protocols.FD_SOCK - vmc0198-24881: pingable_mbrs=[***REMOVING MACHINE NAME AND PORT ***], ping_dest=vmc0204-54485 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-52842: installing view [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ] 2020-09-05 16:16:08.513 DEBUG org.jgroups.protocols.pbcast.GMS - vmc0198-24881: installing view [vmc0200-30543|2672] (184) [ ***REMOVING MACHINE NAME AND PORT FOR CLEAR VIEW *** ] =================================== To isolate the issue we have created a small program both in Jgroup 3.4.3 and Jgroups 4.0.10 Both applications take IP addresses and the number of channels as arguments. We have run both applications in the following matrix and collected view data and timings. Below are the stats: Number of members (number of nodes x number of channels) Jgroups 3.4.3 Jgroup 4.0.10 225 (15x15) Simultaneous start 25 - 30 seconds* 15 minutes** 225 (15x15) Rolling start (view after 15th node start) 20 seconds* 10 minutes** 196 (14x14) Simultaneous start 25 seconds* 4 minutes** 169 (13x13) Simultaneous start 30 - 31 seconds* 7 minutes** 144 (12x12) Simultaneous start 27 seconds* 5 minutes** 121 (11x11) Simultaneous start 22 seconds* 2 minutes** 100 (10x10) Simultaneous start 20 seconds* 5 minutes** ... ... 9 to 49 channels (3x3) to (7x7) almost immediate* almost immediate* Note: Even after taking 15 minutes, views are not stable its keeps fluctuating. ======= Below are my protocols used with properties: Protocol[] protocolStack={ new UDP().setValue("bind_addr",InetAddress.getByName(myBindAddress)).setValue("mcast_port", 10600).setValue("bind_port", 10601) .setValue("port_range", 100).setValue("diagnostics_bind_interfaces", parInterfaceList).setValue("diagnostics_port", 10599), new PING(), new MERGE3(), new FD_SOCK().setValue("bind_addr", InetAddress.getByName(myBindAddress)), new FD_ALL().setValue("timeout", 12000).setValue("interval", 3000), new VERIFY_SUSPECT().setValue("bind_addr", InetAddress.getByName(myBindAddress)), new BARRIER(), new NAKACK2(), new UNICAST3(), new STABLE(), new GMS().setValue("print_local_addr", true), new UFC(), new MFC(), new FRAG2()}; However, we tried to update below few properties value but no luck thread_pool_max_threads = 200 in UDP() Default values of FD_ALL() -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13846) Eliminate dependency on legacy security subsystem module from connector subsystem

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13846?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13846: ------------------------------------ Parent: WFLY-13659 Issue Type: Sub-task (was: Task) > Eliminate dependency on legacy security subsystem module from connector subsystem > --------------------------------------------------------------------------------- > > Key: WFLY-13846 > URL: https://issues.redhat.com/browse/WFLY-13846 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Affects Versions: 20.0.1.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > The dependencies seem more about access to a constant service name so this is easily forkable to eliminate the dependency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13692) Anything in jboss-all.xml after <weld/> element is ignored

by Sudeshna Sur (Jira)

[ https://issues.redhat.com/browse/WFLY-13692?page=com.atlassian.jira.plugi... ] Sudeshna Sur reassigned WFLY-13692: ----------------------------------- Assignee: Sudeshna Sur (was: Matěj Novotný) > Anything in jboss-all.xml after <weld/> element is ignored > ---------------------------------------------------------- > > Key: WFLY-13692 > URL: https://issues.redhat.com/browse/WFLY-13692 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 20.0.1.Final > Reporter: L K > Assignee: Sudeshna Sur > Priority: Major > > Classes org.jboss.as.weld.WeldJBossAll10Parser and org.jboss.as.weld.WeldJBossAll11Parser are incorrect. They do not parse <weld> element as XML, they just check attributes. > As a result, everything that comes after </weld> is ignored. > This jboss-all.xml fails, as expected: > {code:java} > <jboss xmlns="urn:jboss:1.0"> > <some-stupid-element/> > <weld xmlns="urn:jboss:weld:1.1"/> > </jboss> > {code} > This one is successfully parsed (but must also fail): > {code:java} > <jboss xmlns="urn:jboss:1.0"> > <weld xmlns="urn:jboss:weld:1.1"/> > <some-stupid-element/> > </jboss> > {code} > > Now imagine that "some-stupid-element" is in fact "jboss-deployment-structure" which gets ignored... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13847) Eliminate dependency on legacy security subsystem module from connector subsystem

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13847: --------------------------------------- Summary: Eliminate dependency on legacy security subsystem module from connector subsystem Key: WFLY-13847 URL: https://issues.redhat.com/browse/WFLY-13847 Project: WildFly Issue Type: Task Components: JCA Affects Versions: 20.0.1.Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 21.0.0.Beta1 The dependencies seem more about access to a constant service name so this is easily forkable to eliminate the dependency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-354) Bootable JAR - jboss-maven-dist plugin param doesn't work as expected

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-354?page=com.atlassian.jira.plugin... ] Jean Francois Denise commented on WFWIP-354: -------------------------------------------- [~tommaso-borgato], in addition, the chapter "11.1. Provisioning a slim bootable jar' in [https://github.com/wildfly-extras/wildfly-jar-maven-plugin/releases/downl... it. > Bootable JAR - jboss-maven-dist plugin param doesn't work as expected > ---------------------------------------------------------------------- > > Key: WFWIP-354 > URL: https://issues.redhat.com/browse/WFWIP-354 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Jean Francois Denise > Priority: Blocker > > Related RFE: EAP7-1385 > This usage of jboss-maven-dist plugin param doesn't work as expected: > [<jboss-maven-dist>/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository</jboss-maven-dist>|https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8020a649db002980#diff-8c7ea03eb619e46657b96e8fe8d4f09eR248] > Steps to reproduce: > # clone resteasy 3.12 with this commit: https://github.com/marekkopecky/Resteasy/commit/fb29381a9ef9a709f33481af8... > # update jboss-maven-dist plugin param to your custom repo path > # rm -rf ~/.m2/repository/xerces/xercesImpl/2.12.0.SP03 > # set REPO variable (eg. "REPO=/home/mkopecky/jboss-eap-custom-maven-repository/maven-repository") > # build start tests {code}mvn install -DskipTests -Dmaven.repo.local=$REPO > cd testsuite > mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml -Dmaven.repo.local=$REPO > cd integration-tests > mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=21.0.0.Beta1-SNAPSHOT -Dserver.home=placeholder -Dmaven.repo.local=$REPO -Dmaven.test.redirectTestOutputToFile=false{code} > # see the results: org.jboss.modules.ModuleLoadException, because xercesImpl 2.12.0.SP03 is downloaded in custom repo, but not present in .m2 > cc [~fburzigo], [~yersan] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 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 September 2020