[JBoss JIRA] (WFCORE-4225) INFO message Initialized tracer=JaegerTracer is too verbose
by Juraci Paixão Kröhling (Jira)
[ https://issues.jboss.org/browse/WFCORE-4225?page=com.atlassian.jira.plugi... ]
Juraci Paixão Kröhling commented on WFCORE-4225:
------------------------------------------------
Awesome, thanks!
> INFO message Initialized tracer=JaegerTracer is too verbose
> -----------------------------------------------------------
>
> Key: WFCORE-4225
> URL: https://issues.jboss.org/browse/WFCORE-4225
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Jan Stourac
> Assignee: James Perkins
> 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, 8 months
[JBoss JIRA] (WFLY-11328) EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-11328?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek commented on WFLY-11328:
--------------------------------------
[~emmartins] Thank you for your analysis.
Comment belonging to current PR:
ad 1 - I think that synchronization could be omitted without any impact, additions to list are called typically at server startup, iteration is called after 1 minute and then periodically, so there should be no conflict
ad 2 - 10 seconds is really low value, originally I was using 1 minute - but with last change, I've accidentally commited also this change (which is my ebg value). -> so 10 sec as mistake from my side, there should be 1 minute - which should be OK (as you are suggesting it in b)
I agree that killing threads is rather strict. I can imagine logging some warnings for user to know about hung treads as you are suggesting in b. But you last comment shows, that in some cases, this threshold could be reconfigured to different values -> so even logging will happen in wrong times.
>From my point of view, much easier and consistent behavior will be item *a*.
@Masafumi Miura (reporter of the original issue - https://issues.jboss.org/browse/JBEAP-13778) What do you think?
> EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11328
> URL: https://issues.jboss.org/browse/WFLY-11328
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
>
> ee subsystem parameters "hung-task-threshold" and "long-running-tasks" for managed-executor-service / managed-scheduled-executor-service do not work and are not implemented as described in [EAP 7 Development Guide|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterpr...]:
> - hung-task-threshold: Defines the time, in milliseconds, after which tasks are considered hung by the managed executor service and forcefully aborted. If the value is 0 (which is the default), tasks are never considered hung.
> - long-running-tasks: Suggests optimizing the execution of long running tasks, and defaults to false.
> I tested with [EAP 7 QuickStarts managed-executor-service example|https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0...] but these paremeters doe not take any effect:
> - tasks exceeding hung-task-threshold are never forcefully aborted. And there's no way to detect hung tasks exceeding hung-task-threshold.
> - setting long-running-tasks to true does not change the behavior.
> As far as I checked the source code, I noticed the following:
> - EAP 7.x uses the EE Concurency Utilities RI [org.glassfish.enterprise.concurrent|https://github.com/javaee/cu-ri] internally and just passes the paramters to the RI.
> - In the EE Concurency Utilities RI, these parameters are used in the methods [ManagedThreadFactoryImpl#isTaskHung(long now)|https://github.com/javaee/cu-ri/blob/master/src/main/java/org/glassf...], [AbstractManagedExecutorService#getHungThreads()|https://github.com/javaee...] and [AbstractManagedExecutorService#isLongRunningTasks()|https://github.com/ja...] (AbstractManagedExecutorService is the parent class of ManagedExecutorServiceImpl / ManagedScheduledExecutorServiceImpl).
> - However, these methods are never invoked from EAP 7.x. So, these parameters do not take any effect in EAP 7.x.
> - In addition, even if these methods are used, it looks the implementation is totally different from the description in the documentation. The parameter "long-running-tasks" is just used as a flag to skip from checking hung thread detection. And the parameter "hung-task-threshold" never forcefully abort the hung thread exceeding the threshold.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11328) EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-11328?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek edited comment on WFLY-11328 at 11/14/18 2:57 AM:
----------------------------------------------------------------
[~emmartins] Thank you for your analysis.
Comment belonging to current PR:
ad 1 - I think that synchronization could be omitted without any impact, additions to list are called typically at server startup, iteration is called after 1 minute and then periodically, so there should be no conflict
ad 2 - 10 seconds is really low value, originally I was using 1 minute - but with last change, I've accidentally commited also this change (which is my ebg value). -> so 10 sec as mistake from my side, there should be 1 minute - which should be OK (as you are suggesting it in b)
I agree that killing threads is rather strict. I can imagine logging some warnings for user to know about hung treads as you are suggesting in b. But you last comment shows, that in some cases, this threshold could be reconfigured to different values -> so even logging will happen in wrong times.
>From my point of view, much easier and consistent behavior will be item *a*.
was (Author: jondruse):
[~emmartins] Thank you for your analysis.
Comment belonging to current PR:
ad 1 - I think that synchronization could be omitted without any impact, additions to list are called typically at server startup, iteration is called after 1 minute and then periodically, so there should be no conflict
ad 2 - 10 seconds is really low value, originally I was using 1 minute - but with last change, I've accidentally commited also this change (which is my ebg value). -> so 10 sec as mistake from my side, there should be 1 minute - which should be OK (as you are suggesting it in b)
I agree that killing threads is rather strict. I can imagine logging some warnings for user to know about hung treads as you are suggesting in b. But you last comment shows, that in some cases, this threshold could be reconfigured to different values -> so even logging will happen in wrong times.
>From my point of view, much easier and consistent behavior will be item *a*.
@Masafumi Miura (reporter of the original issue - https://issues.jboss.org/browse/JBEAP-13778) What do you think?
> EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11328
> URL: https://issues.jboss.org/browse/WFLY-11328
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
>
> ee subsystem parameters "hung-task-threshold" and "long-running-tasks" for managed-executor-service / managed-scheduled-executor-service do not work and are not implemented as described in [EAP 7 Development Guide|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterpr...]:
> - hung-task-threshold: Defines the time, in milliseconds, after which tasks are considered hung by the managed executor service and forcefully aborted. If the value is 0 (which is the default), tasks are never considered hung.
> - long-running-tasks: Suggests optimizing the execution of long running tasks, and defaults to false.
> I tested with [EAP 7 QuickStarts managed-executor-service example|https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0...] but these paremeters doe not take any effect:
> - tasks exceeding hung-task-threshold are never forcefully aborted. And there's no way to detect hung tasks exceeding hung-task-threshold.
> - setting long-running-tasks to true does not change the behavior.
> As far as I checked the source code, I noticed the following:
> - EAP 7.x uses the EE Concurency Utilities RI [org.glassfish.enterprise.concurrent|https://github.com/javaee/cu-ri] internally and just passes the paramters to the RI.
> - In the EE Concurency Utilities RI, these parameters are used in the methods [ManagedThreadFactoryImpl#isTaskHung(long now)|https://github.com/javaee/cu-ri/blob/master/src/main/java/org/glassf...], [AbstractManagedExecutorService#getHungThreads()|https://github.com/javaee...] and [AbstractManagedExecutorService#isLongRunningTasks()|https://github.com/ja...] (AbstractManagedExecutorService is the parent class of ManagedExecutorServiceImpl / ManagedScheduledExecutorServiceImpl).
> - However, these methods are never invoked from EAP 7.x. So, these parameters do not take any effect in EAP 7.x.
> - In addition, even if these methods are used, it looks the implementation is totally different from the description in the documentation. The parameter "long-running-tasks" is just used as a flag to skip from checking hung thread detection. And the parameter "hung-task-threshold" never forcefully abort the hung thread exceeding the threshold.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9588) Investigate on splitting as transaction module to not be gathering all dependencies
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-9588?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka edited comment on WFLY-9588 at 11/14/18 2:54 AM:
-----------------------------------------------------------------
[~brian.stansberry] made the fixes for transaction subsystem to add capabilities. The summary jira is https://issues.jboss.org/browse/WFLY-11165.
The work consisted of adding capability for TransactionManager, UserTransaction and TransactionSynchronizationRegistry (WFLY-11166) and for XAResourceRecoveryRegistry (WFLY-11167). On top of that the module dependencies were stripped a bit by [fixes of me |https://github.com/wildfly/wildfly/pull/11800] and [~yersan] (WFLY-5966, WFLY-11276, WFLY-11263). With that txframework module was deprecated (WFLY-11271).
The task for the next work are:
* summary by Brian at his comment at https://issues.jboss.org/browse/WFLY-11165?focusedCommentId=13659726#comm...
* making compensations module optional for transaction module (probably having a compensations resource in the transactions subsystem or what Brian developed https://github.com/bstansberry/wildfly/commit/0a5e51fe0988b72690b31456cbc..., it needs to be considered), will be tracked at WFLY-9587
* considering making transaction module more granular (e.g. jta/jts integration modules could be provided) which can bring possibility to provide jta and jts capabilities separately (this is what I started to play with at https://github.com/ochaloup/wildfly/tree/JBEAP-14212-jta-dependency-reorg..., https://github.com/ochaloup/narayana/tree/JBEAP-14212-dependency-cleaning)
was (Author: ochaloup):
[~brian.stansberry] made the fixes for transaction subsystem to add capabilities. The summary jira is https://issues.jboss.org/browse/WFLY-11165.
The work consisted of adding capability for TransactionManager, UserTransaction and TransactionSynchronizationRegistry (WFLY-11166) and for XAResourceRecoveryRegistry (WFLY-11167). On top of that the module dependencies were stripped a bit by [fixes of me |https://github.com/wildfly/wildfly/pull/11800] and [~yersan] (WFLY-5966, WFLY-11276, WFLY-11263). With that txframework module was deprecated (WFLY-11271).
The task for the next work are:
* summary by Brian at his comment at https://issues.jboss.org/browse/WFLY-11165?focusedCommentId=13659726#comm...
* making compensations module optional for transaction module (probably having a compensations resource in the transactions subsystem or what Brian developed https://github.com/bstansberry/wildfly/commit/0a5e51fe0988b72690b31456cbc..., it needs to be considered)
* considering making transaction module more granular (e.g. jta/jts integration modules could be provided) which can bring possibility to provide jta and jts capabilities separately (this is what I started to play with at https://github.com/ochaloup/wildfly/tree/JBEAP-14212-jta-dependency-reorg..., https://github.com/ochaloup/narayana/tree/JBEAP-14212-dependency-cleaning)
> Investigate on splitting as transaction module to not be gathering all dependencies
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9588
> URL: https://issues.jboss.org/browse/WFLY-9588
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Affects Versions: 11.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Major
> Attachments: eap71-txn-dependencies.jpg
>
>
> Current org.jboss.as.transaction module is heavy lifting and has many dependencies and lot of work competencies. E.g. org.jboss.jts module depends on that too.
> It should be investigated how to disentangle all the dependencies.
> Plus this could be beneficiary for WildFly Swarm if we are able to split the dependency chains, maybe not using one big jar in the transaction module but provide more granularity. Needs to be investigated.
> See attached image for a view of dependencies.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3242) [Scenario Simulation] Update cell (double-)click interactions
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3242?page=com.atlassian.jira.plugi... ]
Daniele Zonca reassigned DROOLS-3242:
-------------------------------------
Assignee: Gabriele Cardosi (was: Daniele Zonca)
> [Scenario Simulation] Update cell (double-)click interactions
> --------------------------------------------------------------
>
> Key: DROOLS-3242
> URL: https://issues.jboss.org/browse/DROOLS-3242
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Ivo Bek
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> Following from a discussion about https://issues.jboss.org/browse/DROOLS-2874 it was agreed that editing cells (header or body) in the grids should respond to single-click and not double-click.
> h2. Manual Acceptance Test
> - Not possible edit multiple cells by hold CTRL and click on multiple cells
> - Click column/row leading cell discard edit dialog
> - Edit can be discarded by escape
> - Edit can be discarded by click to canvas
> - Invoke edit of cell
> - Save and reopen
> - Undo redo of editation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (SWSQE-493) Central CI Resource Availability
by Matt Mahoney (Jira)
Matt Mahoney created SWSQE-493:
----------------------------------
Summary: Central CI Resource Availability
Key: SWSQE-493
URL: https://issues.jboss.org/browse/SWSQE-493
Project: Kiali QE
Issue Type: QE Task
Reporter: Matt Mahoney
Assignee: Matt Mahoney
Clean up unused instances.
Currently OSOOS clusters are built with instance flavor:
m1.large: 8Gb, 4 Cores, 40G storage
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months