[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10621 at 7/26/18 5:00 PM:
--------------------------------------------------------------
[~hostalp] Is this reproducible on 14.0.0.Beta1?
I can certainly add a timeout to the lock acquisition during stop(), but this was likely already addressed by WFLY-10661.
was (Author: pferraro):
Is this reproducible on 14.0.0.Beta1?
I can certainly add a timeout to the lock acquisition during stop(), but this was likely already addressed by WFLY-10661.
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt, threaddump-wfly13-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> 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.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10621:
-------------------------------------
Is this reproducible on 14.0.0.Beta1?
I can certainly add a timeout to the lock acquisition during stop(), but this was likely already addressed by WFLY-10661.
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt, threaddump-wfly13-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> 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.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2787:
-------------------------------------
Thanks [~manstis] and [~karreiro].
* Yeah I'm not keen on that outdent arrow myself. Thanks for the context sensitive suggestion, I hadn't considered that, and it would be cleaner. Will rework with that in mind.
* WRT the Data Type Name suggestions you both are raising, I know there's been a thread about that but I missed the part where the problem was described - what problem does the recommendation solve?
Thanks for the feedback, will revise and post again.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2549) [DMN Designer] Add support for 'parent' to DMNModelInstrumentedBase
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2549?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2549:
-----------------------------------
Story Points: 1
> [DMN Designer] Add support for 'parent' to DMNModelInstrumentedBase
> -------------------------------------------------------------------
>
> Key: DROOLS-2549
> URL: https://issues.jboss.org/browse/DROOLS-2549
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Fix For: 7.10.0.Final
>
>
> {{DMNModelInstrumentedBase}} needs to support {{parent}} (like {{org.kie.dmn.model.v1_1.DMNModelInstrumentedBase}}) in order to correctly implement {{getPrefixForNamespaceURI(..)}} that is needed to set the {{QName}} prefix when setting data-types on nodes.
> At the moment the {{QName}} for data-types in the UI is using the {{namespaceURI}} instead of the {{prefix}} as it is currently impossible to lookup a {{prefix}} from the {{namespaceURI}} (of the nodes' parents up to {{Definitions}}).
> Changes required for this JIRA (split into sub-tasks when work starts):-
> * Update XML->(kie)DMN->(ui)DMN model mapping in the marshaller
> * Update the UI to set {{parent}} when adding nodes to the {{DRGElement}} and children
> * Update code relating to "setting data-type" to lookup {{prefix}} for {{QName}} (/)
> * When creating a new Diagram we need to set up the basic default NameSpace contexts on the {{DMNDiagram}}'s {{Defintions}} (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2549) [DMN Designer] Add support for 'parent' to DMNModelInstrumentedBase
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2549?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2549:
-----------------------------------
Story Points: (was: 1)
> [DMN Designer] Add support for 'parent' to DMNModelInstrumentedBase
> -------------------------------------------------------------------
>
> Key: DROOLS-2549
> URL: https://issues.jboss.org/browse/DROOLS-2549
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.7.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Fix For: 7.10.0.Final
>
>
> {{DMNModelInstrumentedBase}} needs to support {{parent}} (like {{org.kie.dmn.model.v1_1.DMNModelInstrumentedBase}}) in order to correctly implement {{getPrefixForNamespaceURI(..)}} that is needed to set the {{QName}} prefix when setting data-types on nodes.
> At the moment the {{QName}} for data-types in the UI is using the {{namespaceURI}} instead of the {{prefix}} as it is currently impossible to lookup a {{prefix}} from the {{namespaceURI}} (of the nodes' parents up to {{Definitions}}).
> Changes required for this JIRA (split into sub-tasks when work starts):-
> * Update XML->(kie)DMN->(ui)DMN model mapping in the marshaller
> * Update the UI to set {{parent}} when adding nodes to the {{DRGElement}} and children
> * Update code relating to "setting data-type" to lookup {{prefix}} for {{QName}} (/)
> * When creating a new Diagram we need to set up the basic default NameSpace contexts on the {{DMNDiagram}}'s {{Defintions}} (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Michael Anstis edited comment on DROOLS-2787 at 7/26/18 2:50 PM:
-----------------------------------------------------------------
[~uxdlc] Looks good, although I'm not keen on the "outdent arrow" icon to change the nesting of the new field. What if the "Add" button was context sensitive? So, if you had "Address" selected it'd add a child to Address, if you had "Employer" selected it'd add a child to Employer etc. If you selected tPerson3 it'd a new _root_ level field (this follows from Guilherme's [suggestion|https://issues.jboss.org/browse/DROOLS-2787?focusedCommentId=1...] of my comment about not having a "Data Type Name" text box, but the first row shows the data type name (and then name, age, Address, Employer etc are nested under that). See https://redhat.invisionapp.com/share/5WN6YR57PBV#/screens/311029287
was (Author: manstis):
[~uxdlc] Looks good, although I'm not keen on the "outdent arrow" icon to change the nesting of the new field. What if the "Add" button was context sensitive? So, if you had "Address" selected it'd add a child to Address, if you had "Employer" selected it'd add a child to Employer etc. If you selected tPerson3 it'd a new _root_ level field (this follows from Guilherme's suggestion of my comment about not having a "Data Type Name" text box, but the first row shows the data type name (and then name, age, Address, Employer etc are nested under that). See https://redhat.invisionapp.com/share/5WN6YR57PBV#/screens/311029287
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months