[JBoss JIRA] (WFLY-9450) NPE on jaxrs subsystem of FAILED deployment
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-9450?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski edited comment on WFLY-9450 at 1/29/20 4:21 AM:
-------------------------------------------------------------------
[~emiliocuberos] - this seem to be different issue. Please open new JIRA and attach reproducer.
was (Author: baranowb):
@Emilio Cuberos - this seem to be different issue. Please open new JIRA and attach reproducer.
> NPE on jaxrs subsystem of FAILED deployment
> --------------------------------------------
>
> Key: WFLY-9450
> URL: https://issues.redhat.com/browse/WFLY-9450
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 15.0.1.Final
> Reporter: Claudio Miranda
> Assignee: Bartosz Baranowski
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> read deployment resources of a server, where one deployment is in failed status, throws a NPE and doesn't return the list of deployed applications.
> To reproduce, get the kitchensink from quickstarts, change the persistence.xml to point to ExampleDS datasource, deploy and assign to main-server-group. Then disable ExampleDS, restart server-one.
> Run the following command:
> {code}
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> {code}
> deploy ~/redhat/git/quickstart/kitchensink/target/kitchensink.war --server-groups=main-server-group
> /profile=default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full-ha/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /host=master/server=server-one:reload
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> The exception in server.log
> {code}
> 2017-10-17 17:08:02,778 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.getDeployment(UndertowDeploymentService.java:170)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:183)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> {code}
> The CLI results doesn't display the error message
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => undefined,
> "failure-description" => undefined
> }
> {code}
> There is a similar problem while reading a specific deployment,
> {code}
> /host=master/server=server-one/deployment=kitchensink.war:read-children-resources(child-type=subsystem,recursive)
> {code}
> results in the following error in server.log
> {code}
> 2017-10-17 17:16:09,857 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "MemberRegistration")
> ]) - failure description: "WFLYEJB0370: EJB component for address [
> (\"deployment\" => \"kitchensink.war\"),
> (\"subsystem\" => \"ejb3\"),
> (\"stateless-session-bean\" => \"MemberRegistration\")
> ] is in
> state DOWN, must be in state UP"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-9450) NPE on jaxrs subsystem of FAILED deployment
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-9450?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-9450:
------------------------------------------
@Emilio Cuberos - this seem to be different issue. Please open new JIRA and attach reproducer.
> NPE on jaxrs subsystem of FAILED deployment
> --------------------------------------------
>
> Key: WFLY-9450
> URL: https://issues.redhat.com/browse/WFLY-9450
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 15.0.1.Final
> Reporter: Claudio Miranda
> Assignee: Bartosz Baranowski
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> read deployment resources of a server, where one deployment is in failed status, throws a NPE and doesn't return the list of deployed applications.
> To reproduce, get the kitchensink from quickstarts, change the persistence.xml to point to ExampleDS datasource, deploy and assign to main-server-group. Then disable ExampleDS, restart server-one.
> Run the following command:
> {code}
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> {code}
> deploy ~/redhat/git/quickstart/kitchensink/target/kitchensink.war --server-groups=main-server-group
> /profile=default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full-ha/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /host=master/server=server-one:reload
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> The exception in server.log
> {code}
> 2017-10-17 17:08:02,778 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.getDeployment(UndertowDeploymentService.java:170)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:183)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> {code}
> The CLI results doesn't display the error message
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => undefined,
> "failure-description" => undefined
> }
> {code}
> There is a similar problem while reading a specific deployment,
> {code}
> /host=master/server=server-one/deployment=kitchensink.war:read-children-resources(child-type=subsystem,recursive)
> {code}
> results in the following error in server.log
> {code}
> 2017-10-17 17:16:09,857 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "MemberRegistration")
> ]) - failure description: "WFLYEJB0370: EJB component for address [
> (\"deployment\" => \"kitchensink.war\"),
> (\"subsystem\" => \"ejb3\"),
> (\"stateless-session-bean\" => \"MemberRegistration\")
> ] is in
> state DOWN, must be in state UP"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned WFCORE-4820:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-4820:
------------------------------------------
Can you please post the full error including any associated stack trace.
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13031) EAP quickstart 'messaging-clustering-singleton' shows errors after import
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-13031?page=com.atlassian.jira.plugi... ]
Parul Sharma moved JBEAP-17131 to WFLY-13031:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13031 (was: JBEAP-17131)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Quickstarts
(was: JMS)
(was: Quickstarts)
Environment: (was: OS X 10.14.5)
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.2.0.GA)
> EAP quickstart 'messaging-clustering-singleton' shows errors after import
> -------------------------------------------------------------------------
>
> Key: WFLY-13031
> URL: https://issues.redhat.com/browse/WFLY-13031
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Reporter: Zbyněk Červinka
> Assignee: Parul Sharma
> Priority: Major
> Attachments: Problems view.png, Project Explorer.png, jboss-ejb3.xml file.png
>
>
> h1. EAP quickstart 'messaging-clustering-singleton' shows 3 errors in the jboss-ejb3.xml file after import:
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb-delivery-active_1_1.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
> * Referenced file contains errors (jar:file:/Applications/codereadystudio-eap-8/studio/codereadystudio.app/Contents/Eclipse/plugins/org.jboss.tools.as.catalog_3.7.0.v20190624-1620.jar!/schema/xsd/jboss-ejb3-spec-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Volodymyr Shymkiv (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Volodymyr Shymkiv commented on DROOLS-4967:
-------------------------------------------
Attached your file updated. It won't be working but it is completely the same as yours. Just edited in excel in different order...
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls, CanNotDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Volodymyr Shymkiv (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Volodymyr Shymkiv updated DROOLS-4967:
--------------------------------------
Attachment: CanNotDrink2.xls
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls, CanNotDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2436) Diagnostics: enable TCP by default
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2436?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2436:
--------------------------------
I had to revert this: the testsuite created way too many ports, some members failed to start because they failed to allocate a port in range {{7500..7550}} (port_range=50).
Need to rethink this...
> Diagnostics: enable TCP by default
> ----------------------------------
>
> Key: JGRP-2436
> URL: https://issues.redhat.com/browse/JGRP-2436
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> Set {{diag_enable_tcp}} to true by default; a lot of deployments happen in the cloud today, and if we don't enable this, {{probe -addr ADDR}} will only return a response from the local member.
> This will open a UDP *and* TCP diagnostics socket, but if {{enable_diagnostics}} is false, then no socket will be opened
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-4967:
-------------------------------------
[~acc_team] I tried to reproduce what you described, but with no luck. The resulting xls file is in attachment. Can you please also attach to this ticket the xls file you used to reproduce this problem?
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4967:
--------------------------------
Attachment: CanDrink2.xls
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4967:
--------------------------------
Sprint: 2020 Week 04-06 (from Jan 20)
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4952) drools-7.31 expert missing/ dropped ProjectClassLoader class?
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4952?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4952.
---------------------------------
Resolution: Explained
That class has been moved in a new module named drools-core-reflective and drools-core depends on it, see https://github.com/kiegroup/drools/blob/master/drools-core/pom.xml#L65
> drools-7.31 expert missing/ dropped ProjectClassLoader class?
> -------------------------------------------------------------
>
> Key: DROOLS-4952
> URL: https://issues.redhat.com/browse/DROOLS-4952
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: John Harrison
> Assignee: Mario Fusco
> Priority: Major
>
> I'm compiling/ running rules using expert (drools-7.31) and java 13.0.1, and getting errors like the following:
> {code:java}
> java.lang.NoClassDefFoundError: org/drools/reflective/classloader/ProjectClassLoader
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:106)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:80)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:64)
> [context - 1447]: at Reason$Descriptor.reason(Reason.java:459)
> [context - 1447]: at Reason.lambda$run$1(Reason.java:82)
> [context - 1447]: at io.javalin.core.security.SecurityUtil.noopAccessManager(SecurityUtil.kt:22)
> [context - 1447]: at io.javalin.http.JavalinServlet$addHandler$protectedHandler$1.handle(JavalinServlet.kt:116)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:45)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:24)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$1.invoke(JavalinServlet.kt:123)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2.invoke(JavalinServlet.kt:40)
> [context - 1447]: at io.javalin.http.JavalinServlet.service(JavalinServlet.kt:75)
> [context - 1447]: at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at io.javalin.core.JavalinServer$start$httpHandler$1.doHandle(JavalinServer.kt:53)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> [context - 1447]: at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
> [context - 1447]: at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:174)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> [context - 1447]: at org.eclipse.jetty.server.Server.handle(Server.java:502)
> [context - 1447]: at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
> [context - 1447]: at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> [context - 1447]: at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> [context - 1447]: at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> [context - 1447]: at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> [context - 1447]: at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> [context - 1447]: at java.base/java.lang.Thread.run(Thread.java:830)
> [context - 1447]: Caused by: java.lang.ClassNotFoundException: org.drools.reflective.classloader.ProjectClassLoader
> [context - 1447]: at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
> [context - 1447]: at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> [context - 1447]: at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> [context - 1447]: ... 42 more
> {code}
> Is this class missing or removed from the distribution? The related release notes don't mention anything, and things work fine in drools-7.30 (class located in drools-core-7.30.0.Final.jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4952) drools-7.31 expert missing/ dropped ProjectClassLoader class?
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4952?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4952:
--------------------------------
Sprint: 2020 Week 04-06 (from Jan 20)
> drools-7.31 expert missing/ dropped ProjectClassLoader class?
> -------------------------------------------------------------
>
> Key: DROOLS-4952
> URL: https://issues.redhat.com/browse/DROOLS-4952
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: John Harrison
> Assignee: Mario Fusco
> Priority: Major
>
> I'm compiling/ running rules using expert (drools-7.31) and java 13.0.1, and getting errors like the following:
> {code:java}
> java.lang.NoClassDefFoundError: org/drools/reflective/classloader/ProjectClassLoader
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:106)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:80)
> [context - 1447]: at org.drools.core.impl.KnowledgeBaseFactory.newKnowledgeBase(KnowledgeBaseFactory.java:64)
> [context - 1447]: at Reason$Descriptor.reason(Reason.java:459)
> [context - 1447]: at Reason.lambda$run$1(Reason.java:82)
> [context - 1447]: at io.javalin.core.security.SecurityUtil.noopAccessManager(SecurityUtil.kt:22)
> [context - 1447]: at io.javalin.http.JavalinServlet$addHandler$protectedHandler$1.handle(JavalinServlet.kt:116)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:45)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2$1.invoke(JavalinServlet.kt:24)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$1.invoke(JavalinServlet.kt:123)
> [context - 1447]: at io.javalin.http.JavalinServlet$service$2.invoke(JavalinServlet.kt:40)
> [context - 1447]: at io.javalin.http.JavalinServlet.service(JavalinServlet.kt:75)
> [context - 1447]: at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> [context - 1447]: at io.javalin.core.JavalinServer$start$httpHandler$1.doHandle(JavalinServer.kt:53)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> [context - 1447]: at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> [context - 1447]: at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> [context - 1447]: at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> [context - 1447]: at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
> [context - 1447]: at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:174)
> [context - 1447]: at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> [context - 1447]: at org.eclipse.jetty.server.Server.handle(Server.java:502)
> [context - 1447]: at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
> [context - 1447]: at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> [context - 1447]: at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> [context - 1447]: at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> [context - 1447]: at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> [context - 1447]: at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> [context - 1447]: at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> [context - 1447]: at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> [context - 1447]: at java.base/java.lang.Thread.run(Thread.java:830)
> [context - 1447]: Caused by: java.lang.ClassNotFoundException: org.drools.reflective.classloader.ProjectClassLoader
> [context - 1447]: at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
> [context - 1447]: at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> [context - 1447]: at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> [context - 1447]: ... 42 more
> {code}
> Is this class missing or removed from the distribution? The related release notes don't mention anything, and things work fine in drools-7.30 (class located in drools-core-7.30.0.Final.jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4979) Support static method invocation in accumulate
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4979?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4979.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/6f194422718daa86a4356ce69fb7267...
> Support static method invocation in accumulate
> ----------------------------------------------
>
> Key: DROOLS-4979
> URL: https://issues.redhat.com/browse/DROOLS-4979
> Project: Drools
> Issue Type: Bug
> Reporter: Luca Molteni
> Assignee: Mario Fusco
> Priority: Major
>
> {code:java}
> @Test
> public void testAccumulateOfDurationBetweenDateTime() {
> final String drl =
> "import java.time.Duration\n" +
> "import " + Interval.class.getCanonicalName() + ";\n" +
> "global java.util.List result; \n" +
> "\n" +
> "rule \"Rule1\"\n" +
> "when\n" +
> " $count : Number() from accumulate(\n" +
> " Interval($start : start, $end : end), " +
> " sum(Duration.between($start, $end).toMinutes()) " +
> " ) " +
> "then\n" +
> " result.add($count);\n" +
> "end\n";
> List<Long> result = new ArrayList<>();
> KieSession ksession = getKieSession(drl);
> ksession.setGlobal("result", result);
> ksession.insert(new Interval(
> LocalDateTime.of(2020, 1, 22, 11, 43),
> LocalDateTime.of(2020, 1, 22, 12, 43)
> ));
> ksession.fireAllRules();
> assertEquals(60, result.iterator().next().longValue());
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13030) Add tests to exclude Galleon layers
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-13030:
-------------------------------------------
Summary: Add tests to exclude Galleon layers
Key: WFLY-13030
URL: https://issues.redhat.com/browse/WFLY-13030
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
datasources layer can be excluded from some integration/basic tests.
jpa layer can be excluded (and replaced by jpa-distributed) when running jpal2c clustering tests.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13029) Clustering jpa2lc tests shouldn't depend on ejb
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-13029:
-------------------------------------------
Summary: Clustering jpa2lc tests shouldn't depend on ejb
Key: WFLY-13029
URL: https://issues.redhat.com/browse/WFLY-13029
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
The dependency on ejb can be replaced by CDI + explicit transaction.
Doing so these 2 tests become testable using galleon layers cloud-server and jps-distributed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-3451) [DMN Designer] Function: Not possible to select _expression_ cell
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-3451?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-3451:
----------------------------------------
[~dadossan] I suspect we should let [~jomarko] have the final test and confirmation to close.
> [DMN Designer] Function: Not possible to select _expression_ cell
> -----------------------------------------------------------------
>
> Key: DROOLS-3451
> URL: https://issues.redhat.com/browse/DROOLS-3451
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: context.gif, function-grid-left-click.png, function-grid-right-click.png
>
>
> It is not possible to select the {{FunctionGrid}} _expression_ cell.
> Left-single-click does not select cell:
> !function-grid-left-click.png|thumbnail!
> Whereas right-single-click does (and shows _context_ menu):
> !function-grid-right-click.png|thumbnail!
> It should be possible to select the cell with single-left-click too.
> h2. Acceptance criteria
> Select function expression cell by
> - Left Single click
> - Right Single click
> - Keyboard navigation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-3451) [DMN Designer] Function: Not possible to select _expression_ cell
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-3451?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-3451:
----------------------------------------
[~dadossan] Yay.. I just tested with {{master}} too and I can confirm the issue is no longer present and hence this JIRA closed.
> [DMN Designer] Function: Not possible to select _expression_ cell
> -----------------------------------------------------------------
>
> Key: DROOLS-3451
> URL: https://issues.redhat.com/browse/DROOLS-3451
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: context.gif, function-grid-left-click.png, function-grid-right-click.png
>
>
> It is not possible to select the {{FunctionGrid}} _expression_ cell.
> Left-single-click does not select cell:
> !function-grid-left-click.png|thumbnail!
> Whereas right-single-click does (and shows _context_ menu):
> !function-grid-right-click.png|thumbnail!
> It should be possible to select the cell with single-left-click too.
> h2. Acceptance criteria
> Select function expression cell by
> - Left Single click
> - Right Single click
> - Keyboard navigation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Brian Stansberry reassigned WFCORE-4820:
----------------------------------------
Component/s: Security
Assignee: Darran Lofthouse (was: Brian Stansberry)
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Darran Lofthouse
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4820:
-------------------------------------
Component/s: Management
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Darran Lofthouse
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13018:
------------------------------------
Fix Version/s: (was: 17.0.1.Final)
> Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ---------------------------------------------------------------
>
> Key: WFLY-13018
> URL: https://issues.redhat.com/browse/WFLY-13018
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 18.0.1.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
>
> Error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
>
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Brian Stansberry moved WFLY-13020 to WFCORE-4820:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4820 (was: WFLY-13020)
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4820:
-------------------------------------
Affects Version/s: 10.0.3.Final
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13020) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Mark Sanchez (Jira)
[ https://issues.redhat.com/browse/WFLY-13020?page=com.atlassian.jira.plugi... ]
Mark Sanchez commented on WFLY-13020:
-------------------------------------
Any status on this?
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-13020
> URL: https://issues.redhat.com/browse/WFLY-13020
> Project: WildFly
> Issue Type: Bug
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-3451) [DMN Designer] Function: Not possible to select _expression_ cell
by Daniel José dos Santos (Jira)
[ https://issues.redhat.com/browse/DROOLS-3451?page=com.atlassian.jira.plug... ]
Daniel José dos Santos commented on DROOLS-3451:
------------------------------------------------
I don't know if I get it, but looks like it's working now. I tested on Firefox and Chrome. As you can see in the gif, when I select I'm left-clicking and when I click with the right button the menu (Clear) is show. Also it's working with keyboard. Can you confirm, please? [~manstis]
!context.gif!
> [DMN Designer] Function: Not possible to select _expression_ cell
> -----------------------------------------------------------------
>
> Key: DROOLS-3451
> URL: https://issues.redhat.com/browse/DROOLS-3451
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: context.gif, function-grid-left-click.png, function-grid-right-click.png
>
>
> It is not possible to select the {{FunctionGrid}} _expression_ cell.
> Left-single-click does not select cell:
> !function-grid-left-click.png|thumbnail!
> Whereas right-single-click does (and shows _context_ menu):
> !function-grid-right-click.png|thumbnail!
> It should be possible to select the cell with single-left-click too.
> h2. Acceptance criteria
> Select function expression cell by
> - Left Single click
> - Right Single click
> - Keyboard navigation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-3451) [DMN Designer] Function: Not possible to select _expression_ cell
by Daniel José dos Santos (Jira)
[ https://issues.redhat.com/browse/DROOLS-3451?page=com.atlassian.jira.plug... ]
Daniel José dos Santos updated DROOLS-3451:
-------------------------------------------
Attachment: context.gif
> [DMN Designer] Function: Not possible to select _expression_ cell
> -----------------------------------------------------------------
>
> Key: DROOLS-3451
> URL: https://issues.redhat.com/browse/DROOLS-3451
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: context.gif, function-grid-left-click.png, function-grid-right-click.png
>
>
> It is not possible to select the {{FunctionGrid}} _expression_ cell.
> Left-single-click does not select cell:
> !function-grid-left-click.png|thumbnail!
> Whereas right-single-click does (and shows _context_ menu):
> !function-grid-right-click.png|thumbnail!
> It should be possible to select the cell with single-left-click too.
> h2. Acceptance criteria
> Select function expression cell by
> - Left Single click
> - Right Single click
> - Keyboard navigation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type properties
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-4698:
-------------------------------
Summary: Adding "expression" type handling for Collection type properties (was: Adding "expression" type handling for Collection type propereties)
> Adding "expression" type handling for Collection type properties
> ----------------------------------------------------------------
>
> Key: DROOLS-4698
> URL: https://issues.redhat.com/browse/DROOLS-4698
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Fix For: 7.33.0.Final
>
> Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn
>
>
> Support is about both drools/java collections and dmn collections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-4973:
-------------------------------
Story Points: 1
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip, screenshot-1.png
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4727) Unclear message when user tries to bind a fact on the Background tab
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4727?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4727:
------------------------------------
[~jomarko] No reproducible in Master: it's not possibile to rename a header cell in Background grid. Can you please double check it?
> Unclear message when user tries to bind a fact on the Background tab
> --------------------------------------------------------------------
>
> Key: DROOLS-4727
> URL: https://issues.redhat.com/browse/DROOLS-4727
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.30.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, drools-tools
> Attachments: bind.webm
>
>
> See the attached video. There is confusing message when user bind a fact on Background tab and tries to continue work with the editor. The current message is like _Can not read GJg undefined property_.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4726) Bound facts from model are available on Background
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4726?page=com.atlassian.jira.plug... ]
Yeser Amer edited comment on DROOLS-4726 at 1/28/20 10:37 AM:
--------------------------------------------------------------
[~jomarko] No more reproducible in Master, can you please confirm?
was (Author: yamer):
[~jomarko] No more reproducible, can you please confirm?
> Bound facts from model are available on Background
> --------------------------------------------------
>
> Key: DROOLS-4726
> URL: https://issues.redhat.com/browse/DROOLS-4726
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.30.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, drools-tools
> Attachments: bound-facts-on-background.webm
>
>
> See the attached video. The bound facts from main model tab are available in the Background tab.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-12948) When shutting down, JDBC_PING tries to use a closed connection
by Aliaksei Makarevich (Jira)
[ https://issues.redhat.com/browse/WFLY-12948?page=com.atlassian.jira.plugi... ]
Aliaksei Makarevich commented on WFLY-12948:
--------------------------------------------
Hello [~rhusar] [~sebastian.laskawiec]
Unfortunatelly this didn't help.
I wrote a comment about it at [KEYCLOAK-11148 JDBC_PING example with Maria DB #204|https://github.com/keycloak/keycloak-containers/pull/204#issuecomment-575152116]
> When shutting down, JDBC_PING tries to use a closed connection
> --------------------------------------------------------------
>
> Key: WFLY-12948
> URL: https://issues.redhat.com/browse/WFLY-12948
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Sebastian Laskawiec
> Assignee: Radoslav Husar
> Priority: Minor
>
> One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory:
> {code}
> keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS
> keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159)
> keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119)
> keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS
> keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> keycloak_2 | ... 20 more
> keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119)
> keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms
> keycloak_2 | *** JBossAS process (510) received TERM signal ***
> {code}
> More information:
> * Generated {{standalone-ha.xml}} used by the example: https://gist.github.com/slaskawi/7cb8eefdfa3e27f7c0f0e62e26bb0216
> * Full logs from Docker Compose: https://gist.github.com/slaskawi/239a2a1ea83d7bc98c8d0d884480c77e
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2436) Diagnostics: enable TCP by default
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2436?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2436:
---------------------------
Description:
Set {{diag_enable_tcp}} to true by default; a lot of deployments happen in the cloud today, and if we don't enable this, {{probe -addr ADDR}} will only return a response from the local member.
This will open a UDP *and* TCP diagnostics socket, but if {{enable_diagnostics}} is false, then no socket will be opened
was:
Set {{diag_enable_tcp}} to true by default; a lot of deployments happen in the cloud today, and if we don't enable this, {{probe -addr ADDR}} will only retturn a response from the local member.
This will open a UDP *and* TCP diagnostics socket, but if {{enable_diagnostics}} is false, then no socket will be opened
> Diagnostics: enable TCP by default
> ----------------------------------
>
> Key: JGRP-2436
> URL: https://issues.redhat.com/browse/JGRP-2436
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> Set {{diag_enable_tcp}} to true by default; a lot of deployments happen in the cloud today, and if we don't enable this, {{probe -addr ADDR}} will only return a response from the local member.
> This will open a UDP *and* TCP diagnostics socket, but if {{enable_diagnostics}} is false, then no socket will be opened
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
[~guillaume.smet] I mean I have tested the code with the reproducer from this Jira and the problem doesn't occur anymore. What is more, I have run WildFly integration testsuite to make sure there are no regressions and the tests are passing.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 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:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4972) Buttons stay disabled when switching to textual collection editor
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ]
Elizabeth Clayton commented on DROOLS-4972:
-------------------------------------------
Sound good [~yamer], I'll try mocking it up first, then circle back with you. Thank you!
> Buttons stay disabled when switching to textual collection editor
> -----------------------------------------------------------------
>
> Key: DROOLS-4972
> URL: https://issues.redhat.com/browse/DROOLS-4972
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Attachments: define-list-and-save.webm
>
>
> If user starts to create list using UI editor, then he decides to switch to textual editor - define list as expression, the buttons are disabled if user didn't canceled items 'in progress' in the UI editor. See the attached video.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4972) Buttons stay disabled when switching to textual collection editor
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4972?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4972:
------------------------------------
Hi [~uxdlc], I'm available to discuss how to improve that link, I propose to have a chat together or to open a dedicated Jira for this, if you already have a proposal in mind. Thanks.
> Buttons stay disabled when switching to textual collection editor
> -----------------------------------------------------------------
>
> Key: DROOLS-4972
> URL: https://issues.redhat.com/browse/DROOLS-4972
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Attachments: define-list-and-save.webm
>
>
> If user starts to create list using UI editor, then he decides to switch to textual editor - define list as expression, the buttons are disabled if user didn't canceled items 'in progress' in the UI editor. See the attached video.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected header cell
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4585?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4585:
------------------------------------
[~jomarko] [~karreiro] I confirm you, items are NOT related.
> Focus doesn't moves after the selected header cell
> --------------------------------------------------
>
> Key: DROOLS-4585
> URL: https://issues.redhat.com/browse/DROOLS-4585
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.28.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Major
> Labels: CustomerFocus, drools-tools
>
> {color:red}*Failure*{color}
> If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body.
> *Expected*
> Viewed part of grid follows the selected cell
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-4973:
----------------------------------------
+1 to [~yamer]'s proposal to use the IN operator for the desired semantic, instead of the equality operator misuse.
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip, screenshot-1.png
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-4973:
-------------------------------
Sprint: 2020 Week 04-06 (from Jan 20)
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip, screenshot-1.png
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13025) Deprecate token=simple and token=digest
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13025:
-----------------------------------
Summary: Deprecate token=simple and token=digest
Key: WFLY-13025
URL: https://issues.redhat.com/browse/WFLY-13025
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 19.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
AuthToken and SimpleToken are removed in JGroups 5.0.0.Alpha1. In preparation, we need to deprecate these resources from WildFly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4976) Guided Decision Table Graphs do not work
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4976?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4976:
--------------------------------
Description:
Users are no longer able to create Guided Decision Table Graphs.
A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
h3. Manual Test
# Open sample Mortgages
# Crete new graph
# Open existing 'Pricing Loans'
# Create new table
# Swithh between them
# Check analysis is synced during sync
was:
Users are no longer able to create Guided Decision Table Graphs.
A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
> Guided Decision Table Graphs do not work
> ----------------------------------------
>
> Key: DROOLS-4976
> URL: https://issues.redhat.com/browse/DROOLS-4976
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.32.0.Final
> Reporter: Michael Anstis
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools
>
> Users are no longer able to create Guided Decision Table Graphs.
> A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
> h3. Manual Test
> # Open sample Mortgages
> # Crete new graph
> # Open existing 'Pricing Loans'
> # Create new table
> # Swithh between them
> # Check analysis is synced during sync
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4976) Guided Decision Table Graphs do not work
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4976?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4976:
--------------------------------
Description:
Users are no longer able to create Guided Decision Table Graphs.
A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
h3. Manual Test (/)
# Open sample Mortgages
# Crete new graph
# Open existing 'Pricing Loans'
# Create new table
# Swithh between them
# Check analysis is synced during sync
was:
Users are no longer able to create Guided Decision Table Graphs.
A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
h3. Manual Test
# Open sample Mortgages
# Crete new graph
# Open existing 'Pricing Loans'
# Create new table
# Swithh between them
# Check analysis is synced during sync
> Guided Decision Table Graphs do not work
> ----------------------------------------
>
> Key: DROOLS-4976
> URL: https://issues.redhat.com/browse/DROOLS-4976
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.32.0.Final
> Reporter: Michael Anstis
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools
>
> Users are no longer able to create Guided Decision Table Graphs.
> A {{Parameter named 'analysisReportScreen' should be not null!}} error is thrown when trying to "open" an existing Guided Decision Table to the graph.
> h3. Manual Test (/)
> # Open sample Mortgages
> # Crete new graph
> # Open existing 'Pricing Loans'
> # Create new table
> # Swithh between them
> # Check analysis is synced during sync
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13024) Integrate MP Fault Tolerance 2.1
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13024?page=com.atlassian.jira.plugi... ]
Radoslav Husar moved EAP7-1430 to WFLY-13024:
---------------------------------------------
Project: WildFly (was: JBoss EAP Planning for version 7 and above)
Key: WFLY-13024 (was: EAP7-1430)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: (was: MicroProfile)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.4.0.GA)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Integrate MP Fault Tolerance 2.1
> --------------------------------
>
> Key: WFLY-13024
> URL: https://issues.redhat.com/browse/WFLY-13024
> Project: WildFly
> Issue Type: Feature Request
> Affects Versions: 19.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4985) A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4985?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4985:
--------------------------------
Affects Version/s: 7.32.0.Final
> A Spreadsheet decision tables does not convert to a DRL file correctly when a Function is being used in the RuleTable constraints
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4985
> URL: https://issues.redhat.com/browse/DROOLS-4985
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, XLS Score Card Editor
> Affects Versions: 7.32.0.Final
> Reporter: Oscar Molina
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools, support
>
> The attached "test_functions.xlsx" spreadsheet which is being used for creating a “Spreadsheet decision tables” asset. This spreadsheet contains a “Function” and has some rules. These rules use the “Function” in the constraints. When this XLSX Decision Table is converted to a “Guided Decision Table”, the constraints are missing the “Function” calls. Surprisingly if the “Function” call is used in a System.out.println statement, the generated DRL correctly contains it.
> A wrongly generated DRL rule
> {code}
> rule "Row 3 Hello RuleTable"
> dialect "mvel"
> when
> $person : Person( gender == "Female" , married == true )
> then
> $person.setHelloMsg( "Miss" );
> System.out.println(hello($person.getName(), "Miss", "how are you doing"));
> end
> {code}
> Expected correct DRL rule
> {code}
> rule "Row 3 Hello RuleTable DRL"
> dialect "mvel"
> when
> $person : Person( gender == "Female" , married == true )
> then
> $person.setHelloMsg( hello($person.getName(), "Miss", "how are you doing") );
> System.out.println(hello($person.getName(), "Miss", "how are you doing"));
> end
> {code}
> Regards,
> Oscar.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Yeser Amer reassigned DROOLS-4973:
----------------------------------
Assignee: Yeser Amer (was: Daniele Zonca)
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip, screenshot-1.png
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4973:
------------------------------------
Thank you [~tari_manga].
[~jomarko] Considering the behavior is part of FEEL language requirement, I think we can say this is not a bug.
I created a PR for this ticket adding test case to map this behavior as expected.
Please note, you can use IN operator in FEEL to check if one or more elements are present in the list without using the = operator.
Thanks.
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Daniele Zonca
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip, screenshot-1.png
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2442) Performance tests
by Bela Ban (Jira)
Bela Ban created JGRP-2442:
------------------------------
Summary: Performance tests
Key: JGRP-2442
URL: https://issues.redhat.com/browse/JGRP-2442
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0
Run UPerf/MPerf before releasing 5.0.0.Final.
Performance should be slightly better due to reduced memory pressure (LongMessage, EmptyMessage, one less memory allocation)...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-12927) wildfly 8.2 huge memory allocation during and after deployement
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-12927?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski resolved WFLY-12927.
---------------------------------------
Resolution: Out of Date
> wildfly 8.2 huge memory allocation during and after deployement
> ---------------------------------------------------------------
>
> Key: WFLY-12927
> URL: https://issues.redhat.com/browse/WFLY-12927
> Project: WildFly
> Issue Type: Bug
> Reporter: sandev sandev
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: threads.png
>
>
> I am using wildfly 8.2.1 final to deploy java ee 7 maven web application wars about 30 war with dependence between them using rmi remote ejb. I found that the server consumes a lot of memory special on startup of the server to 8 g my java opt are -xms 8g -xmx 8g -metaspacesize 1g .so I use java "visualvm" to understand what is happening. I found that the most consumed memory is for 2 types of threads at deploy: MSC service thread and after deploy finish: DeployementScanner-threads in additional that no user use the server or the deployed application this server was just for test
> my question is why wildfly starts with about 3g and after some time the memory growth to ~= 8g without any action on the server its idle any help to solve this problem please
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reopened WFLY-13018:
-------------------------------------
> Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ---------------------------------------------------------------
>
> Key: WFLY-13018
> URL: https://issues.redhat.com/browse/WFLY-13018
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 18.0.1.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.1.Final
>
>
> Error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
>
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFLY-13018.
-------------------------------------
Resolution: Rejected
> Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ---------------------------------------------------------------
>
> Key: WFLY-13018
> URL: https://issues.redhat.com/browse/WFLY-13018
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 18.0.1.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.1.Final
>
>
> Error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
>
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13022) Upgrade MicroProfile Metrics 2.3
by Jeff Mesnil (Jira)
Jeff Mesnil created WFLY-13022:
----------------------------------
Summary: Upgrade MicroProfile Metrics 2.3
Key: WFLY-13022
URL: https://issues.redhat.com/browse/WFLY-13022
Project: WildFly
Issue Type: Component Upgrade
Components: MP Metrics
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
This also includes upgrade of smallrye-metrics that implements MP Metrics 2.3
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-1860) Custom classloader in RpcDispatcher
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1860?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-1860:
--------------------------------
OK, we'll take it from there. Note that we switched to Google Groups as mailing list: \[1\]
\[1\] https://groups.google.com/forum/#!forum/jgroups-dev
> Custom classloader in RpcDispatcher
> -----------------------------------
>
> Key: JGRP-1860
> URL: https://issues.redhat.com/browse/JGRP-1860
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.4.5, 3.5
>
>
> RpcDispatcher is hard-coded to use JGroups' classloader when marshalling the users's custom objects over RPC.
> RpcDispatcher uses Util.objectFromByteBuffer to unmarshall, which uses an ObjectInputStream. ObjectInputStream uses the classloader of its caller's class (Util).
> RpcDispatcher does allow a custom marshaller to be used (implementing RpcDispatcher.Marshaller), but since Util.objectFromByteBuffer hard-codes the use of ObjectInputStream, a custom marshaller cannot simply set the classloader and then delegate back to the default JGroups code.
> Util.objectFromBuffer should be enhanced to use a custom ObjectInputStream implementation that overrides resolveClass to use a custom classloader, and an API should be added to RpcDispatcher to pass in the classloader to use.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-12822) Undertow Deadlock
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/WFLY-12822?page=com.atlassian.jira.plugi... ]
Flavia Rainone commented on WFLY-12822:
---------------------------------------
Clearly, the fix is not correct. I created a PR for this one https://github.com/undertow-io/undertow/pull/851 but, since [~ropalka] already started investigating, I'm checking with him what would be the best way to fix this deadlock before committing with a final solution.
> Undertow Deadlock
> -----------------
>
> Key: WFLY-12822
> URL: https://issues.redhat.com/browse/WFLY-12822
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Flavia Rainone
> Priority: Critical
> Labels: downstream_dependency
>
> Testsuite hang:
> https://ci.wildfly.org/viewLog.html?buildId=175908&buildTypeId=WF_PullReq...
> {code}
> 2019-11-22 19:51:16
> Full thread dump Java HotSpot(TM) Server VM (25.152-b16 mixed mode):
> "Attach Listener" #223 daemon prio=9 os_prio=0 tid=0xc0af2400 nid=0x40bf waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "ServerService Thread Pool -- 78" #191 prio=5 os_prio=0 tid=0xb8678800 nid=0xb78 waiting on condition [0xbacba000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc714cdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "pool-13-thread-1" #162 prio=5 os_prio=0 tid=0xbdad1800 nid=0x8a1 waiting on condition [0xbad0b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe2479960> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "ServerService Thread Pool -- 77" #153 prio=5 os_prio=0 tid=0xc4de7400 nid=0x896 waiting on condition [0xbac69000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc714cdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "default task-2" #142 prio=5 os_prio=0 tid=0xc6848800 nid=0x872 waiting on condition [0xbac18000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc89b31d8> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "default task-1" #141 prio=5 os_prio=0 tid=0xbc8f1400 nid=0x871 waiting for monitor entry [0xbaa25000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.markWritesBroken(AbstractFramedChannel.java:883)
> - waiting to lock <0xe26b4980> (a io.undertow.protocols.http2.Http2Channel)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.channelForciblyClosed(AbstractFramedStreamSinkChannel.java:562)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:539)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:728)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:257)
> - locked <0xe26ef4b8> (a java.lang.Object)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:240)
> - locked <0xe26ef4b8> (a java.lang.Object)
> at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:822)
> at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:809)
> at io.undertow.protocols.http2.Http2Channel.removeStreamSink(Http2Channel.java:968)
> at io.undertow.protocols.http2.Http2StreamSinkChannel.channelForciblyClosed(Http2StreamSinkChannel.java:68)
> at io.undertow.protocols.http2.Http2DataStreamSinkChannel.channelForciblyClosed(Http2DataStreamSinkChannel.java:322)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:539)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:728)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:257)
> - locked <0xe26b71b0> (a java.lang.Object)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:240)
> - locked <0xe26b71b0> (a java.lang.Object)
> at org.xnio.conduits.StreamSinkChannelWrappingConduit.terminateWrites(StreamSinkChannelWrappingConduit.java:75)
> at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178)
> at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79)
> at io.undertow.io.UndertowOutputStream.close(UndertowOutputStream.java:347)
> at io.undertow.io.UndertowOutputStream.updateWritten(UndertowOutputStream.java:266)
> at io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:209)
> at io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:105)
> at io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:131)
> at io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:166)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler$1.handleDefaultResponse(SimpleErrorPageHandler.java:68)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1608)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:401)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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(Thread.java:748)
> "expiration-thread--p3-t1" #131 daemon prio=1 os_prio=0 tid=0xbd8b2400 nid=0x863 waiting on condition [0xbaead000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe21794d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.jboss.as.clustering.context.ContextReferenceExecutor.execute(ContextReferenceExecutor.java:49)
> at org.jboss.as.clustering.context.ContextualExecutor$1.run(ContextualExecutor.java:70)
> at java.lang.Thread.run(Thread.java:748)
> "Reference Reaper #3" #129 daemon prio=5 os_prio=0 tid=0xc1bee400 nid=0x85e in Object.wait() [0xbbead000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> - locked <0xe24ac228> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> at org.wildfly.common.ref.References$ReaperThread.run(References.java:76)
> "Reference Reaper #2" #128 daemon prio=5 os_prio=0 tid=0xc012e400 nid=0x85d in Object.wait() [0xbbefe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> - locked <0xe24ac228> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> at org.wildfly.common.ref.References$ReaperThread.run(References.java:76)
> "Reference Reaper #1" #127 daemon prio=5 os_prio=0 tid=0xc012d000 nid=0x85c in Object.wait() [0xbc05b000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> - locked <0xe24ac228> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> at org.wildfly.common.ref.References$ReaperThread.run(References.java:76)
> "management task-2" #125 prio=5 os_prio=0 tid=0xbdcde400 nid=0x83e waiting on condition [0xbc0fd000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8a77ca0> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "management task-1" #124 prio=5 os_prio=0 tid=0xbbf30800 nid=0x83d waiting on condition [0xbc35c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8a77ca0> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "pool-8-thread-1" #123 prio=5 os_prio=0 tid=0xbbf2e800 nid=0x83c waiting on condition [0xbc3ad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc898fc98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "DeploymentScanner-threads - 2" #121 prio=5 os_prio=0 tid=0xc3f5a000 nid=0x83a waiting on condition [0xbcaba000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8a64f80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "Transaction Reaper Worker 0" #120 daemon prio=5 os_prio=0 tid=0xbff57400 nid=0x839 in Object.wait() [0xbcb0b000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:328)
> - locked <0xe2258890> (a java.util.LinkedList)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65)
> "Transaction Reaper" #119 daemon prio=5 os_prio=0 tid=0xbd84a800 nid=0x837 in Object.wait() [0xbcb5c000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90)
> - locked <0xe22586c0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> "Periodic Recovery" #115 prio=5 os_prio=0 tid=0xbdfe1c00 nid=0x836 in Object.wait() [0xbcbad000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doPeriodicWait(PeriodicRecovery.java:683)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:403)
> - locked <0xe227f4b8> (a java.lang.Object)
> "Transaction Expired Entry Monitor" #118 daemon prio=5 os_prio=0 tid=0xbdfe0800 nid=0x835 in Object.wait() [0xbcbfe000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe226f588> (a com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor)
> at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:190)
> - locked <0xe226f588> (a com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor)
> "XNIO-1 Accept" #117 daemon prio=5 os_prio=0 tid=0xc4261400 nid=0x833 runnable [0xbce6c000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xe21df9e0> (a sun.nio.ch.Util$3)
> - locked <0xe21df9d0> (a java.util.Collections$UnmodifiableSet)
> - locked <0xe21df8d8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "XNIO-1 I/O-1" #116 daemon prio=5 os_prio=0 tid=0xc4260400 nid=0x832 runnable [0xbcffc000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xe21df3a0> (a sun.nio.ch.Util$3)
> - locked <0xe21df390> (a java.util.Collections$UnmodifiableSet)
> - locked <0xe21df298> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "Timer-1" #114 prio=5 os_prio=0 tid=0xbe20c400 nid=0x82f in Object.wait() [0xbd67a000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xc8d8bf48> (a java.util.TaskQueue)
> at java.lang.Object.wait(Object.java:502)
> at java.util.TimerThread.mainLoop(Timer.java:526)
> - locked <0xc8d8bf48> (a java.util.TaskQueue)
> at java.util.TimerThread.run(Timer.java:505)
> "default Accept" #113 prio=5 os_prio=0 tid=0xbe023400 nid=0x82e runnable [0xbdb5c000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8dabc58> (a sun.nio.ch.Util$3)
> - locked <0xc8dabc48> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8dabb50> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-8" #112 prio=5 os_prio=0 tid=0xbe022000 nid=0x82d runnable [0xbdbad000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8dae2b0> (a sun.nio.ch.Util$3)
> - locked <0xc8dae2a0> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8dae1a8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-7" #111 prio=5 os_prio=0 tid=0xbe020800 nid=0x82c runnable [0xbdbfe000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8dae8f8> (a sun.nio.ch.Util$3)
> - locked <0xc8dae8e8> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8dae7f0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:551)
> "default I/O-6" #110 prio=5 os_prio=0 tid=0xbe01f000 nid=0x82b runnable [0xbdd69000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8db6f50> (a sun.nio.ch.Util$3)
> - locked <0xc8db6f40> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8db6e48> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:551)
> "default I/O-5" #109 prio=5 os_prio=0 tid=0xbe01c400 nid=0x82a runnable [0xbddba000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8db95a8> (a sun.nio.ch.Util$3)
> - locked <0xc8db9598> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8db94a0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-4" #108 prio=5 os_prio=0 tid=0xbe01b000 nid=0x829 runnable [0xbde0b000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8db9bf0> (a sun.nio.ch.Util$3)
> - locked <0xc8db9be0> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8db9ae8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-3" #107 prio=5 os_prio=0 tid=0xbea2b800 nid=0x828 runnable [0xbde5c000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8dba238> (a sun.nio.ch.Util$3)
> - locked <0xc8dba228> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8dba130> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-2" #106 prio=5 os_prio=0 tid=0xbe019800 nid=0x827 runnable [0xbdead000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8dba880> (a sun.nio.ch.Util$3)
> - locked <0xc8dba870> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8dba778> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "default I/O-1" #105 prio=5 os_prio=0 tid=0xbea25400 nid=0x826 waiting for monitor entry [0xbdefe000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:525)
> - waiting to lock <0xe26b71b0> (a java.lang.Object)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.protocols.http2.Http2Channel.closeSubChannels(Http2Channel.java:645)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.close(AbstractFramedChannel.java:824)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.protocols.http2.Http2Channel.lastDataRead(Http2Channel.java:593)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:391)
> - locked <0xe26b4980> (a io.undertow.protocols.http2.Http2Channel)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:118)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:67)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:950)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:931)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> "IdleRemover" #104 daemon prio=5 os_prio=0 tid=0xc0286c00 nid=0x825 waiting on condition [0xbe39d000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dc9790> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:261)
> 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)
> "ConnectionValidator" #103 daemon prio=5 os_prio=0 tid=0xbf9f8800 nid=0x824 waiting on condition [0xbe3ee000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dc9d78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:263)
> 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)
> "Timer-0" #102 prio=5 os_prio=0 tid=0xc01a0400 nid=0x823 in Object.wait() [0xbe53f000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xc8a73050> (a java.util.TaskQueue)
> at java.lang.Object.wait(Object.java:502)
> at java.util.TimerThread.mainLoop(Timer.java:526)
> - locked <0xc8a73050> (a java.util.TaskQueue)
> at java.util.TimerThread.run(Timer.java:505)
> "management Accept" #92 prio=5 os_prio=0 tid=0xc2b20800 nid=0x820 runnable [0xbe632000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8a7f0b0> (a sun.nio.ch.Util$3)
> - locked <0xc8a7f0a0> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8a7efa8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:532)
> "management I/O-2" #90 prio=5 os_prio=0 tid=0xc2b1f000 nid=0x81f runnable [0xbe683000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8a7c400> (a sun.nio.ch.Util$3)
> - locked <0xc8a7c3f0> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8a7c2f8> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:551)
> "management I/O-1" #80 prio=5 os_prio=0 tid=0xc2b1bc00 nid=0x81e runnable [0xbe6d4000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc8a7ea60> (a sun.nio.ch.Util$3)
> - locked <0xc8a7ea50> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc8a7e958> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:551)
> "ServerService Thread Pool -- 40" #63 prio=5 os_prio=0 tid=0xc0395000 nid=0x7fb waiting on condition [0xbf4c7000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc714cdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "DeploymentScanner-threads - 1" #61 prio=5 os_prio=0 tid=0xbfb52400 nid=0x7f5 waiting on condition [0xbf569000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8a64f80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "ServerService Thread Pool -- 9" #31 prio=5 os_prio=0 tid=0x0878e000 nid=0x7d3 waiting on condition [0xc18fd000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8a3a0d8> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> "ServerService Thread Pool -- 1" #23 prio=5 os_prio=0 tid=0xc2e37400 nid=0x7ca waiting on condition [0xc2aad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc714cdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> 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:485)
> "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0xf6508800 nid=0x7af waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "MSC service thread 1-8" #20 prio=5 os_prio=0 tid=0xc2103800 nid=0x7c8 waiting on condition [0xc2afe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-7" #19 prio=5 os_prio=0 tid=0xc2102000 nid=0x7c7 waiting on condition [0xc2c5c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-6" #18 prio=5 os_prio=0 tid=0xc2101000 nid=0x7c6 waiting on condition [0xc2cad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-5" #17 prio=5 os_prio=0 tid=0xc4d3ec00 nid=0x7c5 waiting on condition [0xc29af000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-4" #16 prio=5 os_prio=0 tid=0xc4d3d400 nid=0x7c4 waiting on condition [0xc2a00000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-3" #15 prio=5 os_prio=0 tid=0xc4d2e000 nid=0x7c3 waiting on condition [0xc2a51000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-2" #14 prio=5 os_prio=0 tid=0xc2d48800 nid=0x7c2 waiting on condition [0xc2cfe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-1" #13 prio=5 os_prio=0 tid=0xc2d46800 nid=0x7c1 waiting on condition [0xc3d7f000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc8dca228> (a org.jboss.threads.EnhancedQueueExecutor)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1409)
> at java.lang.Thread.run(Thread.java:748)
> "Reference Reaper" #9 daemon prio=5 os_prio=0 tid=0xc465b800 nid=0x7bd in Object.wait() [0xc45fe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xc7d105d8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> - locked <0xc7d105d8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> at org.jboss.modules.ref.References$ReaperThread.run(References.java:64)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0xc4eab400 nid=0x7bb runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xc4ea8000 nid=0x7ba waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xc4ea6800 nid=0x7b9 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xc4ea4c00 nid=0x7b8 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xc4ea3000 nid=0x7b7 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0xc4e89000 nid=0x7b6 in Object.wait() [0xc697d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> - locked <0xc7360118> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xc4e86000 nid=0x7b5 in Object.wait() [0xc6c7d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> - locked <0xc704c810> (a java.lang.ref.Reference$Lock)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "VM Thread" os_prio=0 tid=0xc4e81800 nid=0x7b4 runnable
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6512000 nid=0x7b0 runnable
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6513400 nid=0x7b1 runnable
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6514800 nid=0x7b2 runnable
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6515c00 nid=0x7b3 runnable
> "VM Periodic Task Thread" os_prio=0 tid=0xc4eaf400 nid=0x7bc waiting on condition
> JNI global references: 1879
> Found one Java-level deadlock:
> =============================
> "default task-1":
> waiting to lock monitor 0xc3cba830 (object 0xe26b4980, a io.undertow.protocols.http2.Http2Channel),
> which is held by "default I/O-1"
> "default I/O-1":
> waiting to lock monitor 0xc3cba89c (object 0xe26b71b0, a java.lang.Object),
> which is held by "default task-1"
> Java stack information for the threads listed above:
> ===================================================
> "default task-1":
> at io.undertow.server.protocol.framed.AbstractFramedChannel.markWritesBroken(AbstractFramedChannel.java:883)
> - waiting to lock <0xe26b4980> (a io.undertow.protocols.http2.Http2Channel)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.channelForciblyClosed(AbstractFramedStreamSinkChannel.java:562)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:539)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:728)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:257)
> - locked <0xe26ef4b8> (a java.lang.Object)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:240)
> - locked <0xe26ef4b8> (a java.lang.Object)
> at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:822)
> at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:809)
> at io.undertow.protocols.http2.Http2Channel.removeStreamSink(Http2Channel.java:968)
> at io.undertow.protocols.http2.Http2StreamSinkChannel.channelForciblyClosed(Http2StreamSinkChannel.java:68)
> at io.undertow.protocols.http2.Http2DataStreamSinkChannel.channelForciblyClosed(Http2DataStreamSinkChannel.java:322)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:539)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:728)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:257)
> - locked <0xe26b71b0> (a java.lang.Object)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:240)
> - locked <0xe26b71b0> (a java.lang.Object)
> at org.xnio.conduits.StreamSinkChannelWrappingConduit.terminateWrites(StreamSinkChannelWrappingConduit.java:75)
> at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178)
> at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79)
> at io.undertow.io.UndertowOutputStream.close(UndertowOutputStream.java:347)
> at io.undertow.io.UndertowOutputStream.updateWritten(UndertowOutputStream.java:266)
> at io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:209)
> at io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:105)
> at io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:131)
> at io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:166)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler$1.handleDefaultResponse(SimpleErrorPageHandler.java:68)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1608)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:401)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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(Thread.java:748)
> "default I/O-1":
> at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.close(AbstractFramedStreamSinkChannel.java:525)
> - waiting to lock <0xe26b71b0> (a java.lang.Object)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.protocols.http2.Http2Channel.closeSubChannels(Http2Channel.java:645)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.close(AbstractFramedChannel.java:824)
> at org.xnio.IoUtils.safeClose(IoUtils.java:152)
> at io.undertow.protocols.http2.Http2Channel.lastDataRead(Http2Channel.java:593)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:391)
> - locked <0xe26b4980> (a io.undertow.protocols.http2.Http2Channel)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:118)
> at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:67)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:950)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:931)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Found 1 deadlock.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-4956:
-------------------------------------------
Also note that if you have 2 rules
{code:java}
Person( "Toshiya" == name )
{code}
{code:java}
Person( name == "Toshiya")
{code}
, node sharing doesn't work for them.
> Normarize rule constraints for property reactivity and indexing
> ---------------------------------------------------------------
>
> Key: DROOLS-4956
> URL: https://issues.redhat.com/browse/DROOLS-4956
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.31.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Having a constraint like
> {code:java}
> Person(name == $customer)
> {code}
> is not really the same thing as
> {code:java}
> Person($customer == name)
> {code}
> In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13020) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Mark Sanchez (Jira)
[ https://issues.redhat.com/browse/WFLY-13020?page=com.atlassian.jira.plugi... ]
Mark Sanchez updated WFLY-13020:
--------------------------------
Description:
error:
WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
We get an error with the following ldap configuration. This works for version 17.
<security-realm name="ldap_security_realm">
<server-identities>
<ssl>
<engine enabled-protocols="TLSv1.2"/>
<keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
</ssl>
</server-identities>
<authentication>
<ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
<username-filter attribute="samaccountname"/>
</ldap>
</authentication>
</security-realm>
</security-realms>
<outbound-connections>
<ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
</outbound-connections>
<management-interfaces>
<http-interface security-realm="ldap_security_realm">
<http-upgrade enabled="true"/>
<socket interface="management" port="${jboss.management.http.port:9990}"/>
</http-interface>
</management-interfaces>
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFLY-13020
> URL: https://issues.redhat.com/browse/WFLY-13020
> Project: WildFly
> Issue Type: Bug
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Mark Sanchez (Jira)
[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ]
Mark Sanchez commented on WFLY-13018:
-------------------------------------
I accidently opened the same issue multiple times.
> Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ---------------------------------------------------------------
>
> Key: WFLY-13018
> URL: https://issues.redhat.com/browse/WFLY-13018
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 18.0.1.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.1.Final
>
>
> Error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
>
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13018) Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13018?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13018:
-----------------------------------------
[~ms2836a] Please clarify what your intent was with this one. It is now resolved as "Done" in 17.0.1.Final which implies something was wrong at some point before that release but got corrected in that release.
> Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ---------------------------------------------------------------
>
> Key: WFLY-13018
> URL: https://issues.redhat.com/browse/WFLY-13018
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 18.0.1.Final
> Reporter: Mark Sanchez
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.1.Final
>
>
> Error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
>
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months