[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-3731:
---------------------------------
[~uxdlc]Sure.
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Screen Shot 2019-05-29 at 2.49.21 PM.png, colors.png, download (1).png, download.png, multi.gif, single.gif, tmp.png, 屏幕快照 2019-06-11 下午3.02.19.png, 屏幕快照 2019-06-11 下午3.10.26.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFLY-12192) Add support for injecting Optional<T> parameter types
by Weinan Li (Jira)
[ https://issues.jboss.org/browse/WFLY-12192?page=com.atlassian.jira.plugin... ]
Weinan Li updated WFLY-12192:
-----------------------------
Summary: Add support for injecting Optional<T> parameter types (was: Support for java.util.Optional on PathParam and QueryParam)
> Add support for injecting Optional<T> parameter types
> -----------------------------------------------------
>
> Key: WFLY-12192
> URL: https://issues.jboss.org/browse/WFLY-12192
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Claudio Tagliola
> Assignee: Weinan Li
> Priority: Major
>
> Currently, PathParam and QueryParam support the following construct (from https://docs.jboss.org/resteasy/docs/3.0.17.Final/userguide/html_single/#...):
> {quote}The parameter type you inject into can be any primitive type, a String, or any Java object that has a constructor that takes a String parameter, or a static valueOf method that takes a String as a parameter.{quote}
> Proposal is to also support java.util.Optional.ofNullable as a wrapper object for Strings, which is always called. This will eliminate all null checks for optional parameters in resource classes with the different Optional followup methods, such as optional.ifPresent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (DROOLS-4264) Cannot mix rules with and without unit
by wang zongxiao (Jira)
wang zongxiao created DROOLS-4264:
-------------------------------------
Summary: Cannot mix rules with and without unit
Key: DROOLS-4264
URL: https://issues.jboss.org/browse/DROOLS-4264
Project: Drools
Issue Type: Feature Request
Reporter: wang zongxiao
Assignee: Mario Fusco
when i start kie-server deploy a project that contains guided scorecard,flowing below errors:
java.lang.IllegalStateException: Cannot mix rules with and without unit
at org.drools.core.ruleunit.State.merge(State.java:46)
at org.drools.core.ruleunit.RuleUnitDescriptionRegistry.add(RuleUnitDescriptionRegistry.java:55)
at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:930)
at org.drools.core.impl.KnowledgeBaseImpl.lambda$addPackages$2(KnowledgeBaseImpl.java:714)
at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:731)
at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:714)
at org.drools.compiler.kie.builder.impl.AbstractKieModule.createKieBase(AbstractKieModule.java:231)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:406)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:374)
at org.kie.server.services.drools.DroolsKieServerExtension.createContainer(DroolsKieServerExtension.java:98)
at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:286)
at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:517)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:406)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:370)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:372)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:344)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:317)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
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:745)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFCORE-4550) Create a test to validate CLI embedded server output after a reload
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4550?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4550:
------------------------------------------
[~jamezp] It waits up to the the CLI's connect timeout for reload to complete. In an embedded, admin-only case that should be sufficient.
https://github.com/wildfly/wildfly-core/blob/3.0.0.Final/cli/src/main/jav...
> Create a test to validate CLI embedded server output after a reload
> -------------------------------------------------------------------
>
> Key: WFCORE-4550
> URL: https://issues.jboss.org/browse/WFCORE-4550
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
> Some thought will need to go into this on how it would work. We should use a {{reload}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
> This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFCORE-4550) Create a test to validate CLI embedded server output after a reload
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4550?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4550:
----------------------------------
Description:
There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
Some thought will need to go into this on how it would work. We should use a {{reload}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
was:
There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
Some thought will need to go into this on how it would work. We should use a {{reload --start-mode=admin-only}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
> Create a test to validate CLI embedded server output after a reload
> -------------------------------------------------------------------
>
> Key: WFCORE-4550
> URL: https://issues.jboss.org/browse/WFCORE-4550
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
> Some thought will need to go into this on how it would work. We should use a {{reload}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
> This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Cheng Fang edited comment on WFLY-9631 at 6/26/19 5:03 PM:
-----------------------------------------------------------
PR sent (https://github.com/wildfly/wildfly/pull/12391) that will avoid removing those nascent timers during timer refresh. Tested with the attacdhed reproducer with 1000 and 5000 timers that are created around the same time.
While testing with the reproducer with 1000 timers, I noticed that at the first refresh, over 600 timers are in memory only and will be removed with the current implementation, but some or most of them already managed to register with management model as timer resources. So when they are brought back from db with the next refresh and try to register, it failed with duplicate resource error.
was (Author: cfang):
PR sent (https://github.com/wildfly/wildfly/pull/12391) that will avoid removing those nascent timers during timer refresh. Tested with the attacdhed reproducer with 1000 and 5000 timers that are created around the same time.
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marian Macik
> Assignee: Cheng Fang
> Priority: Major
> Attachments: WFLY-9631-reproducer.zip
>
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-9631:
----------------------------------
PR sent (https://github.com/wildfly/wildfly/pull/12391) that will avoid removing those nascent timers during timer refresh. Tested with the attacdhed reproducer with 1000 and 5000 timers that are created around the same time.
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marian Macik
> Assignee: Cheng Fang
> Priority: Major
> Attachments: WFLY-9631-reproducer.zip
>
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months
[JBoss JIRA] (WFCORE-4550) Create a test to validate CLI embedded server output after a reload
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4550?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4550:
----------------------------------
Description:
There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
Some thought will need to go into this on how it would work. We should use a {{reload --start-mode=admin-only}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
was:
There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
Some thought will need to go into this on how it would work. We should use a {{:reload(running-mode=admin-only)}} operation and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified. Both the {{:reload}} operation and {{reload}} command should likely be tested.
> Create a test to validate CLI embedded server output after a reload
> -------------------------------------------------------------------
>
> Key: WFCORE-4550
> URL: https://issues.jboss.org/browse/WFCORE-4550
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> There are tests that validate the output however these use the {{CommandContext}} which doesn't consume all the console output. It would be useful to have a test which uses a new process to test for things like WFCORE-4543.
> Some thought will need to go into this on how it would work. We should use a {{reload --start-mode=admin-only}} command and wait for the server to be ready, then use something like {{echo hello}} to ensure that logging was not configured on the CLI {{LogContext}}.
> This is not an urgent issue as manually verifying this is easy. However in the past we've had other issues similar to this and the output really should be verified.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 5 months