[JBoss JIRA] (DROOLS-5427) Update Type in Traffic Violation example
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-5427:
------------------------------------
Summary: Update Type in Traffic Violation example
Key: DROOLS-5427
URL: https://issues.redhat.com/browse/DROOLS-5427
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Affects Versions: 7.38.0.Final
Reporter: Anna Dupliak
Assignee: Anna Dupliak
Since we changed a constraints type mechanism we the old test scenario got failing
So need to recreate scesim file in Traffic Violation example.
workarounds:
if you recreate scesim
if you remove that column and add it again, no error is raised
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4446) Confusing scenario validation message for collection types
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4446?page=com.atlassian.jira.plug... ]
Jozef Marko closed DROOLS-4446.
-------------------------------
Fix Version/s: 7.39.0.Final
Resolution: Out of Date
Thank you [~yamer]. I can confirm this is not reproducible anymore. Closing.
> 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: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Screenshot from 2019-08-20 10-19-46.png, Screenshot from 2020-06-10 16-24-49.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, 1 month
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP edited comment on JGRP-1618 at 6/11/20 1:26 AM:
-----------------------------------------------------------
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulate in xmit_table instead of xmit_stats.
was (Author: senthil.aru):
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP commented on JGRP-1618:
----------------------------------
[~bbn-tlv] [~belaban] - Exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP edited comment on JGRP-1618 at 6/11/20 1:25 AM:
-----------------------------------------------------------
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
was (Author: senthil.aru):
[~bbn-tlv] [~belaban] - Exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5384) Clicking rightmost column's header in DMN decision table raises an error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5384?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-5384:
-------------------------------------
[~dadossan] thank you for looking into the issue. I updated the acceptance criteria as a note what to try during review as I see the fix comes to general appformer grid framework.
> Clicking rightmost column's header in DMN decision table raises an error
> ------------------------------------------------------------------------
>
> Key: DROOLS-5384
> URL: https://issues.redhat.com/browse/DROOLS-5384
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: dmn-decision-table-error-popup-7.38.0.png, drools5384.mp4
>
>
> When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
> See screenshot.
> Chrome 80.0.3987.122
> Firefox 60.6.2
> h3. Acceptance criteria
> - DMN grids are not affected
> - GDST grid is unaffected
> - Scesim grid is unaffected
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5384) Clicking rightmost column's header in DMN decision table raises an error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5384?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5384:
--------------------------------
Description:
When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
See screenshot.
Chrome 80.0.3987.122
Firefox 60.6.2
h3. Acceptance criteria
- DMN grids are not affected
- GDST grid is unaffected
- Scesim grid is unaffected
was:
When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
See screenshot.
Chrome 80.0.3987.122
Firefox 60.6.2
> Clicking rightmost column's header in DMN decision table raises an error
> ------------------------------------------------------------------------
>
> Key: DROOLS-5384
> URL: https://issues.redhat.com/browse/DROOLS-5384
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: dmn-decision-table-error-popup-7.38.0.png, drools5384.mp4
>
>
> When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
> See screenshot.
> Chrome 80.0.3987.122
> Firefox 60.6.2
> h3. Acceptance criteria
> - DMN grids are not affected
> - GDST grid is unaffected
> - Scesim grid is unaffected
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13306) Deployment of empty war with 2.3 faces-config.xml fails
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-13306?page=com.atlassian.jira.plugi... ]
Parul Sharma reassigned WFLY-13306:
-----------------------------------
Assignee: Parul Sharma (was: Farah Juma)
> Deployment of empty war with 2.3 faces-config.xml fails
> -------------------------------------------------------
>
> Key: WFLY-13306
> URL: https://issues.redhat.com/browse/WFLY-13306
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 19.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Parul Sharma
> Priority: Major
> Attachments: JsfSample.zip
>
>
> Attached sample is created from the archetype "wildfly-jakartaee-webapp-archetype" found at [https://github.com/wildfly/wildfly-archetypes/] (still 18.0, an update for WildFly 19.0 is currently in work). It is an empty project, the only change is that in "faces-config.xml" the version was changed from 2.2 to 2.3.
> Deployment fails with this exception:
> {quote}
> 2020-03-30 20:05:45,200 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 83) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:357)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:205)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> 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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> 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(Unknown Source)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:40)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:129)
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:849)
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:342)
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:420)
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:217)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:341)
> ... 23 more
> 2020-03-30 20:05:45,207 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 83) MSC000001: Failed to start service jboss.deployment.unit."JsfSample.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."JsfSample.war".undertow-deployment: java.lang.RuntimeException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> 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(Unknown Source)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:283)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:217)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> 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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> ... 10 more
> Caused by: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:357)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:205)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at com.sun.faces.facelets.impl.DefaultResourceResolver.resolveUrl(DefaultResourceResolver.java:40)
> at com.sun.faces.facelets.impl.DefaultFaceletFactory.init(DefaultFaceletFactory.java:129)
> at com.sun.faces.application.ApplicationAssociate.createFaceletFactory(ApplicationAssociate.java:849)
> at com.sun.faces.application.ApplicationAssociate.initializeFacelets(ApplicationAssociate.java:342)
> at com.sun.faces.application.ApplicationAssociate.getCompiler(ApplicationAssociate.java:420)
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:217)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:341)
> ... 23 more
> {quote}
> When adding an empty "beans.xml" file or any CDI annotated class, the error disappears.
> It also works when declaring JSF version 2.2.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month