March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1386) Accept properties file in scripts for starting as a service

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFCORE-1386?page=com.atlassian.jira.plugi... ] Marek Kopecký commented on WFCORE-1386: --------------------------------------- [~esantana]: It seems that your comment is not related with running WF as a service on Windows, WF currently contains ./docs/contrib/scripts/service/service.bat file for this and according to the help text for this file, it seems that this feature is not in WF: {noformat} WildFly Service Script for Windows Usage: service install <options> , where the options are: /startup : Set the service to auto start Not specifying sets the service to manual /jbossuser <username> : JBoss username to use for the shutdown command. /jbosspass <password> : Password for /jbossuser /controller <host:port> : The host:port of the management interface. default: localhost:9990 /host [<domainhost>] : Indicates that domain mode is to be used, with an optional domain/host controller name. default: master Not specifying /host will install JBoss in standalone mode. Options to use when multiple services or different accounts are needed: /name <servicename> : The name of the service default: Wildfly /display <displayname> : The display name of the service, use double quotes to allow spaces. Maximum 256 characters. default: WildFly /desc <description> : The description of the service, use double quotes to allow spaces. Maximum 1024 characters. default: WildFly Application Server /serviceuser <username> : Specifies the name of the account under which the service should run. Use an account name in the form of DomainName\UserName default: not used, the service runs as Local System Account. /servicepass <password> : password for /serviceuser Advanced options: /config <xmlfile> : The server-config to use default: standalone.xml / domain.xml /hostconfig <xmlfile> : domain mode only, the host config to use default: host.xml /base <directory> : The base directory for server/domain content Must be specified as a fully qualified path default: C:\Users\Administrator\playground\wildfly-17.0.0.Beta1-SNAPSHOT\standalone or C:\Users\Administrator\playground\wildfly-17.0.0.Beta1-SNAPSHOT\domain /loglevel <level> : The log level for the service: Error, Info, Warn or Debug (Case insensitive) default: INFO /logpath <path> : Path of the log default depends on domain or standalone mode /base applies when /logpath is not set. C:\Users\Administrator\playground\wildfly-17.0.0.Beta1-SNAPSHOT\domain\log C:\Users\Administrator\playground\wildfly-17.0.0.Beta1-SNAPSHOT\standalone\log /debug : run the service install in debug mode Other commands: service uninstall [/name <servicename>] service start [/name <servicename>] service stop [/name <servicename>] service restart [/name <servicename>] /name <servicename> : Name of the service: should not contain spaces default: Wildfly {noformat} > Accept properties file in scripts for starting as a service > ----------------------------------------------------------- > > Key: WFCORE-1386 > URL: https://issues.jboss.org/browse/WFCORE-1386 > Project: WildFly Core > Issue Type: Feature Request > Components: Scripts > Affects Versions: 2.0.0.Beta1 > Environment: Microsoft Windows > Reporter: Roman Syroeshko > Priority: Major > > Currently $JBOSS_HOME\bin\service\service.bat does not allow passing properties file. We run WildFly in domain mode using the followed command. > {code} > domain.bat --properties=jboss.properties > {code} > Now, it's impossible to install WildFly as a service like that without hacking out-of-the-box files. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-243) Handler errors have a null category

by David Lloyd (Jira)

David Lloyd created LOGMGR-243: ---------------------------------- Summary: Handler errors have a null category Key: LOGMGR-243 URL: https://issues.jboss.org/browse/LOGMGR-243 Project: JBoss Log Manager Issue Type: Bug Components: core Affects Versions: 3.0.0.Final Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-242) Handler-based error managers fail due to wrong format string

by David Lloyd (Jira)

[ https://issues.jboss.org/browse/LOGMGR-242?page=com.atlassian.jira.plugin... ] David Lloyd updated LOGMGR-242: ------------------------------- Affects Version/s: 3.0.0.Final (was: 2.2.0.Final) > Handler-based error managers fail due to wrong format string > ------------------------------------------------------------ > > Key: LOGMGR-242 > URL: https://issues.jboss.org/browse/LOGMGR-242 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Affects Versions: 3.0.0.Final > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Major > Fix For: 3.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-242) Handler-based error managers fail due to wrong format string

by David Lloyd (Jira)

[ https://issues.jboss.org/browse/LOGMGR-242?page=com.atlassian.jira.plugin... ] David Lloyd updated LOGMGR-242: ------------------------------- Fix Version/s: 3.0.0.Final (was: 2.2.0.Final) > Handler-based error managers fail due to wrong format string > ------------------------------------------------------------ > > Key: LOGMGR-242 > URL: https://issues.jboss.org/browse/LOGMGR-242 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Affects Versions: 3.0.0.Final > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Major > Fix For: 3.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3127) standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFCORE-3127?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3127: ---------------------------------- Affects Version/s: 8.0.0.Final > standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly > ----------------------------------------------------------------------------- > > Key: WFCORE-3127 > URL: https://issues.jboss.org/browse/WFCORE-3127 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta30, 8.0.0.Final > Reporter: Radovan Stancel > Assignee: Radovan Stancel > Priority: Major > Labels: downstream_dependency > Original Estimate: 1 day > Time Spent: 3 hours > Remaining Estimate: 5 hours > > ====================== > Scenario-1) > ============ With the following line of JAVA_OPTS in "standalone.bat.conf" file > set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*" > {code} > Error while starting EAP 6.1.1 > C:\jboss-eap-6.1.1\bin>standalone.bat > Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat" > Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > {code} > Scenario-2) > ============ In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file: > set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*" > Now EAP 6.1.1 server starts but still we see the following messages in windows console: > {code} > C:\jboss-eap-6.1.1\bin>standalone.bat > Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat" > Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-242) Handler-based error managers fail due to wrong format string

by David Lloyd (Jira)

David Lloyd created LOGMGR-242: ---------------------------------- Summary: Handler-based error managers fail due to wrong format string Key: LOGMGR-242 URL: https://issues.jboss.org/browse/LOGMGR-242 Project: JBoss Log Manager Issue Type: Bug Components: core Affects Versions: 2.2.0.Final Reporter: David Lloyd Assignee: David Lloyd Fix For: 2.2.0.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-177) Introduce delayed initialization strategy

by David Lloyd (Jira)

[ https://issues.jboss.org/browse/LOGMGR-177?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-177: ------------------------------------ We could call this solved, couldn't we? {{DelayedHandler}} is working great in Quarkus at least. > Introduce delayed initialization strategy > ----------------------------------------- > > Key: LOGMGR-177 > URL: https://issues.jboss.org/browse/LOGMGR-177 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > Priority: Critical > > h2. Synopsis > The logmanager eagerly initializes as soon as logging is first used. In many cases this is undesirable because of circular dependency problems which do not allow the logging configuration to be fully available until other systems are booted for a variety of reasons: > * WildFly logging configuration is done in a subsystem which is not available at first boot > * Logging handlers may depend on other systems (which use logging) to initialize (like Elytron for SSL) > * Java 9+ may make it difficult to initialize logging very early > So we need a multi-stage initialization process. > h2. Requirements > h3. Requirement 1: Performance must not be impacted > One of the primary reasons for the existence of the log manager is performance. Therefore, performance impact must be as minimal as possible during the initialization process and effectively zero post-initialization. > h3. Requirement 2: Process in correct order > Late initialization must allow all log messages to be processed in a correct order. Note that there is more than one possible correct order, however any log message B that was logged observably after log message A must appear in the log after A. > h3. Requirement 3: No lost messages > When initialization is complete, all log messages which occurred before initialization must be logged and none lost. > h3. Requirement 4: No mutations > Messages recorded during initialization cannot be mutated in any way compared to what would have been logged post-initialization; therefore, any log message produced before initialization is complete must have a full copy of its contextual information (caller and MDC/NDC). Note that this requirement is in natural tension with Requirement 1. > h3. Requirement 5: Tracing > Capturing full context on every log record, including those at TRACE level, will certainly impose too severe a performance impact for normal usage. A reasonable optimization would be to choose a "safe" level like "INFO" during the initialization process, thereby requiring full capture of only a small number of log records. However this would in turn make debugging during this early stage quite difficult. So, it must be possible to inform the log manager that boot logging must accept messages of any valid level, including TRACE or ALL. The default should lean towards performance, but it should be easily overridable (say, via a system property). > h3. Requirement 6: Opt-in > In most common cases, like unit testing, it is desirable to simply start logging from the properties configuration. So, delayed initialization should be opt-in as it is generally a container or advanced feature, and the application in question likely has to take action in order to complete logging initialization. > h2. Implementation strategy > A possible implementation strategy would be to create a layer of indirection, centrally managed through the log manager instance, through which all logging is dispatched. This could be done by way of one of the {{org.jboss.logmanager.Logger#logRaw}} or {{org.jboss.logmanager.LoggerNode#publish}} methods. > h3. State machine > The layer of indirection could have multiple stages: > * Uninitialized: > ** All log records are enqueued > ** The root logger level is initialized to the level configured by the initial system property > * Initializing: > ** All log records are enqueued > ** Loggers and handlers are configured by the container or user as they wish > ** At the end of this stage, an "initializationComplete" method on the log manager is called, causing a transition to... > * Starting: > ** All log records are enqueued as long as the queue is not "clear", at which point log records are dispatched normally > ** At the same time, the queue is played back in order and the log messages are dispatched according to their final configuration > ** When the queue is empty, it is atomically tagged as "clear", and the state is changed to... > * Running: > ** All log records are dispatched normally > Note that Requirement 3 can only be met if the configured initial log level is finer than the minimum level in the final configuration. > h3. Safety checks > The initialization message queue should have a configurable (via system property again) limit. A default of, say, 10,000 messages would not be unreasonable and would allow for fairly fine-grained logging. If the cap of enqueued messages is reached, the error handler should report (one time) that the cap was reached and that some messages were lost, and it should suggest that either the level system prop be made coarser, or the limit should be increased, in order to prevent the situation from occurring. > h3. No delayed initialization desired > A system property should be added to determine whether the log manager delays its initialization. Per requirements, it should default to false. If true, then default configuration should not be done at all; it is assumed in this case that the user will perform configuration tasks. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2293: ------------------------------------ Sorry for the delay. Yes, I have {{java.net.preferIPv4Stack=true}} in the default debug configuration. > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > Attachments: IMG_20190123_124154.jpg > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2311) tshark/wireshark support

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2311?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2311: --------------------------- Fix Version/s: 4.0.20 (was: 4.0.19) > tshark/wireshark support > ------------------------ > > Key: JGRP-2311 > URL: https://issues.jboss.org/browse/JGRP-2311 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.20 > > Attachments: tshark-convert.py > > > 1. Dump contents of wireshark/tahsrk/tcpdump-generated (PCAP) files (using {{ParseMessages}} > 2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages > In the second instantiation, ParseMessages would read packets from stdin. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2318) KUBE_PING: test with RBAC

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2318?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2318: --------------------------- Fix Version/s: 4.0.20 (was: 4.0.19) > KUBE_PING: test with RBAC > ------------------------- > > Key: JGRP-2318 > URL: https://issues.jboss.org/browse/JGRP-2318 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.20 > > > Test if KUBE_PING still works with the latest minikube/RBAC combo -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 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 March 2019