December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12859) Acceptor is open after broker starts but before queues are created resulting in QUEUE_DOES_NOT_EXIST message=AMQ229017 (the queue is in the standalone.xml file)

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-12859?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet moved JBEAP-18238 to WFLY-12859: -------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12859 (was: JBEAP-18238) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) > Acceptor is open after broker starts but before queues are created resulting in QUEUE_DOES_NOT_EXIST message=AMQ229017 (the queue is in the standalone.xml file) > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12859 > URL: https://issues.redhat.com/browse/WFLY-12859 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: EAP 7 with EAP 6 clients > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Critical > > The Customer reports that they intermittently see error in server log file. > {noformat} > 2019-12-03T01:07:38.551+00:00@ieatrcxb4642-1@JMS@ERROR [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@2b450b36)) AMQ224016: Caught exception: ActiveMQNonExistentQueueException[errorType=QUEUE_DOES_NOT_EXIST message=AMQ229017: Queue jms.queue.NetlogRequestQueue does not exist] > at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createConsumer(ServerSessionImpl.java:504) > at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:321) > at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:285) > at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) > at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_221] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_221] > at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > {noformat} > The use case is as follow: > EAP 6 clients are running continuously and try to reconnect in case connection is lost. Normally the client does JNDI look for a destination (legacy) and the creates consumer/producer. The destination is cached. > The EAP 7 instance is start with clean data directory. The queue is defined in EAP config xml file. Once EAP instance is running and accepting connection from clients the client reconnects and tries to create consumer/producer with cached destination. At that point they see the above error in the server log. > They use legacy port 5445 to connect their client from EAP 6 to EAP 7. When I enabled {{TRACE}} logging I can see that the 5445 acceptor gets started before my destinations gets created for example: > {noformat} > 2019-12-05 16:11:12,090 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool – 78) AMQ221020: Started EPOLL Acceptor at 127.0.0.1:5445 for protocols [CORE,HORNETQ] > 2019-12-05 16:11:12,390 TRACE [org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl] (ServerService Thread Pool – 85) Sending Notification = Notification[uid=null, type=QUEUE_CREATED, properties=TypedProperties[message=jms.queue.sourceQueue]], notificationEnabled=true messagingServerControl=org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl@ef980c3 > {noformat} > So there is a chance that a client can get connected in that 300 millisecond window and could end up with the above exception. > Is there a way of reverting the order i.e. the queues get created before acceptor is enabled? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4807) [DMN Designer] Do not group V&V messages by UUID

by Kirill Gaevskii (Jira)

[ https://issues.redhat.com/browse/DROOLS-4807?page=com.atlassian.jira.plug... ] Kirill Gaevskii commented on DROOLS-4807: ----------------------------------------- Hi [~manstis], [~roger600] to make sense both approaches - but suggested by [~manstis] (each warning on separate line) looks as more clear way to me. > [DMN Designer] Do not group V&V messages by UUID > ------------------------------------------------ > > Key: DROOLS-4807 > URL: https://issues.redhat.com/browse/DROOLS-4807 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: V&V.png > > > The V&V results are grouped by UUID. See attached screen-shot. > These items are reported individually by {{kie-dmn-validation}} but grouped by {{org.kie.workbench.common.dmn.showcase.backend.validation.ValidationServiceImpl}} in the _standalone_ webapp however I fear Stunner's generic {{ValidationService}} does the same in Business Central and hence reporting DMN V&V per-line may be more troublesum. > See [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] that should more correctly be:- > {code} > @Override > public Collection<DiagramElementViolation<RuleViolation>> validate(Diagram diagram) { > return domainViolations(diagram).stream() > .filter(v -> Objects.nonNull(v.getUUID())) > .filter(v -> !"null".equals(v.getUUID())) > .map(v -> new ElementViolationImpl.Builder().setUuid(v.getUUID()).setDomainViolations(Collections.singletonList(v)).build()) > .collect(Collectors.toList()); > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2008) Test Scenarios: Ability to fail a Guvnor Test Scenario if any unexpected rules are fired when the test scenario is executed

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-2008?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-2008: ------------------------------------ Labels: drools-tools (was: ) > Test Scenarios: Ability to fail a Guvnor Test Scenario if any unexpected rules are fired when the test scenario is executed > --------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2008 > URL: https://issues.redhat.com/browse/DROOLS-2008 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing, Test Scenarios Editor > Reporter: Andrea Lee > Assignee: Toni Rikkola > Priority: Minor > Labels: drools-tools > > Example scenario: > Existing Rules: Rule A, Rule B, Rule C. > Test Scenario expectation: Expect Rule A to fire once. > I would like to have the ability to specify that this Test Scenario should fail if any other rule in addition to Rule A is fired WITHOUT having to specify the following additional expectations: Expect Rule B to not fire, Expect Rule C to not fire. > I have posted this in the user mailing list as well: http://n3.nabble.com/Guvnor-Test-Scenario-Expectations-td722429.html#a722429 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4722) Refactor DOMUtil.createNodeAtPosition

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4722?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4722: ------------------------------------ Labels: ScenarioSimulation drools-tools (was: ScenarioSimulation) > Refactor DOMUtil.createNodeAtPosition > ------------------------------------- > > Key: DROOLS-4722 > URL: https://issues.redhat.com/browse/DROOLS-4722 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Gabriele Cardosi > Priority: Major > Labels: ScenarioSimulation, drools-tools > > According a discussion [here|https://github.com/kiegroup/drools/pull/2630#discussion_r341188931] we should refactor the method _DOMParserUtil.createNodeAtPosition_ to simplify its usage by dropping its last parameter. This parameter is null in most cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4446) Confusing scenario validation message for collection types

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4446?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4446: ------------------------------------ Labels: drools-tools (was: ) > Confusing scenario validation message for collection types > ---------------------------------------------------------- > > Key: DROOLS-4446 > URL: https://issues.redhat.com/browse/DROOLS-4446 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Affects Versions: 7.26.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2019-08-20 10-19-46.png > > > There is small enhancement needed if the user validates dmn scenario with *collection* data type, being previously simple data type. > h2. Steps to reproduce > - Create new DMN > - Define there custom data type *LKW:string* > - Set this LKW type for some *input data* node > - Save DMN > - Create a Scenario for this DMN > - Go back to DMN > - Check tickbox *Is Collection* for the *LKW* type > - Save DMN > - Validate Scenario, you will get message as shown in the picture. It can be confusing as it says *LKW* changed to *LKW* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3311) Remove ScenarioSimulationDocksHandler from ScenarioSimulationEditorPresenter

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3311?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-3311: ------------------------------------ Labels: drools-tools (was: ) > Remove ScenarioSimulationDocksHandler from ScenarioSimulationEditorPresenter > ---------------------------------------------------------------------------- > > Key: DROOLS-3311 > URL: https://issues.redhat.com/browse/DROOLS-3311 > Project: Drools > Issue Type: Sub-task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Toni Rikkola > Priority: Minor > Labels: drools-tools > > Avoid direct injection of ScenarioSimulationDocksHandler inside ScenarioSimulationEditorPresenter. > Inject it inside CommandExecutor and then create/use local Event/EventBus to request actions from ScenarioSimulationEditorPresenter. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3047) Investigate if scenario simulation should be able to manage refactoring when fact or field of a fact type changes

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3047?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-3047: ------------------------------------ Labels: drools-tools (was: ) > Investigate if scenario simulation should be able to manage refactoring when fact or field of a fact type changes > ----------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3047 > URL: https://issues.redhat.com/browse/DROOLS-3047 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4507) Ability to externally execute project defined tests.

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4507?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4507: ------------------------------------ Labels: drools-tools (was: ) > Ability to externally execute project defined tests. > ---------------------------------------------------- > > Key: DROOLS-4507 > URL: https://issues.redhat.com/browse/DROOLS-4507 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Paul Brown > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > Provide the ability to externally invoke project define tests scenario i.e via a rest api. > This is required in order for project defined tests to be reused and executed as part of a delivery pipeline and not from within business central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3163) Add toolbar controls for editing the table.

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3163?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-3163: ------------------------------------ Labels: UX-CSS drools-tools (was: UX-CSS) > Add toolbar controls for editing the table. > -------------------------------------------- > > Key: DROOLS-3163 > URL: https://issues.redhat.com/browse/DROOLS-3163 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Ivo Bek > Priority: Major > Labels: UX-CSS, drools-tools > Attachments: Screen Shot 2018-10-19 at 2.32.04 PM.png > > > As a novice user of this feature I would like a simple control to edit the table (insert row etc), so that I can quickly learn how to use this tool. > Note: To align the design with both the wireframes and with similar editors (DMN) the table should offer a dropdown above the table to allow simple table structure edits. As illustrated in the wireframe click-thru: https://redhat.invisionapp.com/share/BVKORFBUJ24#/screens/302476078 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4035) Remove kie-soup-project-datamodel-api dependency from drools-scenario-simulation-api

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4035?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4035: ------------------------------------ Labels: drools-tools (was: ) > Remove kie-soup-project-datamodel-api dependency from drools-scenario-simulation-api > ------------------------------------------------------------------------------------ > > Key: DROOLS-4035 > URL: https://issues.redhat.com/browse/DROOLS-4035 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: drools-tools > > drools-scenario-simulation-api is inherited by all scenario-simulation modules, included the submarine one(s), so it must not contain anything related/specific for the "business central" environment. - DO NOT MERGE -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2019