[JBoss JIRA] (WFLY-11710) Datasource metrics are not always exposed by the metrics subsystem
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11710?page=com.atlassian.jira.plugin... ]
Brian Stansberry reopened WFLY-11710:
-------------------------------------
Reopening as the stability monitor approach has proven to be an issue -- WFLY-11760. And if that's corrected (i.e. https://github.com/wildfly/wildfly/pull/12103) then boot hangs.
> Datasource metrics are not always exposed by the metrics subsystem
> ------------------------------------------------------------------
>
> Key: WFLY-11710
> URL: https://issues.jboss.org/browse/WFLY-11710
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 16.0.0.Beta1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 16.0.0.CR1
>
>
> The metrics subsystem install a service at RUNTIME to register any metrics on the resources registered in WildFly management tree.
> However, the metrics for datasources are provided by the statistics=jdbc and statistics=pool children of the datasource resource which are installed at RUNTIME.
> Since there is no dependency between the metrics service and the service that installs the datasource statistics, it is possible that the metrics services is started before and while traverse the WildFly management tree before the statistics resources are added to it.
> This issue is intermittent and depend on the sequence of execution of unrelated services.
> To circumvent this issue, the metrics subsystem could install its service at VERIFY stage (instead of RUNTIME) and will then have the guarantee that any resources created at RUNTIME is present in WildFly management tree.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11760) Race condition when starting the DeploymentMetricService
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11760?page=com.atlassian.jira.plugin... ]
James Perkins reassigned WFLY-11760:
------------------------------------
Assignee: Richard Opalka (was: Jeff Mesnil)
> Race condition when starting the DeploymentMetricService
> --------------------------------------------------------
>
> Key: WFLY-11760
> URL: https://issues.jboss.org/browse/WFLY-11760
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: James Perkins
> Assignee: Richard Opalka
> Priority: Major
>
> It looks like there is a race condition that produces an NPE in the {{DeploymentMetricService}}. The {{MetricsRegistrationService}} asynchronously starts {{MetricCollector}} and for some reason the {{Supplier}} returns {{null}} even though there is a service dependency.
> {code}
> 11:42:18,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."simple-servlet.war".metrics: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-servlet.war".metrics: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.microprofile.metrics.MetricsRegistrationService.registerMetrics(MetricsRegistrationService.java:162)
> at org.wildfly.extension.microprofile.metrics.deployment.DeploymentMetricService.start(DeploymentMetricService.java:55)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-2657) [DMN Designer] Select Box for Decision Table input columns
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-2657?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2657:
-------------------------------------
[~manstis] I'm not quite following the scenario, but it sounds like there's a UI bit to this? Please let me know if I should be working on something for this, thanks!
> [DMN Designer] Select Box for Decision Table input columns
> ----------------------------------------------------------
>
> Key: DROOLS-2657
> URL: https://issues.jboss.org/browse/DROOLS-2657
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
> h3. Acceptance test
> # Sorting in select box
> # Rename InputData, change reflected in select box
> # Same InputData connected to multiple nodes, appropriate select boxes contain the value
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11760) Race condition when starting the DeploymentMetricService
by James Perkins (Jira)
James Perkins created WFLY-11760:
------------------------------------
Summary: Race condition when starting the DeploymentMetricService
Key: WFLY-11760
URL: https://issues.jboss.org/browse/WFLY-11760
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Reporter: James Perkins
Assignee: Jeff Mesnil
It looks like there is a race condition that produces an NPE in the {{DeploymentMetricService}}. The {{MetricsRegistrationService}} asynchronously starts {{MetricCollector}} and for some reason the {{Supplier}} returns {{null}} even though there is a service dependency.
{code}
11:42:18,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."simple-servlet.war".metrics: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-servlet.war".metrics: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.wildfly.extension.microprofile.metrics.MetricsRegistrationService.registerMetrics(MetricsRegistrationService.java:162)
at org.wildfly.extension.microprofile.metrics.deployment.DeploymentMetricService.start(DeploymentMetricService.java:55)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
... 6 more
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4309) Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4309?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4309:
------------------------------------------
Note that custom validation enhancements like this increase our memory footprint and increase (by a tiny tiny amount) our boot time.
> Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-4309
> URL: https://issues.jboss.org/browse/WFCORE-4309
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 7.0.0.Final
> Reporter: Jan Stourac
> Assignee: Diana Vilkolakova
> Priority: Minor
>
> There is not validation for 'host-context-map' property values on key side. There is validation for the values that represents 'server-ssl-contexts', although, there is no validation for host matching part. E.g. writing attribute of this value is possible:
> {code}
> /subsystem=elytron/server-ssl-sni-context=serverSslSniCtx:write-attribute(name=host-context-map,value={"\\?.example.com"=validSslContext,"..example.com"="validSslContext", "\\*\\*.example.com"=validSslContext})
> {code}
> {code}
> "\\?.example.com"
> "..example.com"
> "\\*\\*.example.com"
> {code}
> even though, these are invalid host name matchers IMHO. It would be nice to identify these and report those to user immediately during the configuration attempt.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4348) Shell scripts tests are intermittently failing on Windows CI runs
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4348?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4348:
----------------------------------
Description:
The script tests seem to be intermittently [failing on Windows|https://ci.wildfly.org/viewLog.html?buildId=140714&buildTypeId=Wi...].
The {{AddUserTestCase}} and {{CliScriptTestCase}} seem to only be failing with PowerShell and are timing out. The {{StandaloneScriptTestCase}} and {{DomainScriptTestCase}} seem to have an issue where the management address and port are already in use.
On all tests we should increase the timeout as it may be too low which is leading to the other issues. Though we need to test this to confirm it.
For the standalone and domain tests it may be wise to introduce a pre-check looking for a running server and shutdown that server if it's running.
was:
The script tests seem to be intermediately [failing on Windows|https://ci.wildfly.org/viewLog.html?buildId=140714&buildTypeId=Wi...].
The {{AddUserTestCase}} and {{CliScriptTestCase}} seem to only be failing with PowerShell and are timing out. The {{StandaloneScriptTestCase}} and {{DomainScriptTestCase}} seem to have an issue where the management address and port are already in use.
On all tests we should increase the timeout as it may be too low which is leading to the other issues. Though we need to test this to confirm it.
For the standalone and domain tests it may be wise to introduce a pre-check looking for a running server and shutdown that server if it's running.
> Shell scripts tests are intermittently failing on Windows CI runs
> -----------------------------------------------------------------
>
> Key: WFCORE-4348
> URL: https://issues.jboss.org/browse/WFCORE-4348
> Project: WildFly Core
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The script tests seem to be intermittently [failing on Windows|https://ci.wildfly.org/viewLog.html?buildId=140714&buildTypeId=Wi...].
> The {{AddUserTestCase}} and {{CliScriptTestCase}} seem to only be failing with PowerShell and are timing out. The {{StandaloneScriptTestCase}} and {{DomainScriptTestCase}} seem to have an issue where the management address and port are already in use.
> On all tests we should increase the timeout as it may be too low which is leading to the other issues. Though we need to test this to confirm it.
> For the standalone and domain tests it may be wise to introduce a pre-check looking for a running server and shutdown that server if it's running.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months