January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12900) Clustering TS: Default to non-multicast discovery protocol

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12900?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12900: ---------------------------------- Affects Version/s: 19.0.0.Beta1 > Clustering TS: Default to non-multicast discovery protocol > ---------------------------------------------------------- > > Key: WFLY-12900 > URL: https://issues.redhat.com/browse/WFLY-12900 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > We have been slowly making progress on reducing reliance on multicast to run the clustering test suite by default given the complexity of system configuration (e.g. multicast on {{::1}} workarounds). The goal is to use a default non-multicast-based protocol by defaut. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12845) Upgrade JGroups to 4.1.9.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12845?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12845: ---------------------------------- Affects Version/s: 19.0.0.Beta1 > Upgrade JGroups to 4.1.9.Final > ------------------------------ > > Key: WFLY-12845 > URL: https://issues.redhat.com/browse/WFLY-12845 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.1.Final, 19.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Just a tracker for now. > Changelog > https://issues.jboss.org/projects/JGRP/versions/12343163 > The fix for JGRP-2409 has caused compilation failure thus updating the https://github.com/wildfly-clustering/wildfly/tree/jgroups-master branch with the fix from which PR will be opened. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4830) Add a Docker composer to connect BC and Kie Server images

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4830?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-4830: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > Add a Docker composer to connect BC and Kie Server images > --------------------------------------------------------- > > Key: DROOLS-4830 > URL: https://issues.redhat.com/browse/DROOLS-4830 > Project: Drools > Issue Type: Feature Request > Components: docker images > Affects Versions: 7.30.0.Final > Reporter: Ricardo Zanini Fernandes > Assignee: Ricardo Zanini Fernandes > Priority: Major > Fix For: 7.33.0.Final > > > It's natural to have BC and KIE servers working together. Would be nice to have a Docker composer file that fires up the two instances at once. This will support use cases such authoring on BC and deploying in the connected KIE Server. > References: https://www.drools.org/download/download.html -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3160) adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm)

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-3160?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-3160: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm) > ------------------------------------------------------------ > > Key: DROOLS-3160 > URL: https://issues.redhat.com/browse/DROOLS-3160 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Biarnes Kiefer > Assignee: Toni Rikkola > Priority: Major > Fix For: 7.33.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-2254?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-2254: ------------------------------------------- Fix Version/s: 7.33.0.Final (was: 7.32.0.Final) > Automate .proto files rebuild in pom.xml > ---------------------------------------- > > Key: DROOLS-2254 > URL: https://issues.redhat.com/browse/DROOLS-2254 > Project: Drools > Issue Type: Task > Components: tools > Affects Versions: 7.5.0.Final > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > Fix For: 7.33.0.Final > > > According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files. > This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4810) Upgrade WildFly Elytron to 1.11.1.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4810?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4810: ------------------------------- Fix Version/s: 11.0.0.Beta8 > Upgrade WildFly Elytron to 1.11.1.Final > --------------------------------------- > > Key: WFCORE-4810 > URL: https://issues.redhat.com/browse/WFCORE-4810 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1925?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1925: ---------------------------- Fix Version/s: 1.11.2.CR1 (was: 1.11.1.Final) > Release WildFly Elytron 1.11.1.Final > ------------------------------------ > > Key: ELY-1925 > URL: https://issues.redhat.com/browse/ELY-1925 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.1.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1925?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1925: ---------------------------- Fix Version/s: 1.11.1.Final (was: 1.11.2.CR1) > Release WildFly Elytron 1.11.1.Final > ------------------------------------ > > Key: ELY-1925 > URL: https://issues.redhat.com/browse/ELY-1925 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.1.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

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

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ] Richard Achmatowicz updated WFLY-13009: --------------------------------------- Description: When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. was: When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. > moduleAvailability message is sent before module has started > ------------------------------------------------------------ > > Key: WFLY-13009 > URL: https://issues.redhat.com/browse/WFLY-13009 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 19.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Paul Ferraro > Priority: Major > > When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. > The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). > It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 2020