[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
[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
[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
[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
[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
[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