[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[JBoss JIRA] (WFCORE-5002) Require a minimum of Maven 3.3.0 and default to 3.3.9
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5002?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5002:
----------------------------------
Description:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI.
was:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. On some CI servers the {{.mvn/jvm.config}} will be picked up which may not allow the value to be overridden. Having a default of 1g seems like it should be sufficient.
> Require a minimum of Maven 3.3.0 and default to 3.3.9
> -----------------------------------------------------
>
> Key: WFCORE-5002
> URL: https://issues.redhat.com/browse/WFCORE-5002
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
> As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (WFCORE-5002) Require a minimum of Maven 3.3.0 and default to 3.3.9
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5002?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5002:
----------------------------------
Description:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI, http://maven.apache.org/configure.html#mvn-jvm-config-file.
was:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI.
> Require a minimum of Maven 3.3.0 and default to 3.3.9
> -----------------------------------------------------
>
> Key: WFCORE-5002
> URL: https://issues.redhat.com/browse/WFCORE-5002
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
> As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI, http://maven.apache.org/configure.html#mvn-jvm-config-file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (WFLY-13584) Require a minimum of Maven 3.3.0 and default to 3.3.9
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13584?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-13584:
---------------------------------
Description:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI, http://maven.apache.org/configure.html#mvn-jvm-config-file.
was:
The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. On some CI servers the {{.mvn/jvm.config}} will be picked up which may not allow the value to be overridden. Having a default of 1g seems like it should be sufficient.
> Require a minimum of Maven 3.3.0 and default to 3.3.9
> -----------------------------------------------------
>
> Key: WFLY-13584
> URL: https://issues.redhat.com/browse/WFLY-13584
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The current minimum Maven version is 3.3.0 which is quite old at this point. A minimum of 3.6.0 should be required with {{mvnw}} defaulting to the latest, 3.6.3.
> As part of this change we should remove the max heap from the {{.mvn/jvm.config}}. This config is picked up by maven as of 3.3.1 making it hard to override for environments like CI, http://maven.apache.org/configure.html#mvn-jvm-config-file.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months