[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2430:
---------------------------
Fix Version/s: 5.0
4.2.1
(was: 4.2.0)
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.1
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13142) Can't create a Connection Factory using JGroups discovery
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13142?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13142:
----------------------------------
Summary: Can't create a Connection Factory using JGroups discovery (was: Can't create a Connection Factory using Jgroups discovery)
> Can't create a Connection Factory using JGroups discovery
> ---------------------------------------------------------
>
> Key: WFLY-13142
> URL: https://issues.redhat.com/browse/WFLY-13142
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 19.0.0.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> When trying to configure a connection factory with a JGroup Discovery Group it fails with the exception:
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.messaging-activemq.bindings.discovery.dg-group1"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.jms.pooled-connection-factory.activemq-ra is missing [jboss.messaging-activemq.bindings.discovery.dg-group1]"]
> },
> "rolled-back" => true
> }
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5009:
----------------------------------------
I spotted the convo on brms mailing list.
I am confused as to why {{number}} or {{date}} etc. are considered keywords?
In my understanding, based purely on the DMN spec, they are not keyword and they should work just fine for ItemDefinition fields.
If something from the backend is triggering wrong result please advise and I will take a look.
Finally, please confirm your understanding.
> DMN Designer convert java class with invalid DMN identiefier
> ------------------------------------------------------------
>
> Key: DROOLS-5009
> URL: https://issues.redhat.com/browse/DROOLS-5009
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-05 16-21-10.png
>
>
> There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN.
> for example assume this java class and try to convert it into DMN data type, you will get an error as attached.
> {code:java}
> public class Address {
> private int number;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier
by Donato Marrazzo (Jira)
[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ]
Donato Marrazzo commented on DROOLS-5009:
-----------------------------------------
I think that the right approach is to omit the field and inform the user.
> DMN Designer convert java class with invalid DMN identiefier
> ------------------------------------------------------------
>
> Key: DROOLS-5009
> URL: https://issues.redhat.com/browse/DROOLS-5009
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-05 16-21-10.png
>
>
> There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN.
> for example assume this java class and try to convert it into DMN data type, you will get an error as attached.
> {code:java}
> public class Address {
> private int number;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Hielke Hoeve (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Hielke Hoeve updated WFLY-13162:
--------------------------------
Steps to Reproduce:
- Download wildfly 18.0.1.Final & extract & use wildfly-18.0.1.Final
- Checkout hielkehoeve/wildfly/18.0.x
- Build test project (testsuite/integration/batch-jberet/WFLY-13162)
- Copy standalone/configuration/standalone-full.xml to standalone/configuration/standalone.xml
- Start wildfly in standalone mode
- Redeploy project.ear a number of times (testsuite/integration/batch-jberet/concurrentmodificationexception/project-ear/target/project.ear)
was:
- Download wildfly 18.0.1.Final & extract & use wildfly-18.0.1.Final
- Checkout hielkehoeve/wildfly/18.0.x
- Build test project (testsuite/integration/batch-jberet/concurrentmodificationexception)
- Copy standalone/configuration/standalone-full.xml to standalone/configuration/standalone.xml
- Start wildfly in standalone mode
- Redeploy project.ear a number of times (testsuite/integration/batch-jberet/concurrentmodificationexception/project-ear/target/project.ear)
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/tree/18.0.x. The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13162) ConcurrentModificationException in WildFlyJobXmlResolver
by Hielke Hoeve (Jira)
[ https://issues.redhat.com/browse/WFLY-13162?page=com.atlassian.jira.plugi... ]
Hielke Hoeve updated WFLY-13162:
--------------------------------
Steps to Reproduce:
- Download wildfly 18.0.1.Final & extract & use wildfly-18.0.1.Final
- Checkout hielkehoeve/wildfly/18.0.x
- Build test project (testsuite/integration/batch-jberet/WFLY-13162)
- Copy standalone/configuration/standalone-full.xml to standalone/configuration/standalone.xml
- Start wildfly in standalone mode
- Redeploy project.ear a number of times (testsuite/integration/batch-jberet/WFLY-13162/project-ear/target/project.ear)
was:
- Download wildfly 18.0.1.Final & extract & use wildfly-18.0.1.Final
- Checkout hielkehoeve/wildfly/18.0.x
- Build test project (testsuite/integration/batch-jberet/WFLY-13162)
- Copy standalone/configuration/standalone-full.xml to standalone/configuration/standalone.xml
- Start wildfly in standalone mode
- Redeploy project.ear a number of times (testsuite/integration/batch-jberet/concurrentmodificationexception/project-ear/target/project.ear)
> ConcurrentModificationException in WildFlyJobXmlResolver
> --------------------------------------------------------
>
> Key: WFLY-13162
> URL: https://issues.redhat.com/browse/WFLY-13162
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 18.0.1.Final, 19.0.0.Beta3
> Reporter: Hielke Hoeve
> Assignee: Cheng Fang
> Priority: Major
>
> Because of a thread unsafe construction in WildFlyJobXmlResolver I am experiencing ConcurrentModificationExceptions while starting my EAR every so often. This is because every EJB of the EAR is processed by WildFlyJobXmlResolver in paralel threads. Even if it has no jbatch dependency or dependency to a EJB which does.
> This is not reproducable for every startup as it depends on the performance of the host machine, number of ejbs in ear, number of threads and thread timing.
> I have created an example project representing our project setup with which I am able to reproduce the issue using a default wildfly build. This test project contains 1 EJB with jbatch, a number of plain EJBs, a WAR which uses the jbatch EJB and an EAR.
> See below for the exception stacktrace.
> I have made a small fix for this issue @ https://github.com/hielkehoeve/wildfly/tree/18.0.x. The example test project can also be found there.
> {code:java}
> 08:32:30,164 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."project.ear"."project-d.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "project-d.jar" of deployment "project.ear"
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.util.ConcurrentModificationException
> at java.base/java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.base/java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:741)
> at java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.merge(WildFlyJobXmlResolver.java:261)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:127)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:130)
> at org.wildfly.extension.batch.jberet@18.0.0.Final//org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:78)
> at org.jboss.as.server@10.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months