[JBoss JIRA] (WFLY-4262) Memory of expired session not released
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4262?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4262:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
Component/s: Web (Undertow)
> Memory of expired session not released
> --------------------------------------
>
> Key: WFLY-4262
> URL: https://issues.jboss.org/browse/WFLY-4262
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Running on Windows 7
> Wildfly 8.2
> Primefaces 5.1
> Reporter: Jose Perez
> Assignee: Stuart Douglas
> Attachments: Expired session still available.png, JVM memory usage.png, screenshot-1.png
>
>
> Expecting Wildfly to remove expired user session data after 20 minutes. But the memory is released later (see the screen shots from VisualVM)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-509) Correctly deal with deployment service restart
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-509:
-------------------------------------
Summary: Correctly deal with deployment service restart
Key: WFCORE-509
URL: https://issues.jboss.org/browse/WFCORE-509
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Reporter: Stuart Douglas
Assignee: Stuart Douglas
At the moment a lot of deployment services are not restartable, as they rely on transient state. The DeploymentUnitService has a device that will restart the whole deployment if it detects a restart, we should investigate adding something similar to other deployment services.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS updated JGRP-1876:
-------------------------------
Attachment: karim-logs-files.zip
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
I reproduced the problem and got the attached log files. Here is the scenario:
{noformat}
- View: [A, B, C]
View: [A-192.168.10.3|2] (3) [A-192.168.10.3, B-192.168.10.3, C-192.168.10.3]
- Isolate C
INFO janv. 18 17:45:40,218 | AWT-EventQueue-0 | (protocols.DISCARD) | Setting discard all value to: true
- Views:
View: [A-192.168.10.3|3] (2) [A-192.168.10.3, B-192.168.10.3]
View: [C-192.168.10.3|3] (1) [C-192.168.10.3]
TRACE janv. 18 17:46:55,703 | Timer-2,TEST,A-192.168.10.3 | (protocols.MERGE3) | A-192.168.10.3: Sending MergeInfo[[A-192.168.10.3|3]]
- No isolate C 2s later
INFO janv. 18 17:46:57,781 | AWT-EventQueue-0 | (protocols.DISCARD) | Setting discard all value to: false
- C detect incoherent view and proceed to merge
INFO janv. 18 17:47:26,359 | Timer-3,TEST,C-192.168.10.3 | (protocols.MERGE3) | C-192.168.10.3: found inconsistent views: [C-192.168.10.3|3]: [(1) C-192.168.10.3]
[A-192.168.10.3|3]: [(1) B-192.168.10.3]
- View on B and C : [C-192.168.10.3|4] (2) [C-192.168.10.3, B-192.168.10.3]
{noformat}
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-690) Deadlock on LeftTupleSets
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-690?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-690.
--------------------------------
Fix Version/s: 6.2.0.Final
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/30b295c7c50d3ab283c22bab025bb...
> Deadlock on LeftTupleSets
> -------------------------
>
> Key: DROOLS-690
> URL: https://issues.jboss.org/browse/DROOLS-690
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> The following deadlock has been reported:
> {code}
> Java stack information for the threads listed above:
> ===================================================
> "drools-worker-2":
> at org.drools.core.common.DefaultAgenda.addEagerRuleAgendaItem(DefaultAgenda.java:282)
> - waiting to lock <0x00000007d8fc80d0> (a java.util.LinkedList)
> at org.drools.core.reteoo.PathMemory.queueRuleAgendaItem(PathMemory.java:153)
> at org.drools.core.reteoo.PathMemory.doLinkRule(PathMemory.java:120)
> - locked <0x00000007d91f34d0> (a org.drools.core.reteoo.PathMemory)
> at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:90)
> at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:170)
> at org.drools.core.reteoo.LeftInputAdapterNode$LiaNodeMemory.setNodeDirty(LeftInputAdapterNode.java:645)
> at org.drools.core.reteoo.LeftInputAdapterNode.doUpdateSegmentMemory(LeftInputAdapterNode.java:396)
> - locked <0x00000007d91f68a8> (a java.lang.Object)
> at org.drools.core.reteoo.LeftInputAdapterNode.doUpdateObject(LeftInputAdapterNode.java:366)
> at org.drools.core.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:436)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:512)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:437)
> at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:382)
> at org.drools.core.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:273)
> at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:511)
> at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:385)
> at drools.core.Rule_vme$u46$phases_inconnues1199361134.defaultConsequence(Rule_vme$u46$phases_inconnues1199361134.java:19)
> at drools.core.Rule_vme$u46$phases_inconnues1199361134DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at drools.core.Rule_vme$u46$phases_inconnues1199361134DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1046)
> - locked <0x00000007d8fc8080> (a org.drools.core.common.DefaultAgenda)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:152)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:100)
> - locked <0x00000007d9335498> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.phreak.PhreakTimerNode$Executor.evauateAndFireRule(PhreakTimerNode.java:483)
> at org.drools.core.phreak.PhreakTimerNode$TimerNodeJob$1.run(PhreakTimerNode.java:420)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> "Drools thread":
> at org.drools.core.common.SynchronizedLeftTupleSets.takeAll(SynchronizedLeftTupleSets.java:44)
> - waiting to lock <0x00000007d91f68a8> (a java.lang.Object)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:112)
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:77)
> - locked <0x00000007d9334c40> (a org.drools.core.phreak.RuleExecutor)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:990)
> - locked <0x00000007d8fc80d0> (a java.util.LinkedList)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:945)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1190)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1329)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1306)
> at drools.core.Core$2.run(Core.java:495)
> at java.lang.Thread.run(Thread.java:744)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
I created a [PR | https://github.com/belaban/JGroups/pull/199] to fix the issue reported by Radim.
I will describe the root cause in the next comment.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4262) Memory of expired session not released
by Wojciech Ozga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4262?page=com.atlassian.jira.plugin.... ]
Wojciech Ozga updated WFLY-4262:
--------------------------------
Description: Expecting Wildfly to remove expired user session data after 20 minutes. But the memory is released later (see the screen shots from VisualVM) (was: Expecting Wildfly to remove expired user session data after 20 minutes. But the data is never removed, neither by container, neither by GC, neither when new requests reach the server.)
> Memory of expired session not released
> --------------------------------------
>
> Key: WFLY-4262
> URL: https://issues.jboss.org/browse/WFLY-4262
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Running on Windows 7
> Wildfly 8.2
> Primefaces 5.1
> Reporter: Wojciech Ozga
> Assignee: Jason Greene
> Attachments: Expired session still available.png, JVM memory usage.png
>
>
> Expecting Wildfly to remove expired user session data after 20 minutes. But the memory is released later (see the screen shots from VisualVM)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4262) Memory of expired session not released
by Wojciech Ozga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4262?page=com.atlassian.jira.plugin.... ]
Wojciech Ozga updated WFLY-4262:
--------------------------------
Steps to Reproduce:
1. Set user session expiration to 20minutes in web.xml
<session-config>
<session-timeout>20</session-timeout>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
2. Deploy project to clean WildFy 8.2
3. Simulated traffic with JMeter, creating new user session on every request, till the JVM memory is almost fully used.
4. wait 20 minutes and verify that the sessions was not removed
5. try to make new requests - verify that session waas not removed
6. perform System.gc() from the code or from fe: VisualVM
was:
1. Set user session expiration to 20minutes in web.xml
2. Deploy project to clean WildFy 8.2
3. Simulated traffic with JMeter, creating new user session on every request, till the JVM memory is almost fully used.
4. wait 20 minutes and verify that the sessions was not removed
5. try to make new requests - verify that session waas not removed
6. perform System.gc() from the code or from fe: VisualVM
> Memory of expired session not released
> --------------------------------------
>
> Key: WFLY-4262
> URL: https://issues.jboss.org/browse/WFLY-4262
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Running on Windows 7
> Wildfly 8.2
> Primefaces 5.1
> Reporter: Wojciech Ozga
> Assignee: Jason Greene
> Attachments: Expired session still available.png, JVM memory usage.png
>
>
> Expecting Wildfly to remove expired user session data after 20 minutes. But the data is never removed, neither by container, neither by GC, neither when new requests reach the server.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4262) Memory of expired session not released
by Wojciech Ozga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4262?page=com.atlassian.jira.plugin.... ]
Wojciech Ozga updated WFLY-4262:
--------------------------------
Attachment: JVM memory usage.png
> Memory of expired session not released
> --------------------------------------
>
> Key: WFLY-4262
> URL: https://issues.jboss.org/browse/WFLY-4262
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Running on Windows 7
> Wildfly 8.2
> Primefaces 5.1
> Reporter: Wojciech Ozga
> Assignee: Jason Greene
> Attachments: Expired session still available.png, JVM memory usage.png
>
>
> Expecting Wildfly to remove expired user session data after 20 minutes. But the data is never removed, neither by container, neither by GC, neither when new requests reach the server.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months