January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not clearing the crashed members

by Sibin Karnavar (JIRA)

Sibin Karnavar created JGRP-2245: ------------------------------------ Summary: JGroup JDBC_PING is not clearing the crashed members Key: JGRP-2245 URL: https://issues.jboss.org/browse/JGRP-2245 Project: JGroups Issue Type: Bug Affects Versions: 4.0.8 Reporter: Sibin Karnavar Assignee: Bela Ban Priority: Critical 1) In AWS cloud environments, IP address will be different when a node crashes and when a new node gets recreated. 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused when other nodes restarts. 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable. I think the issue is handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table. // remove all files which are not from the current members protected void handleView(View new_view, View old_view, boolean coord_changed) { if(is_coord) { if(coord_changed) { if(remove_all_data_on_view_change) removeAll(cluster_name); else if(remove_old_coords_on_view_change) { Address old_coord=old_view != null? old_view.getCreator() : null; if(old_coord != null) remove(cluster_name, old_coord); } } if(coord_changed || View.diff(old_view, new_view)[1].length > 0) { writeAll(); if(remove_all_data_on_view_change || remove_old_coords_on_view_change) startInfoWriter(); } } else if(coord_changed) // I'm no longer the coordinator remove(cluster_name, local_addr); } 4) because of the crashed members non existing ip address sendToMembers of TP is trying to send messages to old crashed members and writing error logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-188) Allow the configuration API to not persist properties when writing a configuration file

by James Perkins (JIRA)

James Perkins created LOGMGR-188: ------------------------------------ Summary: Allow the configuration API to not persist properties when writing a configuration file Key: LOGMGR-188 URL: https://issues.jboss.org/browse/LOGMGR-188 Project: JBoss Log Manager Issue Type: Feature Request Reporter: James Perkins Assignee: James Perkins With the introduction of the [{{DelayedHandler}}|LOGMGR-177] it may be desirable for configurations not to persist some data to the {{logging.properties}} configuration file. This should include all generic properties plus child handler names. The level, filter, encoding, formatter and error manager will always be persisted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3522) Module dependency order for a deployment is wrong

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3522?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3522: ------------------------------------- This is another example of why parent-first class loading is always wrong. We should instead be excluding the set of packages in deployment resource loaders that are found in dependencies that we want to flag (along with a hefty warning or error message). > Module dependency order for a deployment is wrong > ------------------------------------------------- > > Key: WFCORE-3522 > URL: https://issues.jboss.org/browse/WFCORE-3522 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.8.Final > Reporter: Ken Finnigan > Priority: Blocker > > Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile. > With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead. > He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3522) Module dependency order for a deployment is wrong

by Ken Finnigan (JIRA)

Ken Finnigan created WFCORE-3522: ------------------------------------ Summary: Module dependency order for a deployment is wrong Key: WFCORE-3522 URL: https://issues.jboss.org/browse/WFCORE-3522 Project: WildFly Core Issue Type: Bug Affects Versions: 3.0.8.Final Reporter: Ken Finnigan Priority: Blocker Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile. With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead. He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-185) The ConsoleHandler.setTarget() doesn't allow for a null value to be passed

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-185?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-185: --------------------------------- Priority: Blocker (was: Major) > The ConsoleHandler.setTarget() doesn't allow for a null value to be passed > -------------------------------------------------------------------------- > > Key: LOGMGR-185 > URL: https://issues.jboss.org/browse/LOGMGR-185 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 2.1.0.Alpha5 > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 2.1.0.Alpha6 > > > If the {{ConsoleHandler}} is reset as a result of LOGMGR-178 a {{null}} value may be passed to the {{ConsoleHandler.setTarget()}} method which should handle a {{null}} value. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-134) Add module name, module version fields to ExtLogRecord

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-134?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-134: ------------------------------------ Assignee: David Lloyd > Add module name, module version fields to ExtLogRecord > ------------------------------------------------------ > > Key: LOGMGR-134 > URL: https://issues.jboss.org/browse/LOGMGR-134 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 2.1.0.Alpha6 > > > It will be necessary for ExtLogRecord to carry additional fields for Java 9 module name and module version. The serialization impact should be analyzed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-185) The ConsoleHandler.setTarget() doesn't allow for a null value to be passed

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-185?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-185: --------------------------------- Fix Version/s: 2.1.0.Alpha6 > The ConsoleHandler.setTarget() doesn't allow for a null value to be passed > -------------------------------------------------------------------------- > > Key: LOGMGR-185 > URL: https://issues.jboss.org/browse/LOGMGR-185 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 2.1.0.Alpha5 > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha6 > > > If the {{ConsoleHandler}} is reset as a result of LOGMGR-178 a {{null}} value may be passed to the {{ConsoleHandler.setTarget()}} method which should handle a {{null}} value. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2252) "Unable to expand" error with acculumate in Guided Rule Editor with DSL

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2252?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2252: ----------------------------------- Sprint: 2018 Week 03-04 > "Unable to expand" error with acculumate in Guided Rule Editor with DSL > ----------------------------------------------------------------------- > > Key: DROOLS-2252 > URL: https://issues.jboss.org/browse/DROOLS-2252 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Labels: support > > In Guided Rule Editor with DSL option, you can add "From Accumulate" but "Function"/"Custom Code" gets an error "Unable to expand". > Reproduce steps: > - Unzip the attached reproducer-repo.zip > - Clone the repo via business-central "Administration" > "Repositories" > "Clone Repository" > - Go to Project Explorer, choose the repo, choose "project1" > - Go to package org > kie > example > project1. You will find DataObject 'Person,' DSL, Test Scenario > - Create a new Guided Rule. Check "Use Domain Specific Language (DSL)" option > - Add conditions (See guidedrule01.png) > -- DSL "There is a person whose age is 20" > -- "From Accumulate ..." > --- Choose "Number" for the first "click to add pattern..." > --- Choose "Person" for the second "click to add pattern..." > --- Configure Variable name "$p" for "All Person with" > -- Write "count($p)" in Function > - Save > - Press "Validate" > - You will get an error "Unable to expand" (See error01.png) > This is because "count($p)" line doesn't have preceding ">". > {noformat} > rule "gr1" > dialect "mvel" > when > There is a person whose age is 20 > >Number( ) from accumulate ( $p : Person( ), > count($p)) > then > end > {noformat} > - If you add ">" at the begging of Function (See guidedrule02.png), you don't get the error. > - But if you close the Editor and reopen the rdslr, the condition is rendered as free form DRL (See guidedrule03.png). So it cannot be a workaround. > - "Custom Code" has the same problem as "Function". Furthermore, "Custom Code" cannot use ">" because ">" wouldn't be placed at the beginning of the line. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2252) "Unable to expand" error with acculumate in Guided Rule Editor with DSL

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2252?page=com.atlassian.jira.plugi... ] Michael Anstis moved RHDM-284 to DROOLS-2252: --------------------------------------------- Project: Drools (was: Red Hat Decision Manager) Key: DROOLS-2252 (was: RHDM-284) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: Guided Rule Editor (was: Decision Central) Affects Version/s: 7.5.0.Final (was: 6.x.x) QE Status: NEW > "Unable to expand" error with acculumate in Guided Rule Editor with DSL > ----------------------------------------------------------------------- > > Key: DROOLS-2252 > URL: https://issues.jboss.org/browse/DROOLS-2252 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Labels: support > > In Guided Rule Editor with DSL option, you can add "From Accumulate" but "Function"/"Custom Code" gets an error "Unable to expand". > Reproduce steps: > - Unzip the attached reproducer-repo.zip > - Clone the repo via business-central "Administration" > "Repositories" > "Clone Repository" > - Go to Project Explorer, choose the repo, choose "project1" > - Go to package org > kie > example > project1. You will find DataObject 'Person,' DSL, Test Scenario > - Create a new Guided Rule. Check "Use Domain Specific Language (DSL)" option > - Add conditions (See guidedrule01.png) > -- DSL "There is a person whose age is 20" > -- "From Accumulate ..." > --- Choose "Number" for the first "click to add pattern..." > --- Choose "Person" for the second "click to add pattern..." > --- Configure Variable name "$p" for "All Person with" > -- Write "count($p)" in Function > - Save > - Press "Validate" > - You will get an error "Unable to expand" (See error01.png) > This is because "count($p)" line doesn't have preceding ">". > {noformat} > rule "gr1" > dialect "mvel" > when > There is a person whose age is 20 > >Number( ) from accumulate ( $p : Person( ), > count($p)) > then > end > {noformat} > - If you add ">" at the begging of Function (See guidedrule02.png), you don't get the error. > - But if you close the Editor and reopen the rdslr, the condition is rendered as free form DRL (See guidedrule03.png). So it cannot be a workaround. > - "Custom Code" has the same problem as "Function". Furthermore, "Custom Code" cannot use ">" because ">" wouldn't be placed at the beginning of the line. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3521) Display dynamic capabilities with a pattern

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-3521: ----------------------------------------- Summary: Display dynamic capabilities with a pattern Key: WFCORE-3521 URL: https://issues.jboss.org/browse/WFCORE-3521 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 4.0.0.Alpha5 Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet Currently when we describe a resource or an attribute with dynamic capabilities we show only the static part of the name. The goal of this enhancement is to display a dynamic 'pattern' of this capability name using $dynamic_part for each part. Thus we would have :"org.wildfly.undertow.host.$default-server.$default-virtual-host" for the "org.wildfly.undertow.host" capability in undertow subsystem for example. We would be using another key in order not to break tools relying on the old format. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2018