[JBoss JIRA] (WFCORE-4048) Unable to configure custom security realm in deployment
by Martin Choma (JIRA)
Martin Choma created WFCORE-4048:
------------------------------------
Summary: Unable to configure custom security realm in deployment
Key: WFCORE-4048
URL: https://issues.jboss.org/browse/WFCORE-4048
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 6.0.0.CR2
Reporter: Martin Choma
Assignee: Darran Lofthouse
Original user report [1]:
Hello everyone, I am migrating from legacy security to Elytron, and I have a problem. Is there anyone who can help me? We have a custom login-module that queries infinispan cache (which maps simple bearer tokens to user names), and then queries the database (to get user roles), and on commit essentially wraps it up in Principal object. Elytron doesn't have login-modules, but security realms. There is no default realm that matches our desired functionality, so we need to define a new custom-realm. The problem is, security realms can be defined with classes in wildfly "modules", not deployments. And since "modules" can't contain EJB's, I can't inject neither infinispan cache nor database entity manager in the code. Please help what is the right way to go here
I was thinking about it and I have come to conclusion that Elytron is not able to do the same as legacy. I assume that user is right that you cant use EE features in modules. And it looks to me Elytorn does not allow dependency on deployment module. Because Elytron checks existance of module in time of starting and deployment can be not loaded yet. In legacy existance verification is apparently postponed to time of usage.
So I assume in legacy you can define custom login module in deployment (with EE annotations) and register such login module in security subsystem. And dependencies are resolved in runtime and not in boottime.
[1] https://wildfly.hipchat.com/embedded/history/room/699248/2018/07/18?p=1&q...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4047) MSC Deadlock in undertow subsystem test
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-4047:
----------------------------------------
Summary: MSC Deadlock in undertow subsystem test
Key: WFCORE-4047
URL: https://issues.jboss.org/browse/WFCORE-4047
Project: WildFly Core
Issue Type: Bug
Components: Management
Reporter: Brian Stansberry
Assignee: Richard Opalka
Priority: Critical
Testsuite hang in https://ci.wildfly.org/viewLog.html?buildId=118052&buildTypeId=WF_PullReq...
{code}
[11:30:50][Step 2/3] 2018-08-20 11:30:49
Full thread dump Java HotSpot(TM) Server VM (25.152-b16 mixed mode):
"Attach Listener" #182 daemon prio=9 os_prio=0 tid=0xa3950000 nid=0x3e28 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"XNIO-1 Accept" #181 prio=5 os_prio=0 tid=0xa1ec2000 nid=0x56d4 runnable [0xa090b000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xe55f89f0> (a sun.nio.ch.Util$3)
- locked <0xe55f89e0> (a java.util.Collections$UnmodifiableSet)
- locked <0xe55f88e8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
"XNIO-1 I/O-2" #180 prio=5 os_prio=0 tid=0xa1ec1800 nid=0x56d3 runnable [0xa11ad000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xe55f7d60> (a sun.nio.ch.Util$3)
- locked <0xe55f7d50> (a java.util.Collections$UnmodifiableSet)
- locked <0xe55f7c58> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
"XNIO-1 I/O-1" #179 prio=5 os_prio=0 tid=0x9f4bc400 nid=0x56d2 runnable [0xa18ad000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xe55f83a8> (a sun.nio.ch.Util$3)
- locked <0xe55f8398> (a java.util.Collections$UnmodifiableSet)
- locked <0xe55f82a0> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
"MSC service thread 11-8" #178 prio=5 os_prio=0 tid=0x09d34c00 nid=0x56d0 waiting for monitor entry [0xa08ba000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.msc.service.ServiceControllerImpl.dependencyAvailable(ServiceControllerImpl.java:850)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl$DependencyAvailableTask.inform(ServiceControllerImpl.java:1665)
at org.jboss.msc.service.ServiceControllerImpl$DependentsControllerTask.execute(ServiceControllerImpl.java:1612)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
"Controller Boot Thread" #177 prio=5 os_prio=0 tid=0x9fc9c400 nid=0x56cf waiting for monitor entry [0xa0efe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.msc.service.ServiceControllerImpl.getImmediateUnavailableDependencies(ServiceControllerImpl.java:1287)
- waiting to lock <0xe5718bf0> (a org.jboss.msc.service.ServiceRegistrationImpl)
- locked <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl.getUnavailableDependencies(ServiceControllerImpl.java:1279)
at org.jboss.as.controller.ServiceVerificationHelper.execute(ServiceVerificationHelper.java:93)
- locked <0xe575c008> (a org.jboss.as.controller.ServiceVerificationHelper)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:276)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:419)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-7" #176 prio=5 os_prio=0 tid=0xa3954800 nid=0x56ce waiting on condition [0x9fa5c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xe570b240> (a org.jboss.threads.EnhancedQueueExecutor)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1410)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-6" #175 prio=5 os_prio=0 tid=0xa0a57c00 nid=0x56cd waiting for monitor entry [0xa095c000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.msc.service.ServiceControllerImpl.dependencyAvailable(ServiceControllerImpl.java:850)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl$DependencyAvailableTask.inform(ServiceControllerImpl.java:1665)
at org.jboss.msc.service.ServiceControllerImpl$DependentsControllerTask.execute(ServiceControllerImpl.java:1612)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-5" #174 prio=5 os_prio=0 tid=0xa12a8000 nid=0x56cc waiting on condition [0xa0686000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xe570b240> (a org.jboss.threads.EnhancedQueueExecutor)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1410)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-4" #173 prio=5 os_prio=0 tid=0xa0a59400 nid=0x56cb waiting on condition [0x9fe5c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xe570b240> (a org.jboss.threads.EnhancedQueueExecutor)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1410)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-3" #172 prio=5 os_prio=0 tid=0xa0a56800 nid=0x56ca waiting on condition [0x9fead000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xe570b240> (a org.jboss.threads.EnhancedQueueExecutor)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1410)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-2" #171 prio=5 os_prio=0 tid=0xa129ac00 nid=0x56c9 waiting for monitor entry [0xa0bac000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.msc.service.ServiceControllerImpl.dependencyAvailable(ServiceControllerImpl.java:850)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl$DependencyAvailableTask.inform(ServiceControllerImpl.java:1665)
at org.jboss.msc.service.ServiceControllerImpl$DependentsControllerTask.execute(ServiceControllerImpl.java:1612)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
"MSC service thread 11-1" #170 prio=5 os_prio=0 tid=0x9fc9d000 nid=0x56c8 waiting on condition [0x9fbfe000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xe570b240> (a org.jboss.threads.EnhancedQueueExecutor)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1410)
at java.lang.Thread.run(Thread.java:748)
"Reference Reaper" #14 daemon prio=5 os_prio=0 tid=0xa16e1000 nid=0x5628 in Object.wait() [0xa18fe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xa749ccf8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0xa749ccf8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at org.jboss.modules.ref.References$ReaperThread.run(References.java:64)
"process reaper" #11 daemon prio=10 os_prio=0 tid=0x09c3a800 nid=0x5626 waiting on condition [0xa288c000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xa73305f8> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"surefire-forkedjvm-ping-30s" #10 daemon prio=5 os_prio=0 tid=0xa3164c00 nid=0x5624 waiting on condition [0xa3271000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xa71c1c00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"surefire-forkedjvm-command-thread" #9 daemon prio=5 os_prio=0 tid=0xa3154c00 nid=0x5623 runnable [0xa32c2000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xa71f9040> (a java.io.BufferedInputStream)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:115)
at org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:391)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" #8 daemon prio=9 os_prio=0 tid=0xa3aab400 nid=0x5621 runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xa3aa7c00 nid=0x5620 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xa3aa6800 nid=0x561f waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xa3aa4800 nid=0x561e waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xa3aa3000 nid=0x561d runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0xa3a88c00 nid=0x561c in Object.wait() [0xa3b57000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0xa71f7ee8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xa3a86000 nid=0x561b in Object.wait() [0xa677d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0xa71ec3e8> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"main" #1 prio=5 os_prio=0 tid=0xf6507400 nid=0x5615 waiting for monitor entry [0xf666f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.msc.service.ServiceControllerImpl.getState(ServiceControllerImpl.java:1101)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:806)
at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:784)
- locked <0xe5718bf0> (a org.jboss.msc.service.ServiceRegistrationImpl)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:761)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
at org.jboss.msc.service.ObsoleteServiceBuilderImpl.install(ObsoleteServiceBuilderImpl.java:293)
at org.wildfly.extension.undertow.AbstractUndertowSubsystemTestCase$RuntimeInitialization.addExtraServices(AbstractUndertowSubsystemTestCase.java:240)
at org.jboss.as.subsystem.test.AbstractKernelServicesImpl.create(AbstractKernelServicesImpl.java:127)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:568)
at org.wildfly.extension.undertow.UndertowSubsystem11TestCase.testRuntime(UndertowSubsystem11TestCase.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
"VM Thread" os_prio=0 tid=0xa3a81800 nid=0x561a runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6510c00 nid=0x5616 runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6512000 nid=0x5617 runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6513800 nid=0x5618 runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6514c00 nid=0x5619 runnable
"VM Periodic Task Thread" os_prio=0 tid=0xa3ab7400 nid=0x5622 waiting on condition
JNI global references: 706
Found one Java-level deadlock:
=============================
"MSC service thread 11-8":
waiting to lock monitor 0xa221b37c (object 0xe561fa38, a org.jboss.msc.service.ServiceControllerImpl),
which is held by "Controller Boot Thread"
"Controller Boot Thread":
waiting to lock monitor 0xa20b3f64 (object 0xe5718bf0, a org.jboss.msc.service.ServiceRegistrationImpl),
which is held by "main"
"main":
waiting to lock monitor 0xa221b37c (object 0xe561fa38, a org.jboss.msc.service.ServiceControllerImpl),
which is held by "Controller Boot Thread"
Java stack information for the threads listed above:
===================================================
"MSC service thread 11-8":
at org.jboss.msc.service.ServiceControllerImpl.dependencyAvailable(ServiceControllerImpl.java:850)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl$DependencyAvailableTask.inform(ServiceControllerImpl.java:1665)
at org.jboss.msc.service.ServiceControllerImpl$DependentsControllerTask.execute(ServiceControllerImpl.java:1612)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
"Controller Boot Thread":
at org.jboss.msc.service.ServiceControllerImpl.getImmediateUnavailableDependencies(ServiceControllerImpl.java:1287)
- waiting to lock <0xe5718bf0> (a org.jboss.msc.service.ServiceRegistrationImpl)
- locked <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceControllerImpl.getUnavailableDependencies(ServiceControllerImpl.java:1279)
at org.jboss.as.controller.ServiceVerificationHelper.execute(ServiceVerificationHelper.java:93)
- locked <0xe575c008> (a org.jboss.as.controller.ServiceVerificationHelper)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:276)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:419)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
at java.lang.Thread.run(Thread.java:748)
"main":
at org.jboss.msc.service.ServiceControllerImpl.getState(ServiceControllerImpl.java:1101)
- waiting to lock <0xe561fa38> (a org.jboss.msc.service.ServiceControllerImpl)
at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:806)
at org.jboss.msc.service.ServiceContainerImpl.detectCircularity(ServiceContainerImpl.java:784)
- locked <0xe5718bf0> (a org.jboss.msc.service.ServiceRegistrationImpl)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:761)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:260)
at org.jboss.msc.service.ObsoleteServiceBuilderImpl.install(ObsoleteServiceBuilderImpl.java:293)
at org.wildfly.extension.undertow.AbstractUndertowSubsystemTestCase$RuntimeInitialization.addExtraServices(AbstractUndertowSubsystemTestCase.java:240)
at org.jboss.as.subsystem.test.AbstractKernelServicesImpl.create(AbstractKernelServicesImpl.java:127)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:568)
at org.wildfly.extension.undertow.UndertowSubsystem11TestCase.testRuntime(UndertowSubsystem11TestCase.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Found 1 deadlock.
{code}
What's going on here is the main thread in subsystem test fixture AbstractKernelServicesImpl at L115 installs a Service<ModelController>. Like a normal, non-test-fixture boot that spawns the ControllerBootThread to do parsing and run the boot management ops. Then main continues on to L127 where it starts adding any additional services the test wants. AbstractUndertowSubsystemTestCase.RuntimeInitialization installs a bunch.
So, we have two threads, ControllerBootThread and main, installing services. And then of course MSC threads can also install services.
What the subsystem test fixtures does where main is adding services at the same time the boot thread is running is unorthodox in terms of how a real server would operate. But, it's been this way for years and I've never seen a deadlock like this before.
[~ropalka] I'm assigning this to you because this seems more like an MSC problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-95) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-95?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on WFWIP-95:
--------------------------------------
[~bmaxwell] with the PR I'm adding you would be able to add a file org.apache.activemq.Artemis.properties to the jar, exclusively for the wildfly distribution.
That way users won't need to specify anything. They can still alter the default specified by the file.
https://github.com/apache/activemq-artemis/pull/2254
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFWIP-95
> URL: https://issues.jboss.org/browse/WFWIP-95
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-95) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFWIP-95?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell commented on WFWIP-95:
-----------------------------------
A system property is probably acceptable, and have it documented in the migration docs, to say if you are using this class, you need to set this system property.
Then deprecate the class and also list in the migration docs, here is how you can change your code to not use this deprecated class that will be unsupported in the future.
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFWIP-95
> URL: https://issues.jboss.org/browse/WFWIP-95
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10889) AbstractUndertowSubsystemTestCase should not use ServiceController.awaitValue with no timeout
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10889?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10889:
---------------------------------------
Assignee: Brian Stansberry (was: Stuart Douglas)
> AbstractUndertowSubsystemTestCase should not use ServiceController.awaitValue with no timeout
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10889
> URL: https://issues.jboss.org/browse/WFLY-10889
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Avoid hangs like https://ci.wildfly.org/viewLog.html?buildId=118094&buildTypeId=WF_PullReq... with the important thread being:
> {code}"main" #1 prio=5 os_prio=0 tid=0x000000000127d800 nid=0x2fd4 in Object.wait() [0x000000000149d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000006c13073a8> (a org.jboss.msc.service.ServiceControllerImpl)
> at java.lang.Object.wait(Object.java:502)
> at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1130)
> - locked <0x00000006c13073a8> (a org.jboss.msc.service.ServiceControllerImpl)
> at org.wildfly.extension.undertow.AbstractUndertowSubsystemTestCase.testRuntime(AbstractUndertowSubsystemTestCase.java:122)
> at org.wildfly.extension.undertow.UndertowSubsystem12TestCase.testRuntime(UndertowSubsystem12TestCase.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> {code}
> Put some kind of timeout in there so the job doesn't run for hours before timing out.
> Same for clustering testsuite's ValueServiceServlet.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10889) AbstractUndertowSubsystemTestCase should not use ServiceController.awaitValue with no timeout
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10889:
---------------------------------------
Summary: AbstractUndertowSubsystemTestCase should not use ServiceController.awaitValue with no timeout
Key: WFLY-10889
URL: https://issues.jboss.org/browse/WFLY-10889
Project: WildFly
Issue Type: Bug
Components: Test Suite, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Stuart Douglas
Avoid hangs like https://ci.wildfly.org/viewLog.html?buildId=118094&buildTypeId=WF_PullReq... with the important thread being:
{code}"main" #1 prio=5 os_prio=0 tid=0x000000000127d800 nid=0x2fd4 in Object.wait() [0x000000000149d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000006c13073a8> (a org.jboss.msc.service.ServiceControllerImpl)
at java.lang.Object.wait(Object.java:502)
at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1130)
- locked <0x00000006c13073a8> (a org.jboss.msc.service.ServiceControllerImpl)
at org.wildfly.extension.undertow.AbstractUndertowSubsystemTestCase.testRuntime(AbstractUndertowSubsystemTestCase.java:122)
at org.wildfly.extension.undertow.UndertowSubsystem12TestCase.testRuntime(UndertowSubsystem12TestCase.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
{code}
Put some kind of timeout in there so the job doesn't run for hours before timing out.
Same for clustering testsuite's ValueServiceServlet.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4045) Make ExtensibleHttpManagement.addManagementHandler() return error code 500
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4045?page=com.atlassian.jira.plugi... ]
Kabir Khan edited comment on WFCORE-4045 at 8/20/18 4:21 PM:
-------------------------------------------------------------
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: text/plain; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 20:20:49 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
[~]
{code}
With -L:
{code}
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: text/plain; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 20:20:52 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
was (Author: kabirkhan):
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:39:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
with -L:
{code}
[~]
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:51:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
> Make ExtensibleHttpManagement.addManagementHandler() return error code 500
> --------------------------------------------------------------------------
>
> Key: WFCORE-4045
> URL: https://issues.jboss.org/browse/WFCORE-4045
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> The security checks done by the handlers added via ExtensibleHttpManagement.addManagementHandler() currently redirect to the standard html page with an error code of 200. This behaviour is impossible to change.
> This is currently only used by MP Health, for which the ExtensibleHttpManagement API was added. Rather than expand this API we will change the behaviour of handlers added with this mechanism to return 500. The standard error page will be updated in WFCORE-4046 to be more generic.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4045) Make ExtensibleHttpManagement.addManagementHandler() return error code 500
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4045?page=com.atlassian.jira.plugi... ]
Kabir Khan edited comment on WFCORE-4045 at 8/20/18 3:58 PM:
-------------------------------------------------------------
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:39:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
with -L:
{code}
[~]
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:51:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
was (Author: kabirkhan):
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:39:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
{code}
[~]
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:51:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
> Make ExtensibleHttpManagement.addManagementHandler() return error code 500
> --------------------------------------------------------------------------
>
> Key: WFCORE-4045
> URL: https://issues.jboss.org/browse/WFCORE-4045
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> The security checks done by the handlers added via ExtensibleHttpManagement.addManagementHandler() currently redirect to the standard html page with an error code of 200. This behaviour is impossible to change.
> This is currently only used by MP Health, for which the ExtensibleHttpManagement API was added. Rather than expand this API we will change the behaviour of handlers added with this mechanism to return 500. The standard error page will be updated in WFCORE-4046 to be more generic.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4045) Make ExtensibleHttpManagement.addManagementHandler() return error code 500
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4045?page=com.atlassian.jira.plugi... ]
Kabir Khan edited comment on WFCORE-4045 at 8/20/18 3:57 PM:
-------------------------------------------------------------
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:39:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
{code}
[~]
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:51:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
was (Author: kabirkhan):
See WFLY-10861 for the background information resulting in this.
The output with https://github.com/wildfly/wildfly-core/pull/3465 is now:
{code}
$curl -v http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:39:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRealm' and this is already selected by default by the add-user tool."
{code}
{code}
[~]
$curl -v -L http://127.0.0.1:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /health HTTP/1.1
> Host: 127.0.0.1:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Connection: keep-alive
< Content-Type: application/json; charset=utf-8
< Content-Length: 408
< Date: Mon, 20 Aug 2018 19:51:30 GMT
<
* Connection #0 to host 127.0.0.1 left intact
"WFLYDMHTTP0016: Your Application Server is running. However you have not yet added any users to be able to access the HTTP management interface. To add a new user execute the add-user.sh script within the bin folder of your WildFly installation and enter the requested information. By default the realm name used by WildFly is 'ManagementRea
{code}
As discussed with [~rsvoboda] the API exposed to register http handlers from the subsystems is new and we want to keep it as simple as possible at the moment. The new ManagementHttpServer.addManagementHandler() was reusing the logic from the console to redirect to the standard error mechanism used for the console. This mechanism ends up loading the page https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (linux) or https://github.com/wildfly/wildfly-core/blob/master/domain-http/error-con... (windows).
For this use-case, which will also be used by other subsystems which want to register a custom HttpHandler, the mechanism is to simply send a 500 status code with the text shown above. If something more advanced is needed in the future we can expand the API, but it is too early to do so without knowing the use-cases.
> Make ExtensibleHttpManagement.addManagementHandler() return error code 500
> --------------------------------------------------------------------------
>
> Key: WFCORE-4045
> URL: https://issues.jboss.org/browse/WFCORE-4045
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> The security checks done by the handlers added via ExtensibleHttpManagement.addManagementHandler() currently redirect to the standard html page with an error code of 200. This behaviour is impossible to change.
> This is currently only used by MP Health, for which the ExtensibleHttpManagement API was added. Rather than expand this API we will change the behaviour of handlers added with this mechanism to return 500. The standard error page will be updated in WFCORE-4046 to be more generic.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months