April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-7728. ----------------------------- Resolution: Out of Date > Increased Memory footprint in recent builds > ------------------------------------------- > > Key: WFLY-7728 > URL: https://issues.jboss.org/browse/WFLY-7728 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended. > Test scenario: > # Start EAP instance. > # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times. > We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3197) jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3197?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-3197: ----------------------------------- Assignee: James Perkins (was: Tomaz Cerar) > jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3197 > URL: https://issues.jboss.org/browse/WFCORE-3197 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: centOs > Reporter: Nuno Godinho de Matos > Assignee: James Perkins > Priority: Trivial > > Hi, I am currently migrating some windows batch scripts associated to an automated create domain/stanadlone process. > One of these scripts, consists on faclitating the user to invoke the jboss cli to run a cli file. > While on windows the script is natrually working. > On linux centOs, the script immediately broke with the error: > {panel} > [johnDoe@localhost bin]$ sh 01_invoke_cli_file_script.sh "file99.sh" > ********************************************************** > SETUP CORE ENV VARIABLES > ********************************************************** > SET_CORE_ENV_VARS_SCRIPT_PATH=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin > CURRENT_WILDFLY_DOMAIN_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/.. > WILDFLY_DOMAINS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../.. > WILDFLY_USER_PROJECTS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../.. > WILDFLY_BASE_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../.. > WILDFLY_BIN_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../../bin > ********************************************************** > INVOKE jboss-cli.bat with script file: "file99.sh" > ********************************************************** > Error: Unable to access jarfile /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/jboss-modules.jar > <----- this some additional informaiton I am printing to make the point > RESOLVED_JBOSS_HOME: /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain > {panel} > What the above panel shows is that the RESOLVED_JBOSS_HOME is not being properly set. > This clearly constrasts with the windows behavior, where my base script can correctly invoke a : > call jboss-cli.bat -f someFilepath > and not break. > The reason for this seems that that while on windows, the script correctly makes no assumption on where the current working directory of the user is. > And only cares about the current location of the jboss-cli.bat script itself. > {panel} > if "%OS%" == "Windows_NT" ( > set "DIRNAME=%~dp0%" <-------- This here is a good approach > ) else ( > set DIRNAME=.\ > ) > {panel} > On linux, the same is not being done: > {panel} > # Setup JBOSS_HOME > RESOLVED_JBOSS_HOME=`cd "$DIRNAME/.."; pwd` <-------- This is not a good approach if dirname is calculated based on the command line DIRNAME=`dirname "$0"` > if [ "x$JBOSS_HOME" = "x" ]; then > # get the full path (without any relative bits) > JBOSS_HOME=$RESOLVED_JBOSS_HOME > else > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME"; pwd` > if [ "$RESOLVED_JBOSS_HOME" != "$SANITIZED_JBOSS_HOME" ]; then > echo "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." > echo "" > fi > fi > export JBOSS_HOME > {panel} > I would suggest that linux scripts shouild cross cuttingly assume nothing about current working directory and do something like: > {code} > #DIRNAME=`dirname "$0"` > DIRNAME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > {code} > Since I do not want to be corrupting my wildfly installation and I want to leave all scripts completely untouched, I will be changing my script invocation from: > {panel} > # source "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > /bin/bash "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > {panel} > Which is not Ideal, since in some scripts I may want to set in my run time environment variables like JAVA_OPTS to override the default ones used on start up of an app server. > So for me, in the ideal case, I would like to be able to use the source command to run any arbitrary script in the /bin folder without my current directory location playing any relevant role. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5793) Allow selective CI builds

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-5793: --------------------------------- Assignee: Ken Wills (was: Tomaz Cerar) > Allow selective CI builds > ------------------------- > > Key: WFLY-5793 > URL: https://issues.jboss.org/browse/WFLY-5793 > Project: WildFly > Issue Type: Enhancement > Reporter: Ryan Emerson > Assignee: Ken Wills > Priority: Optional > > Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md). > A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9477) Cannot create two hosts with unspecified default web module in Undertow

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9477?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9477: --------------------------------- Assignee: (was: Tomaz Cerar) > Cannot create two hosts with unspecified default web module in Undertow > ----------------------------------------------------------------------- > > Key: WFLY-9477 > URL: https://issues.jboss.org/browse/WFLY-9477 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Tomaz Cerar > Priority: Minor > > As a user, I cannot create two hosts with unspecified default web module. Currently the default-web-module is checked only for uniqueness and by default there is defined ROOT.war, which by default doesn't exist. Current behavior is that in case of non existing module defined by default-web-module, when accessing the root context ('/'), the content defined as part of welcome-file handler is provided. > As a user I should not be forced to put random values to avoid duplicity check, when I don't want to have set default-web-module. As such the default-web-module should have undefined default which could be checked and avoided failures due duplicates as there are in reality none. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10037) QS Ejb-security-jaas admin authorisation exception

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10037?page=com.atlassian.jira.plugin... ] Tomaz Cerar reassigned WFLY-10037: ---------------------------------- Assignee: Sande Gilda (was: Tomaz Cerar) > QS Ejb-security-jaas admin authorisation exception > -------------------------------------------------- > > Key: WFLY-10037 > URL: https://issues.jboss.org/browse/WFLY-10037 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 13.0.0.Beta1 > Reporter: Jozef Cibik > Assignee: Sande Gilda > Priority: Minor > > The user authenticated in client/servlet doesn't have admin authorisation, therefore server throws a stacktrace in server logs when executing "mvn exec:exec" or accessing QS URL. > Readme should mention this exception in server log. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3307) Parameters passed to standalone.sh are not printed on startup

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3307?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-3307: ----------------------------------- Assignee: James Perkins (was: Tomaz Cerar) > Parameters passed to standalone.sh are not printed on startup > ------------------------------------------------------------- > > Key: WFCORE-3307 > URL: https://issues.jboss.org/browse/WFCORE-3307 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 3.0.3.Final > Environment: linux / windows > Reporter: kobogian hitis > Assignee: James Perkins > Priority: Minor > > Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS). > Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts. > Not printing them causes confusion between what is printed and what is actually applied. > If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used. > Someone might argue about setting only JAVA_OPTS before running standalone.sh. > The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour. > So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh). > It should be possible however to be able to see them being printed somewhere. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1828) Make it easier to register add and remove handlers with customized definitions

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1828?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1828: ----------------------------------- Assignee: (was: Tomaz Cerar) > Make it easier to register add and remove handlers with customized definitions > ------------------------------------------------------------------------------ > > Key: WFCORE-1828 > URL: https://issues.jboss.org/browse/WFCORE-1828 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > > The nice way to build up a ResourceDefinition is with the Parameters object. And that works well with most add and remove handlers where the RD when building up the MRR generates a definition for the handlers. > But in cases where there needs to be some customization of the add description (e.g. deployment(-overlay) add where the content param can have fields that are not used in the content attribute) then the only option is in some way or other to override registerOperations. That or have the add OSH implement DescriptionProvider. Which we don't want. ;) > Perhaps add setAddDescription/setRemoveDescription to Parameters, or > {code} > public interface SelfDescibingOperationStepHandler extends OperationStepHandler { > OperationDefinition getDefinition(); > } > {code} > Enhancing Parameters sound better. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9173) Update JavaMail to 1.6.0 (or newer)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9173?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-9173. ------------------------------- Fix Version/s: 12.0.0.Final Resolution: Done > Update JavaMail to 1.6.0 (or newer) > ----------------------------------- > > Key: WFLY-9173 > URL: https://issues.jboss.org/browse/WFLY-9173 > Project: WildFly > Issue Type: Feature Request > Components: Mail > Affects Versions: 10.1.0.Final > Reporter: Rob Heine > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 12.0.0.Final > > > JavaMail 1.6.0 has been released. Please integrate this version in WildFly (maybe it might find its way into WildFly-10.x :) ). > Source: https://github.com/javaee/javamail/releases -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9977) Redundant CONSOLE log handler adding in CLI scripts for messaging-clustering* QS

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9977?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9977: --------------------------------- Assignee: (was: Tomaz Cerar) > Redundant CONSOLE log handler adding in CLI scripts for messaging-clustering* QS > -------------------------------------------------------------------------------- > > Key: WFLY-9977 > URL: https://issues.jboss.org/browse/WFLY-9977 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 12.0.0.Final > Reporter: Nikoleta Žiaková > > CLI scripts in messaging-clustering and messaging-clustering-singleton QS contain redundant step for adding CONSOLE log handler. They fails with: > {code} > Failure: WFLYCTL0212: Duplicate resource > {code} > The reason is that CONSOLE log handler is enabled by default. > Readme files mention adding the handler, too: > https://github.com/wildfly/quickstart/tree/master/messaging-clustering > https://github.com/wildfly/quickstart/tree/master/messaging-clustering-si... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4051) Use descriptive error message for duplicate host/context deployments

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4051?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4051: --------------------------------- Assignee: (was: Tomaz Cerar) > Use descriptive error message for duplicate host/context deployments > -------------------------------------------------------------------- > > Key: WFLY-4051 > URL: https://issues.jboss.org/browse/WFLY-4051 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: Paul Ferraro > Priority: Minor > > If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons. > What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018