March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-273: ---------------------------------- Actually, I think I may have been able to figure out how to cause this: (1) Start master & slave HCs (2) kill master HC (3) connect to slave HC and start a non-auto-start server (4) restart master HC (5) server shows up in master as disabled, but is running. > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5242: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1258298|https://bugzilla.redhat.com/show_bug.cgi?id=1258298] from POST to MODIFIED > Inconsistent format for IPv6 addresses in server log > ---------------------------------------------------- > > Key: WFLY-5242 > URL: https://issues.jboss.org/browse/WFLY-5242 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Lyle Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 10.0.0.CR1 > > > Description of problem: > When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs. > How reproducible: > Always > Steps to Reproduce: > 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports) > 2. Start WildFly and check the log > Actual results: > ---------------------------------------- > 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080 > ...... > 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management > 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993 > ---------------------------------------- > In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management" > Expected results: > Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-903) Differently implemented password-stacking option in ClientLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-903?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-903: -------------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1254194|https://bugzilla.redhat.com/show_bug.cgi?id=1254194] from POST to MODIFIED > Differently implemented password-stacking option in ClientLoginModule > --------------------------------------------------------------------- > > Key: SECURITY-903 > URL: https://issues.jboss.org/browse/SECURITY-903 > Project: PicketBox > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: PicketBox_5_0_0.Alpha2 > > > From BZ: > "In case when some login module should use password stacking then value of password-stacking option should be set to useFirstPass. All login modules should respect it. However implemetation of org.jboss.security.ClientLoginModule uses password-stacking differently - it uses password stacking everytime when some value is set for password-stacking option (even value false). It should work same as other login modules. Current behavior can be confusing and can lead to incorrectly set server configuration." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1526) AS7 JConsole scripts ignore arguments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1526: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1238868|https://bugzilla.redhat.com/show_bug.cgi?id=1238868] from POST to MODIFIED > AS7 JConsole scripts ignore arguments > -------------------------------------- > > Key: WFLY-1526 > URL: https://issues.jboss.org/browse/WFLY-1526 > Project: WildFly > Issue Type: Enhancement > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Minor > > JConsole scripts ignore arguments, for instance, sh script: > jconsole -J-Djava.class.path="$CLASSPATH" > instead of > jconsole -J-Djava.class.path="$CLASSPATH" "$@" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-273: ---------------------------------- Here are the oucomes with --restart-servers || || auto-start || reload --restart-servers= || Current Status || Outcome || Existing Config / add with CLI || Comments || || 1 || default (true)|| not specified || running || stopped & started || (existing config) || || 2 || default (true)|| not specified || not running || started || (existing config) || || 3 || default (true)|| false || not running || started || (existing config) || Should this be started with --restart-servers=false? || || 4 || default (true)|| true || running || stopped & started || (existing config) || || 5 || false || not specified || running || stopped & not started || (existing config) || || 6 || false || true || running || stopped & not started || (existing config) || || 7 || false || false || running || not stopped & still running || (existing config) || || 8 || true || false || not running || started || (added new server) || Should this be started with --restart-servers=false? (same as 3) || || 9 || false || false || not running || not started || (added new server) || || 10 || false || false || running || running || (added new server & started manually) || || 11 || false || true || running || stopped & not started || (added new server & started manually) || So I think we'd want to think about 3 and 11 (3) If an auto-start server has been stopped, and restart-servers=false, should it restart the stopped server? (I think no.) (11) for a new auto-start=true server, restart-servers=true doesn't start the server. This might be ok though, as it was explicitly added with auto-start = false. > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4590) l1-lifespan attribute in distributed cache configuration does not enable l1 cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4590?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4590: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1218148|https://bugzilla.redhat.com/show_bug.cgi?id=1218148] from POST to MODIFIED > l1-lifespan attribute in distributed cache configuration does not enable l1 cache > --------------------------------------------------------------------------------- > > Key: WFLY-4590 > URL: https://issues.jboss.org/browse/WFLY-4590 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > > l1-lifespan attribute in distributed cache configuration is not honored. If set to a non-zero value it just sets the underlying cache config parameter, but does not explicitly enable l1 which is by default disabled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-681) Incorrectly timeout values in ControllerLogger method timeoutCompletingOperation and ControllerMessages method serviceInstallTimedOut

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-681?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-681: ------------------------------------------------ Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1219273|https://bugzilla.redhat.com/show_bug.cgi?id=1219273] from POST to MODIFIED > Incorrectly timeout values in ControllerLogger method timeoutCompletingOperation and ControllerMessages method serviceInstallTimedOut > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-681 > URL: https://issues.jboss.org/browse/WFCORE-681 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.CR1 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 1.0.0.CR2 > > > Incorrectly scaled timeout value passed to org.jboss.as.controller.ControllerLogger method timeoutCompletingOperation and org.jboss.as.controller.ControllerMessages method serviceInstallTimedOut > parameter value is ms, second is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4533) Port jboss-as-messaging_1_5.xsd from EAP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4533?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4533: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1212941|https://bugzilla.redhat.com/show_bug.cgi?id=1212941] from POST to MODIFIED > Port jboss-as-messaging_1_5.xsd from EAP > ---------------------------------------- > > Key: WFLY-4533 > URL: https://issues.jboss.org/browse/WFLY-4533 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Darran Lofthouse > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 9.0.0.CR1 > > > Unfortunately an incompatible change has been introduced in jboss-as-messaging_1_4.xsd within EAP, this Jira issue is to minimise the impact. > EAP should have a new jboss-as-messaging_1_5.xsd added and the changes to the 1.4 schema reverted. The parser will be updated to support 1.5 and will remain quietly accepting the new element. > In WildFly we need to forward port this new 1.5 schema and also update the 1.4 parser to quietly accept the new element. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3549) Deadlock during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3549: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1213817|https://bugzilla.redhat.com/show_bug.cgi?id=1213817] from POST to MODIFIED > Deadlock during shutdown > ------------------------ > > Key: WFLY-3549 > URL: https://issues.jboss.org/browse/WFLY-3549 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: David Lloyd > Fix For: 8.2.0.Final > > > This deadlock appeared in an Arquillian test: > {noformat} > Found one Java-level deadlock: > ============================= > "undefined": > waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService), > which is held by "MSC service thread 1-2" > "MSC service thread 1-2": > waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), > which is held by "undefined" > Java stack information for the threads listed above: > =================================================== > "undefined": > at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121) > - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704) > at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > "MSC service thread 1-2": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) > at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695) > at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397) > at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759) > at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53) > at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67) > - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Found 1 deadlock. > {noformat} > Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4404) View does not inherit 'default' methods from interfaces( JDK8 )

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4404: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from POST to MODIFIED > View does not inherit 'default' methods from interfaces( JDK8 ) > --------------------------------------------------------------- > > Key: WFLY-4404 > URL: https://issues.jboss.org/browse/WFLY-4404 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 10.0.0.CR5 > > > View and View service do not inherit JDK8 'default' methods from interfaces. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 March 2016