[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Dennis Reed (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Dennis Reed updated JGRP-2135:
------------------------------
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Dennis Reed (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Dennis Reed reopened JGRP-2135:
-------------------------------
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ELY-1950) FORM authentication not working for URL encoded session IDs
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1950?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1950:
----------------------------------
Security: (was: Security Issue)
> FORM authentication not working for URL encoded session IDs
> -----------------------------------------------------------
>
> Key: ELY-1950
> URL: https://issues.redhat.com/browse/ELY-1950
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.12.0.CR1
>
>
> The session IDs are encoded as: -
> {code}
> /secure/j_security_check;jsessionid=kVzsBG9c3XxcOlzpa65ohiMeMNqXdSNQuOdvdpR3.flame
> {code}
> However the code that checks if this is a submission to j_security_check is: -
> {code:java}
> request.getRequestURI().getPath().endsWith(postLocation)
> {code}
> This code needs to trim the path at ';'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Francisco De Melo Junior (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Francisco De Melo Junior commented on JGRP-2135:
------------------------------------------------
Hello Bela Ban, we are experiencing a similar behavior on 3.6.13 (which is imported on eap 7.1).
1. Was there a change on code for version 13? I couldn't find it here.
2. Would be possible to you implement any change (for example getting the max_msg_size before) to avoid OOME being thrown? (and heap dump in case the flag OnOutOfMemoryError || HeapDumpOnOutOfMemoryError)
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5263) [Test Scenario Editor] Wrong test result status if rules have not been fired
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5263?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5263:
-------------------------------
Sprint: 2020 Week 16-18 (from Apr 13)
> [Test Scenario Editor] Wrong test result status if rules have not been fired
> -----------------------------------------------------------------------------
>
> Key: DROOLS-5263
> URL: https://issues.redhat.com/browse/DROOLS-5263
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_List.zip, Screenshot from 2020-04-21 17-28-31.png, screenshot-1.png
>
>
> Defect: If user create a list - typed fact and puts it to the Test Scenario test passes but coverage is 0.
> This feature implemented other way in legacy test scenario.
> Root case :
> We removed initialization of the list by default .
> Previously when you have been adding a fact to legacy test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element
> Now If you add a list fact you are free to left it empty or initialize it with at least one element.
> In that case if there was no rules fired we need to show a warning and mark the test as FAILED.
> Workaround: put in GIVEN section for the list at least one empty element
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5263) [Test Scenario Editor] Wrong test result status if rules have not been fired
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5263?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5263:
-------------------------------
Story Points: 3
> [Test Scenario Editor] Wrong test result status if rules have not been fired
> -----------------------------------------------------------------------------
>
> Key: DROOLS-5263
> URL: https://issues.redhat.com/browse/DROOLS-5263
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_List.zip, Screenshot from 2020-04-21 17-28-31.png, screenshot-1.png
>
>
> Defect: If user create a list - typed fact and puts it to the Test Scenario test passes but coverage is 0.
> This feature implemented other way in legacy test scenario.
> Root case :
> We removed initialization of the list by default .
> Previously when you have been adding a fact to legacy test scenario - it was automatically initializing so in the end you got in GIVEN list with one empty element
> Now If you add a list fact you are free to left it empty or initialize it with at least one element.
> In that case if there was no rules fired we need to show a warning and mark the test as FAILED.
> Workaround: put in GIVEN section for the list at least one empty element
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years