[JBoss JIRA] (WFWIP-146) WARN messages when /metrics endpoint is accessed
by Rostislav Svoboda (Jira)
Rostislav Svoboda created WFWIP-146:
---------------------------------------
Summary: WARN messages when /metrics endpoint is accessed
Key: WFWIP-146
URL: https://issues.jboss.org/browse/WFWIP-146
Project: WildFly WIP
Issue Type: Bug
Components: MP Metrics
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
WARN messages when /metrics endpoint is accessed.
With standalone.xml I see 12 warnings.
{code}
14:52:14,117 WARN [io.smallrye.metrics] (management I/O-1) Unable to export metric subsystem_undertow_server_default_server_http_listener_default_processing_time: java.lang.IllegalStateException: WFLYMETRICS0006: Metric attribute processing-time on [
("subsystem" => "undertow"),
("server" => "default-server"),
("http-listener" => "default")
] is undefined and will not be exposed.
at org.wildfly.extension.microprofile.metrics-smallrye@15.0.0.Alpha1-SNAPSHOT//org.wildfly.extension.microprofile.metrics.MetricsRegistrationService$1.getValue(MetricsRegistrationService.java:197)
at org.wildfly.extension.microprofile.metrics-smallrye@15.0.0.Alpha1-SNAPSHOT//org.wildfly.extension.microprofile.metrics.MetricsRegistrationService$1.getValue(MetricsRegistrationService.java:174)
at io.smallrye.metrics//io.smallrye.metrics.exporters.PrometheusExporter.createSimpleValueLine(PrometheusExporter.java:340)
at io.smallrye.metrics//io.smallrye.metrics.exporters.PrometheusExporter.exposeEntries(PrometheusExporter.java:140)
at io.smallrye.metrics//io.smallrye.metrics.exporters.PrometheusExporter.getEntriesForScope(PrometheusExporter.java:116)
at io.smallrye.metrics//io.smallrye.metrics.exporters.PrometheusExporter.exportAllScopes(PrometheusExporter.java:85)
at io.smallrye.metrics//io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:83)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-2747) [DMN Designer] Support table header cell selection
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-2747?page=com.atlassian.jira.plugi... ]
Michael Anstis resolved DROOLS-2747.
------------------------------------
Fix Version/s: 7.14.0.Final
Resolution: Done
> [DMN Designer] Support table header cell selection
> --------------------------------------------------
>
> Key: DROOLS-2747
> URL: https://issues.jboss.org/browse/DROOLS-2747
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.14.0.Final
>
> Attachments: Screenshot from 2018-03-20 08-59-39.png, Screenshot from 2018-03-20 09-20-04.png
>
>
> The decision table header cell does not support highlight / selection feature, see:
> !Screenshot from 2018-03-20 08-59-39.png|thumbnail!
> In contrast context entry name cell support this:
> !Screenshot from 2018-03-20 09-20-04.png|thumbnail!
> The outline should be consistent, i.e. blue rectangle should be rendered regardless of the selected cell type (data vs. header).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2312.
----------------------------
Resolution: Done
Partially backported to 3.6.17 (only initial change, not the optimization)
> LazyThreadFactory can keep threads instances alive for a long period
> --------------------------------------------------------------------
>
> Key: JGRP-2312
> URL: https://issues.jboss.org/browse/JGRP-2312
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: William Burns
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16, 3.6.17
>
>
> The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory.
> This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped.
> The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes.
> Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2312:
--------------------------------
OK, I fixed this by removing threads from the queue whose names are complete (no {{"<ADDR>""}} or {{"<CLUSTER>"}} parts in the name).
> LazyThreadFactory can keep threads instances alive for a long period
> --------------------------------------------------------------------
>
> Key: JGRP-2312
> URL: https://issues.jboss.org/browse/JGRP-2312
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: William Burns
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16, 3.6.17
>
>
> The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory.
> This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped.
> The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes.
> Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2312 at 11/6/18 9:23 AM:
---------------------------------------------------------
OK, I fixed this by removing threads from the queue whose names are complete (no {{"<ADDR>"}} or {{"<CLUSTER>"}} parts in the name).
was (Author: belaban):
OK, I fixed this by removing threads from the queue whose names are complete (no {{"<ADDR>""}} or {{"<CLUSTER>"}} parts in the name).
> LazyThreadFactory can keep threads instances alive for a long period
> --------------------------------------------------------------------
>
> Key: JGRP-2312
> URL: https://issues.jboss.org/browse/JGRP-2312
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: William Burns
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16, 3.6.17
>
>
> The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory.
> This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped.
> The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes.
> Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3227) [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3227?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3227:
---------------------------------------
[~manstis] if the user sets the type and save again, will it save correctly? in other words, is there a workaround?
> [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3227
> URL: https://issues.jboss.org/browse/DROOLS-3227
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Fix For: 7.15.0.Final
>
> Attachments: auto.dmn
>
>
> The decision table output column data type is not stored, if the decision table was generated according to some input data.
> An example of such table is attached [^auto.dmn] . This table was created in steps below:
> - Create new DMN diagram
> - Add an Input Data node : *applicant*
> - Add a Decision node: *applicant score*
> - Connect them
> - Define new data type: *tApplicant*.
> -- lang:string (Constraints: "c", "java")
> -- open source: boolean
> - Set *applicant* node data type as *tApplicant*
> - Set *applicant score* node data type as *number*
> - Open expression editor for *applicant score* node
> - Set its top level expression as Decision Table
> - Save and download DMN model
> - It will be like the attached
> {code:xml}
> <dmn:output id="_E6C7E5E6-45C5-4FC2-A37B-69806046893F" name="output-1" typeRef="string">
> <dmn:outputValues id="_B473BAB4-521D-4FD9-88BC-C28CD497F03A">
> <dmn:text></dmn:text>
> </dmn:outputValues>
> <dmn:defaultOutputEntry id="_85BF133E-380C-4F0E-9E2A-0C5C6493F6B4" typeRef="string">
> <dmn:text></dmn:text>
> </dmn:defaultOutputEntry>
> </dmn:output>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10919) INFO message Initialized tracer=JaegerTracer is too verbose
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFLY-10919?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-10919:
------------------------------------------
An example:
{code}
13:44:38,649 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=RS, jaeger.version=Java-0.30.6, ip=10.20.30.103}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
{code}
> INFO message Initialized tracer=JaegerTracer is too verbose
> -----------------------------------------------------------
>
> Key: WFLY-10919
> URL: https://issues.jboss.org/browse/WFLY-10919
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Major
>
> Following log message is logged during the deploy operation of a deployment:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> This information is too verbose for INFO level. I propose to do one of following:
> # Remove this log message from INFO level - note that very similar message is also logged on DEBUG level:
> {code}
> 10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> # Simplify the log message on INFO level to something simple, like:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war
> {code}
> This issue is a followup of a WFLY-10904.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11287) Shutdown hangs if WAR is distributable and uses SSE
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-11287:
-----------------------------------
Summary: Shutdown hangs if WAR is distributable and uses SSE
Key: WFLY-11287
URL: https://issues.jboss.org/browse/WFLY-11287
Project: WildFly
Issue Type: Bug
Components: Clustering, Web (Undertow)
Affects Versions: 14.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
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, 6 months
[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2312:
--------------------------------
[~dan.berindei] You're right; I don't need to track threads after both `<ADDR>` and `<CLUSTER>` have been replaced. I'll change the code accordingly.
Note - that for testing this - commit b2b83f47e5e40747a724dc0bf88e5a978249f64c already fixed the issue and has been merged onto master.
> LazyThreadFactory can keep threads instances alive for a long period
> --------------------------------------------------------------------
>
> Key: JGRP-2312
> URL: https://issues.jboss.org/browse/JGRP-2312
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: William Burns
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16, 3.6.17
>
>
> The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory.
> This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped.
> The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes.
> Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-10919) INFO message Initialized tracer=JaegerTracer is too verbose
by Michal Jurc (Jira)
[ https://issues.jboss.org/browse/WFLY-10919?page=com.atlassian.jira.plugin... ]
Michal Jurc commented on WFLY-10919:
------------------------------------
[~juraci.costa] Any updates on this? The message is quite long for {{INFO}} level log as it is now
> INFO message Initialized tracer=JaegerTracer is too verbose
> -----------------------------------------------------------
>
> Key: WFLY-10919
> URL: https://issues.jboss.org/browse/WFLY-10919
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
> Priority: Major
>
> Following log message is logged during the deploy operation of a deployment:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer=JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> This information is too verbose for INFO level. I propose to do one of following:
> # Remove this log message from INFO level - note that very similar message is also logged on DEBUG level:
> {code}
> 10:52:11,714 DEBUG [org.wildfly.microprofile.opentracing.smallrye] (ServerService Thread Pool -- 72) WFLYTRAC0001: Tracer initialized: JaegerTracer(version=Java-0.30.6, serviceName=helloworld-rs.war, reporter=RemoteReporter(sender=UdpSender(), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, manager=HttpSamplingManager(hostPort=localhost:5778), sampler=ProbabilisticSampler(tags={sampler.type=probabilistic, sampler.param=0.001})), tags={hostname=dhcp-10-40-5-80.brq.redhat.com, jaeger.version=Java-0.30.6, ip=10.40.5.80}, zipkinSharedRpcSpan=false, expandExceptionLogs=false)
> {code}
> # Simplify the log message on INFO level to something simple, like:
> {code}
> 10:52:11,703 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 72) Initialized tracer for service helloworld-rs.war
> {code}
> This issue is a followup of a WFLY-10904.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months