[JBoss JIRA] (DROOLS-3022) [DMN Designer] Data Types - Validations - Validate the uniqueness and the presence of a Data Type name
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3022?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3022:
--------------------------------
Description:
The Data Type name must be unique at the level that it's defined; e.g.
- tPerson
-- uuid
-- name
-- city (Structure)
--- uuid
--- name
The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels.
----
Prototype:
!validation.png|thumbnail!
h2. Manaul Acceptance Test
- Try to put same name by Typing
- Try to put same name by Copy and paste
- Do not allow empty name
- Allow spaces in name
- Allow multibyte chars in name
- Allow special characters in name (?)
- Allow lower upper case in name
- Save when error shown
- Cancel edit when error shown (x)
- Invoke other edit when error shown
was:
The Data Type name must be unique at the level that it's defined; e.g.
- tPerson
-- uuid
-- name
-- city (Structure)
--- uuid
--- name
The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels.
----
Prototype:
!validation.png|thumbnail!
h2. Manaul Acceptance Test
- Try to put same name by Typing
- Try to put same name by Copy and paste
- Do not allow empty name
- Allow spaces in name
- Allow multibyte chars in name
- Allow special characters in name (?)
- Allow lower upper case in name
> [DMN Designer] Data Types - Validations - Validate the uniqueness and the presence of a Data Type name
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3022
> URL: https://issues.jboss.org/browse/DROOLS-3022
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
> Attachments: validation.png
>
>
> The Data Type name must be unique at the level that it's defined; e.g.
> - tPerson
> -- uuid
> -- name
> -- city (Structure)
> --- uuid
> --- name
> The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels.
> ----
> Prototype:
> !validation.png|thumbnail!
> h2. Manaul Acceptance Test
> - Try to put same name by Typing
> - Try to put same name by Copy and paste
> - Do not allow empty name
> - Allow spaces in name
> - Allow multibyte chars in name
> - Allow special characters in name (?)
> - Allow lower upper case in name
> - Save when error shown
> - Cancel edit when error shown (x)
> - Invoke other edit when error shown
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFLY-11089:
------------------------------------------
The issue is in the renegociation that is failing with the buffer being discarded. [~swd847] has provided a fix for undertow.
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Major
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2985) Jenkins PR build of optaweb-employee-rostering should not build kie-server too
by Marek Novotny (Jira)
[ https://issues.jboss.org/browse/DROOLS-2985?page=com.atlassian.jira.plugi... ]
Marek Novotny commented on DROOLS-2985:
---------------------------------------
I looked at the PR config and if you mean that build of everything before the PR build, that is honestly required as we uses SNAPSHOTS over the all kiegroup repos.
https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/master/j...
We could removed that, but that could impact our whole building environment as existing SNAPSHOTs can be out of sync, but generally it is true we can reduce the PR build time.
> Jenkins PR build of optaweb-employee-rostering should not build kie-server too
> ------------------------------------------------------------------------------
>
> Key: DROOLS-2985
> URL: https://issues.jboss.org/browse/DROOLS-2985
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Marek Novotny
> Priority: Blocker
>
> When building this PR:
> https://github.com/kiegroup/optaweb-employee-rostering/pull/187
> It gave this error:
> {code}
> 13:44:42 [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> 13:44:42 @
> 13:44:42 [ERROR] The build could not read 1 project -> [Help 1]
> 13:44:42 org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> {code}
> but optaweb-employee-rostering doesn't rely on droolsjbpm-integration, so building that repo too is just delaying our ability to merge fast, as well as introducing false negatives.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2985) Jenkins PR build of optaweb-employee-rostering should not build kie-server too
by Marek Novotny (Jira)
[ https://issues.jboss.org/browse/DROOLS-2985?page=com.atlassian.jira.plugi... ]
Marek Novotny commented on DROOLS-2985:
---------------------------------------
[~ge0ffrey] Where is the evidence of that PR build job, please?
I agree with you it shouldn't be triggered as the repository is at the end of the repositories chain, but as I looked at the PR linked here it disappeared so where are you seeing that now?
[~mbiarnes] should look at that.
> Jenkins PR build of optaweb-employee-rostering should not build kie-server too
> ------------------------------------------------------------------------------
>
> Key: DROOLS-2985
> URL: https://issues.jboss.org/browse/DROOLS-2985
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Marek Novotny
> Priority: Blocker
>
> When building this PR:
> https://github.com/kiegroup/optaweb-employee-rostering/pull/187
> It gave this error:
> {code}
> 13:44:42 [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> 13:44:42 @
> 13:44:42 [ERROR] The build could not read 1 project -> [Help 1]
> 13:44:42 org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> {code}
> but optaweb-employee-rostering doesn't rely on droolsjbpm-integration, so building that repo too is just delaying our ability to merge fast, as well as introducing false negatives.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11084) inter-app quickstart does not deploy (WildFly 14.0.1)
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11084?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFLY-11084:
--------------------------------------
Description:
Using Wildfly 14.0.1.Final
When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
@ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
@ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
To reproduce, from the inter-app quickstart:
mvn install wildfly:deploy
Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
{noformat}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
"WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
}
09:56:51,014 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
{
"WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
}
{noformat}
was:
Using Wildfly 14.0.1.Final
When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
@ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
@ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
To reproduce, from the inter-app quickstart:
mvn install wildfly:deploy
Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
> inter-app quickstart does not deploy (WildFly 14.0.1)
> -----------------------------------------------------
>
> Key: WFLY-11084
> URL: https://issues.jboss.org/browse/WFLY-11084
> Project: WildFly
> Issue Type: Bug
> Reporter: Kevin Eagles
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> Using Wildfly 14.0.1.Final
> When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
> Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
> To reproduce, from the inter-app quickstart:
> mvn install wildfly:deploy
> Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> 09:56:51,014 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
> {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFLY-11089 at 10/3/18 3:58 AM:
--------------------------------------------------------------
Removing truststore from security relam mean 2-way TLS is changed to 1-way TLS. Your Elytron configuration is also 1-way TLS.
Keywords "2-way TLS" and "large size" reminds me WFLY-11007. Especially see https://issues.jboss.org/browse/WFLY-11007?focusedCommentId=13633363&page...
I think it is worth to use -Djavax.net.debug=all system property if it reveals something suspicious in TLS communication.
was (Author: mchoma):
Removing truststore from security relam mean 2-way TLS is changed to 1-way TLS. Your Elytron configuration is also 1-way TLS.
Keywords "2-way TLS" and "large size" reminds me WFLY-11007. Especially see https://issues.jboss.org/browse/WFLY-11007?focusedCommentId=13633363&page...
I think it is worth to use -Djavax.net.debug=all system property if it reveals something suspicious in TLS handshake.
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Major
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2985) Jenkins PR build of optaweb-employee-rostering should not build kie-server too
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-2985?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet reopened DROOLS-2985:
--------------------------------------
> Jenkins PR build of optaweb-employee-rostering should not build kie-server too
> ------------------------------------------------------------------------------
>
> Key: DROOLS-2985
> URL: https://issues.jboss.org/browse/DROOLS-2985
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Marek Novotny
> Priority: Blocker
>
> When building this PR:
> https://github.com/kiegroup/optaweb-employee-rostering/pull/187
> It gave this error:
> {code}
> 13:44:42 [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> 13:44:42 @
> 13:44:42 [ERROR] The build could not read 1 project -> [Help 1]
> 13:44:42 org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> {code}
> but optaweb-employee-rostering doesn't rely on droolsjbpm-integration, so building that repo too is just delaying our ability to merge fast, as well as introducing false negatives.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFLY-11089:
-------------------------------------
Removing truststore from security relam mean 2-way TLS is changed to 1-way TLS. Your Elytron configuration is also 1-way TLS.
Keywords "2-way TLS" and "large size" reminds me WFLY-11007. Especially see https://issues.jboss.org/browse/WFLY-11007?focusedCommentId=13633363&page...
I think it is worth to use -Djavax.net.debug=all system property if it reveals something suspicious in TLS handshake.
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Major
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-2985) Jenkins PR build of optaweb-employee-rostering should not build kie-server too
by Geoffrey De Smet (Jira)
[ https://issues.jboss.org/browse/DROOLS-2985?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-2985:
------------------------------------------
[~manaRH] [~mbiarnes] I am reopening this issue because the optaweb-employee-rostering PR build is still building kie-server:
This issue isn't about the build failure - it's about:
- the loss of time to merge a PR
- and the false negatives that happen on PR's.
> Jenkins PR build of optaweb-employee-rostering should not build kie-server too
> ------------------------------------------------------------------------------
>
> Key: DROOLS-2985
> URL: https://issues.jboss.org/browse/DROOLS-2985
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Marek Novotny
> Priority: Blocker
>
> When building this PR:
> https://github.com/kiegroup/optaweb-employee-rostering/pull/187
> It gave this error:
> {code}
> 13:44:42 [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> 13:44:42 @
> 13:44:42 [ERROR] The build could not read 1 project -> [Help 1]
> 13:44:42 org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
> 13:44:42 [ERROR] 'dependencies.dependency.version' for org.jboss.narayana.tomcat:tomcat-jta:jar is missing. @ org.kie.server:kie-server:[unknown-version], /home/jenkins/workspace/KIE/master/pullrequest/optaweb-employee-rostering-pullrequests/upstream-repos/droolsjbpm-integration/kie-server-parent/kie-server-wars/kie-server/pom.xml, line 264, column 17
> {code}
> but optaweb-employee-rostering doesn't rely on droolsjbpm-integration, so building that repo too is just delaying our ability to merge fast, as well as introducing false negatives.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10531) Wildfly leaks ActiveMQ connections
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-10531?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek commented on WFLY-10531:
--------------------------------------
[~jwgmeligmeyling] Hi, I'm also wondering why is it happening at first place.
But I have manually tested this new patch with both reproducers (from [~gunterze] and older reproducer for https://issues.jboss.org/browse/WFLY-9501) Both were working successfully.
Her are some "well known" facts:
* If close is executed in PreDestroy for all cases -> there is no error with new reproducer (but old reproducer fails, which is obvious - it's a revert of original fix)
* I've also tried to keep closing in PreDestroy for all cases + add transaction listener, so inTx contexts were closed twice - this should not be used, but I've tried it to validate reason - there were no error with both reproducers - so it also worked
* then I accidentally forgot one negation in my new patch. It caused, that contexts from inTx were closed twice, but without inTx weren't close at all. (I have validated it with some debugging messages) - there was an error with new reproducer.
>From the third item, I was able to see (because of my debugging messages), that there are contexts which are injected and not inTx (which sounds possible) - and these contexts are not closed with original fix -> *this is the reason of the current issue*
I'm currently trying to rewrite new reproducer into integration test to add certainty, that fix works - unfortunately, I'm still not able to reproduce an error in test, but I hope that it should be possible.
> Wildfly leaks ActiveMQ connections
> ----------------------------------
>
> Key: WFLY-10531
> URL: https://issues.jboss.org/browse/WFLY-10531
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Final
> Environment: openjdk 8 / openjdk 9, Linux
> Reporter: Marcel Šebek
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: WFLY-10531-ear-1.0.ear, WFLY10531.zip
>
>
> After upgrading our application from wildfly 12 to 13, the app started to crash after a while (hours, days, depending on circumstances). It crashes on
> IJ000453: Unable to get managed connection for java:/JmsXA
> and other errors (it simply cannot perform all the jobs it contains). I found that when shutting down the server which has been running for a while, I can see a bunch of these messages in the log:
> WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (ServerService Thread Pool -- 117) [:::] IJ000615: Destroying active connection in pool: ActiveMQConnectionDefinition (org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection@2f37f69)
> Bascially, the longer the server was running, more of these messages are shown. I cannot find a way how to reproduce the issue. When the server runs for short time but with some load, no connection is leaked (or just one, rarely). On the other side, it leaks connections even without any particularly high load (just a few requests and @Schedule jobs) when running for longer time.
> It may also be a bug in our application, which just happen to have more serious impact with the new wildfly version.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months