[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Radim Vansa (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Radim Vansa commented on WFLY-13259:
------------------------------------
[~smarlow] There have been significant changes for 5.3 that let 2LC hook into transaction; {{RegionFactory.createTransactionContext()}} creates {{CacheTransactionSynchronization}} which has {{transactionCompleting()}} and {{transactionCompleted}} methods that are invoked before/after DB commit (2LC hooks as a Synchronization, not a XA resource as JPA does not guarantee any order in which XA resources are called and we need to do stuff strictly after DB commit).
The {{PutFromLoadValidator}} gets the session just as an {{Object}} as it is compatible with both 5.1 and 5.3 and it needed only to compare the objects, not call any Session-specific methods. You'll have to somehow deal with it (override for 5.3?) so that you can call {{SharedSessionContractImplementor.getCacheTransactionSynchronization()}} and register the operations.
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2463:
---------------------------
Fix Version/s: 4.2.2
5.0.0.Alpha4
Note that with a stopped node, the sender will get an ICMP error message, making it return immediately. The same goes for a node which doesn't listen on the given port, because the process has stopped.
If a node drops messages to closed ports without sending an ICMP error message, that's a problem... however, the changed disconnect algorithm should prevent dangling LEAVE responses...
Let me finish JGRP-2462, then I'll take a look!
> TransferQueueBundler: Message to stopped node blocks the bundler thread
> -----------------------------------------------------------------------
>
> Key: JGRP-2463
> URL: https://issues.redhat.com/browse/JGRP-2463
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination.
> One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s).
> {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message.
> I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-2462:
------------------------------------
Wouldn't you also have to implement explicit congestion notification as well, at least from the transport to xFC, for RED/Blue to work?
Also, would you have a single RED/Blue instance or all the members, or would each member get a separate instance, so that when a node is really slow, messages can still be sent normally to other nodes? I was thinking of JGRP-2463 and the coordinator having more load with RELAY2.
> TransferQueueBundler: drop messages if queue is full
> ----------------------------------------------------
>
> Key: JGRP-2462
> URL: https://issues.redhat.com/browse/JGRP-2462
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block.
> This can happen for example when the TCP {{send}} blocks due to a full send-window.
> Retransmission requests and responses compound the problem when the TQB's queue is full.
> Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first.
> Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter.
> Look at random early detection )\[1\]) for inspiration.
> \[1\] https://en.wikipedia.org/wiki/Random_early_detection
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread
by Dan Berindei (Jira)
Dan Berindei created JGRP-2463:
----------------------------------
Summary: TransferQueueBundler: Message to stopped node blocks the bundler thread
Key: JGRP-2463
URL: https://issues.redhat.com/browse/JGRP-2463
Project: JGroups
Issue Type: Bug
Affects Versions: 4.2.1
Reporter: Dan Berindei
Assignee: Bela Ban
{{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination.
One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s).
{{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message.
I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5199) List DMN expression is not supported in SceSim tooling
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5199?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5199:
--------------------------------
Description:
This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
h3. Input data
- Output Ref is Custom Data Type (is collection == true)
h3. Decision/BKM
- Output Ref is *Custom Data Type (is collection == true)*
- Expression type is *Relation* or *List*
- Expression type is *Decision Table* with *Hit Policy that collect multiple values*
For these situations above would be nice to use collection editor of SceSim
There are still other situations when we can not be sure if it is list or not, in such case SceSim editor doesn't need to investigate if collection editor is needed
- Output ref set as *Any*
- Literal expressions like [1, 2, 3]
was:
This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
h3. Input data
- Output Ref is Custom Data Type (is collection == true)
h3. Decision/BKM
- Output Ref is Custom Data Type (is collection == true)
- Expression type is Relation or List
- Expression type is Decision Table with Hit Policy that collect multiple values
For these situations above would be nice to use collection editor of SceSim
> List DMN expression is not supported in SceSim tooling
> ------------------------------------------------------
>
> Key: DROOLS-5199
> URL: https://issues.redhat.com/browse/DROOLS-5199
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_content.zip
>
>
> This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
> So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
> h3. Input data
> - Output Ref is Custom Data Type (is collection == true)
> h3. Decision/BKM
> - Output Ref is *Custom Data Type (is collection == true)*
> - Expression type is *Relation* or *List*
> - Expression type is *Decision Table* with *Hit Policy that collect multiple values*
> For these situations above would be nice to use collection editor of SceSim
> There are still other situations when we can not be sure if it is list or not, in such case SceSim editor doesn't need to investigate if collection editor is needed
> - Output ref set as *Any*
> - Literal expressions like [1, 2, 3]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5199) List DMN expression is not supported in SceSim tooling
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5199?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5199:
--------------------------------
Description:
This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
*Input data*
- Output Ref is Custom Data Type (is collection == true)
*Decision/BKM*
- Output Ref is *Custom Data Type (is collection == true)*
- Expression type is *Relation* or *List*
- Expression type is *Decision Table* with *Hit Policy that collect multiple values*
For these situations above would be nice to use collection editor of SceSim
There are still other situations when we can not be sure if it is list or not, in such case SceSim editor doesn't need to investigate if collection editor is needed
- Output ref set as *Any*
- Literal expressions like [1, 2, 3]
was:
This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
h3. Input data
- Output Ref is Custom Data Type (is collection == true)
h3. Decision/BKM
- Output Ref is *Custom Data Type (is collection == true)*
- Expression type is *Relation* or *List*
- Expression type is *Decision Table* with *Hit Policy that collect multiple values*
For these situations above would be nice to use collection editor of SceSim
There are still other situations when we can not be sure if it is list or not, in such case SceSim editor doesn't need to investigate if collection editor is needed
- Output ref set as *Any*
- Literal expressions like [1, 2, 3]
> List DMN expression is not supported in SceSim tooling
> ------------------------------------------------------
>
> Key: DROOLS-5199
> URL: https://issues.redhat.com/browse/DROOLS-5199
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_content.zip
>
>
> This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
> So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
> *Input data*
> - Output Ref is Custom Data Type (is collection == true)
> *Decision/BKM*
> - Output Ref is *Custom Data Type (is collection == true)*
> - Expression type is *Relation* or *List*
> - Expression type is *Decision Table* with *Hit Policy that collect multiple values*
> For these situations above would be nice to use collection editor of SceSim
> There are still other situations when we can not be sure if it is list or not, in such case SceSim editor doesn't need to investigate if collection editor is needed
> - Output ref set as *Any*
> - Literal expressions like [1, 2, 3]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5199) List DMN expression is not supported in SceSim tooling
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5199?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5199:
--------------------------------
Description:
This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
h3. Input data
- Output Ref is Custom Data Type (is collection == true)
h3. Decision/BKM
- Output Ref is Custom Data Type (is collection == true)
- Expression type is Relation or List
- Expression type is Decision Table with Hit Policy that collect multiple values
For these situations above would be nice to use collection editor of SceSim
was:The issue is in SceSim file, when user want to provide values for DMN node that has List expression inside. In such case collection editor is not offered tot he user.
> List DMN expression is not supported in SceSim tooling
> ------------------------------------------------------
>
> Key: DROOLS-5199
> URL: https://issues.redhat.com/browse/DROOLS-5199
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_content.zip
>
>
> This jira is related to DROOLS-5131 where a DMN support for *List* expression was added. DROOLS-5131 brought another way to define a collection of values.
> So in DMN DRD diagram, these are situations, when we are sure model will deal with collection
> h3. Input data
> - Output Ref is Custom Data Type (is collection == true)
> h3. Decision/BKM
> - Output Ref is Custom Data Type (is collection == true)
> - Expression type is Relation or List
> - Expression type is Decision Table with Hit Policy that collect multiple values
> For these situations above would be nice to use collection editor of SceSim
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5194) [DMN Designer] List: Remove header
by Stetson Robinson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5194?page=com.atlassian.jira.plug... ]
Stetson Robinson commented on DROOLS-5194:
------------------------------------------
Thanks keeping me in the loop so well on this [~manstis]. I'm not ignoring you, promise :) I've linked this to my appropriate Kogito epic and will be circling back to update the DMN content according. Thanks so much again!
> [DMN Designer] List: Remove header
> ----------------------------------
>
> Key: DROOLS-5194
> URL: https://issues.redhat.com/browse/DROOLS-5194
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Fix For: 7.36.0.Final
>
> Attachments: BC-nested.png, BC.png, VSCode-nested.png, VSCode.png
>
>
> Further to DROOLS-5131 it is incorrect for the {{List}} to have any header.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month