[JBoss JIRA] (WFLY-11256) Fix Undertow Metrics
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11256?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11256:
---------------------------------
Fix Version/s: 15.0.0.Final
> Fix Undertow Metrics
> --------------------
>
> Key: WFLY-11256
> URL: https://issues.jboss.org/browse/WFLY-11256
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Undertow metrics are relevant only when /subsystem=undertow's statistics-enabled is true.
> When that it not the case (and metrics can not be computer) the metrics' read handler should not return a meaningless value (e.g. 0) as it already specifies an undefined metric value in the metrics' attribute definition.
> That change and WFCORE-4190 will prevent exposing Undertow metrics when they do not report actual metric from Undertow underlying runtime.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11165) Eliminate unessential module dependencies on the org.jboss.as.transactions module
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11165?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11165:
---------------------------------
Fix Version/s: 15.0.0.Final
> Eliminate unessential module dependencies on the org.jboss.as.transactions module
> ---------------------------------------------------------------------------------
>
> Key: WFLY-11165
> URL: https://issues.jboss.org/browse/WFLY-11165
> Project: WildFly
> Issue Type: Enhancement
> Components: Class Loading, Management, Transactions
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> As part of our work on getting maximum benefit from Galleon, we want to eliminate unnecessary hard dependencies between Galleon packages, most of which are just provisioning wrappers around the FS content for our JBoss Modules modules. So that means cutting dependency links between modules.
> The org.jboss.as.transactions module necessarily has a large dependency tree, so if other modules depend on it, they then also have a large dependency tree, perhaps much larger than whatever they really need. So I want to eliminate such dependencies whereever possible.
> There are quite a few modules that depend on org.jboss.as.transactions solely for ServiceName constants for services that provide value types not from org.jboss.as.transactions, e.g. TransactionManager which is from the javax.transaction.api module. So the main (perhaps only) task here will be to eliminate those links.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11282) ignore-dependency in jboss-web.xml does not work
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11282?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11282:
---------------------------------
Fix Version/s: 15.0.0.Final
> ignore-dependency in jboss-web.xml does not work
> ------------------------------------------------
>
> Key: WFLY-11282
> URL: https://issues.jboss.org/browse/WFLY-11282
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 15.0.0.Beta1
> Environment: JBoss EAP 7.1.0
> Java 8u192
> CentOS 7.5 x64
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
> Labels: deploy, deployment, resource-ref
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> 1. Use of *ignore-dependency* in the *resource-ref* in *jboss-web.xml* doesn't work, the resource reference remains mandatory.
> Have the following in *web.xml*
> {code:xml}<resource-ref>
> <res-ref-name>wm/WM1</res-ref-name>
> <res-type>commonj.work.WorkManager</res-type>
> <res-auth>Container</res-auth>
> <res-sharing-scope>Shareable</res-sharing-scope>
> </resource-ref>
> <resource-ref>
> <res-ref-name>tm/TM1</res-ref-name>
> <res-type>commonj.timers.TimerManager</res-type>
> <res-auth>Container</res-auth>
> <res-sharing-scope>Unshareable</res-sharing-scope>
> </resource-ref>{code}
> In order to let the ear/war deploy at JBoss EAP (where the CommonJ API isn't available), add a *jboss-web.xml* setting these resource references to be ignored by adding *<ignore-dependency/>*
> {code:xml}<?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_7_2.xsd"
> version="7.2">
> <context-root>mod</context-root>
> <resource-ref>
> <res-ref-name>wm/WM1</res-ref-name>
> <jndi-name>DummyWorkManager</jndi-name>
> <ignore-dependency/>
> </resource-ref>
> <resource-ref>
> <res-ref-name>tm/TM1</res-ref-name>
> <jndi-name>DummyTimerManager</jndi-name>
> <ignore-dependency/>
> </resource-ref>
> </jboss-web>{code}
> However the deploy will fail (as if the jboss-web.xml wouldn't be there at all):
> {noformat}ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."APP.ear"."mod.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."APP.ear"."mod.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "mod.war" of deployment "APP.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0027: Could not load commonj.work.WorkManager referenced in env-entry
> at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.getResourceRefEntries(ResourceReferenceProcessor.java:153)
> at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.processDescriptorEntries(ResourceReferenceProcessor.java:74)
> at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: commonj.work.WorkManager from [Module "deployment.APP.ear.mod.war" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.getResourceRefEntries(ResourceReferenceProcessor.java:151)
> ... 8 more{noformat}
> \\
> 2. Overriding *resource-ref* from *web.xml* in *jboss-web*.xml doesn't work properly.
> I can partially work around the above ClassNotFoundException by adding a dummy res-type like
> {code:xml}<res-type>javax.resource.Referenceable</res-type>{code}
> to both resource references in jboss-web.xml, however this seems to override only the 1st entry as the ClassNotFoundException will change to
> {noformat}java.lang.ClassNotFoundException: commonj.timers.TimerManager{noformat}
> and I don't seem to be able to get rid of this one in any way, save for removing the 2nd resource reference (timer manager) from web.xml and jboss.xml completely.
> Then the deploy will fail with
> {noformat}ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "APP.ear")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.module.app-name.mod-name.env.DummyWorkManager"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.app-name.mod-name.env.wm.WM1 is missing [jboss.naming.context.java.module.app-name.mod-name.env.DummyWorkManager]"]
> }{noformat}
> which only confirms that the ignore-dependency doesn't work.
> Notes:
> - The fact that the CommonJ API can't be used at JBoss EAP isn't a problem. The ear is built to be usable for multiple app servers. The CommonJ WorkManager and TimerManager resources are used only at those app servers where available. We just need the ear to successfully deploy at JBoss EAP. We can take care of the rest.
> - It's likely that providing a modified web.xml via deployment overlay would make things work (not tested but I'm pretty confident about that), but we want to avoid that, we'd like to have the ear deploy straight away (and it should be possible with the use of ignore-dependency)
> - ignore-dependency did work at JBoss AS 6.0, see https://developer.jboss.org/thread/160804
> - Slightly more extensive description of both issues is available here: https://stackoverflow.com/questions/52967897/jboss-eap-7-1-how-to-ignore-...
> - Since there are actually 2 issues being reported here (but they seem to be connected), this JIRA issue can be split into 2 if required
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10731?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10731:
---------------------------------
Fix Version/s: 15.0.0.Final
> core-threads of ManagedScheduledExecutorService limits number of maximal threads
> --------------------------------------------------------------------------------
>
> Key: WFLY-10731
> URL: https://issues.jboss.org/browse/WFLY-10731
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Reporter: gunter zeilinger
> Assignee: Jiri Ondrusek
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> After changing the default configuration:
> {noformat}
> <managed-scheduled-executor-services>
> - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
> + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/>
> </managed-scheduled-executor-services>
> {noformat}
> only 2 (= value of core-threads) threads are used by the Scheduled Executer Service:
> {code:bash}
> $ grep ManagedScheduledExecutorService $WILDFLY/standalone/log/server.log | tail
> 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) ..
> 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) ..
> {code}
> I have not yet tested if the issue also effects Wildfly 13.0.0.Final ( cannot use Wildfly 13.0.0.Final because of WFLY-10531 )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11099) ActiveMQ 2.6.3.jbossorg-001 requires QPid Proton-J 0.27.3 (ClassNotFoundExceptions in messaging subsystem)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11099?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11099:
---------------------------------
Fix Version/s: 15.0.0.Final
> ActiveMQ 2.6.3.jbossorg-001 requires QPid Proton-J 0.27.3 (ClassNotFoundExceptions in messaging subsystem)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11099
> URL: https://issues.jboss.org/browse/WFLY-11099
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Reporter: Jan-Willem Gmelig Meyling
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> With the update from Artemis 1.5.x to 2.6.x in WFLY-9407, Proton-J wasn't updated from 0.16.x to 0.27.3, which leads to class not found exceptions for "Sasl... " classes when remote acceptors are created and connected to (I tested with AMQP protocol). When updating Proton-J to the newest version (0.29.0) my issues are gone.
> I'm not sure which other modules are using the proton-j module, but my suggestion is that we bump the version of Proton-j to the required 0.27.3 minimally.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11036) Shutdown hangs if WAR is distributable and uses SSE
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11036?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11036:
---------------------------------
Fix Version/s: 15.0.0.Final
> Shutdown hangs if WAR is distributable and uses SSE
> ---------------------------------------------------
>
> Key: WFLY-11036
> URL: https://issues.jboss.org/browse/WFLY-11036
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
> Attachments: wfly-11036-0.0.1-SNAPSHOT.war, wfly-11036-src.zip
>
>
> I have an application (WAR) that uses server-sent events (as standardized in JAX-RS 2.1). The application is also marked as <distributable/> in web.xml. If anything actually opens a SSE channel, WildFly hangs during shutdown.
> The culprit appears to be DistributableSessionManager. See the below thread dump, taken during a hung shutdown. DSM is coded to wait up to getDefaultMaxInactiveInterval() seconds in its stop() method, and the default is 30 minutes unless configured otherwise. That's why shutdown hangs, although I don't know what it's waiting for.
> If I remove <distributable/> from web.xml, shutdown happens normally.
> {code}
> "ServerService Thread Pool -- 45" #154 prio=5 os_prio=0 tid=0x000000002bc1a800 nid=0x115e8 waiting on condition [0x0000000035c5e000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb4bcc98> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.tryWriteLock(StampedLock.java:394)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:98)
> - locked <0x00000000fb446c70> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:617)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:607)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$920/1245185678.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:621)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:135)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:117)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Locked ownable synchronizers:
> - None
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months