[JBoss JIRA] (WFLY-5588) DefaultContextServiceServletTestCase fails on IBM jdk
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5588?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5588:
--------------------------------------
I am starting to doubt I'll ever get an answer for this - https://developer.ibm.com/answers/questions/240589/comibmenableclasscachi...
> DefaultContextServiceServletTestCase fails on IBM jdk
> -----------------------------------------------------
>
> Key: WFLY-5588
> URL: https://issues.jboss.org/browse/WFLY-5588
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.CR4
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480-20150129_02)
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150116_231420 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_GA_20150116_2030_B231420
> JIT - tr.r14.java_20150109_82886.02
> GC - R28_Java8_GA_20150116_2030_B231420_CMPRSS
> J9CL - 20150116_231420)
> JCL - 20150123_01 based on Oracle jdk8u31-b12
> Reporter: Petr Kremensky
> Assignee: Dominik Pospisil
> Attachments: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase-output.txt, org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.txt, TEST-org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.xml
>
>
> org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.testServlet fails on IBM jdk.
> {noformat}
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.182 sec <<< FAILURE! - in org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase
> testServlet(org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase) Time elapsed: 0.142 sec <<< ERROR!
> java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: HTTP Status 500 Response: <html><head><title>ERROR</title><style>body {
> font-family: "Lucida Grande", "Lucida Sans Unicode", "Trebuchet MS", Helvetica, Arial, Verdana, sans-serif;
> margin: 5px;
> }
> .header {
> background-image: linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -o-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -moz-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -webkit-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -ms-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
>
> background-image: -webkit-gradient(
> linear,
> left bottom,
> left top,
> color-stop(0.08, rgb(153,151,153)),
> color-stop(0.54, rgb(199,199,199))
> );
> color: black;
> padding: 2px;
> font-weight: normal;
> border: solid 1px;
> font-size: 170%;
> text-align: left;
> vertical-align: middle;
> height: 32px;
> }
> .error-div {
> display: inline-block; width: 32px; height: 32px; background: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAgAAAAIACH+pydAAAGGElEQVRYw8WXW2wcVxnHf+fM7NXrdXbdtZ3ipGqCEzvQKmlFoUggwkvvGBoaqVVV5Y0nkCoQPPCAhMQbQlzUh/IWHoh6QUVKZVLxUCGogKZRW9uJkyg0iVzZ2dhre9c7u7M7c87hYWc2M7t2bBASI306O/85+v7/7zLn24H/8yV2u/EcFNvwVNK2X0DKw1qpYaX1gCWlY0m5arRe8JQ6I2DmaVj/nwk4CxO2Zf1aw9dKo6N67+eOZHN7x0gViiSHBmlXa7hrazjLt1i+eKmxUi5bwpg/e8a8PA3X/msBr0MyJ+WvgFOffehY8v7HH5OW78HqGjgOtNrge2AnIJWAgQEYLqBsm3/NvKM/mZ1rYczpRa2/9x3w/iMBM1BCiHfuGRmZevClF9NJ5cP1m9B0+/aa3t/ZDNw3TtuSfPy737trK6sXtTGPPwOruxLwNhSEEHMHpqZGDz93wubKFdio3ZXUGNOHs2cIDh/g6pt/9G8uXLnlGPP5k1Dt5bN60m6lhXj34OTkxKET37SZm4d6oz/KgFRH7yOrBozbwlTWGf7ql6RZrWTcytrxaTj9Ro9OGb3JS/mz0nDxgYnnvmWbuUsdJ6FTY2JmImShqZA83N90UbOXOXDiG4nCcPFoTsqfbluCP8DenJQLx1/+7pBcXILaZl9qo2svFmalb48xkM9hxkf5+29+u9HSenIayn0ZyEr5i0NHpnKy7aGrtW6UehsLozRBRlRQEh3BwzLpWh3h++yfPJRLSvnzvhK8DkPamOl7n3nCUjcXtyXuK0X0WViaAFc9QtSNJe594uu2MubZGcjHBGTgqeFiQQml0K12nDgSpd4iyi4uRMci6Q8xJSWq7SGEZCg/qD14LCYgIcTzoxMHc6qygYk40aETKTFSdh2aANOWhbEsjJSYCK6C/V0LcH+9xvCB/TlbiBdCAXbQMJPZ/fvQjUbXEULAa6/1deyuh0dwNU+e7DSzEOhmi8xn9iI+ujgVE6ChlBwpYcqVjuIgA3IXBMYYtNbd30IIpJQI0ZEa+gPQnk9ieA8GSrESaGNyiWIBrVQntUHqdrq01iiluo0WilBK4fs+WutOr4S9YAyJoRzamMGYAClEve046ETyTr13EKCU6kZ+N4GNCxfwKpVOryQSuOUVhBCbsRIIuN1cWRkaSCfRrdaOTncijgltNPDn5xHZLIn7x3GNh4CVmADgcv3a9YmBY0cxm06nAQH31KlOao3BL5fxbtzAOE73hAt7JXb6RU7PGO44WK5Do1ZHw6WYAN+YM+X5S8dLXziWizVNvY5aWcFfWuq8Idsctb1Yr8DwmRwrUr1yfVMbcyYmwIWZ2mbdai9+gvfBAsaAbrUwrrtllLuJPibIGGQ2hUlIHLdlA+diTXgSqkKIt5b/OevL+8bwqlWU63anW3jyhaa4c9T2Hs0hrsL5EOCJQ/sov7/gS8Mb07AZEwDgav2D5aVy3eSziEL+Dllk0PSRcmcMqx6BUeGykINsksrttboPP4w2aVfACVhGiFevvft+I/XwJCad3DF6tc2MiD4zmRSZhyZY/OusI4V4JTqKYwIA6lr/2Gm6s5/+7UMv/egDmEyqL7VbRR/LViR6sikGvniYpffm2m6r/VFd65/0vqZ9R/tbsMeG+WKpMDL+lWMJ58Jl/NVqvOG26PAoDmCXhhg4epDl9+a9zUp1uQkPbvWfcMvZchbuEXAuk0kf2X/84YxpuDQv3kA5zW1fw9CswSyZyXFEJsmnf/m46bntuTY8+SxUtuLadri9CokxeEUK8WJhtJgaeeSIxG3RurWGv+Gg3RbaU5CwkOkU1lCWxFgBmbS4ff6qX7297rXh9Gn4/llobMcjtsFywACQ+zZMTsOP8vBIOpNS+bFiJj2cxx7MYg+k8ZwmrWqD9lqNjVvrTc9tWRtw/k345dtwFagDTmTdUUA2EDAYXffB2JPw6FH4ch7GUpCzIemD50J9A1Y+hH/8Cc4vdTq9Tud9D9dNOt+MajclyNL53xZmIhusmcBSQJLOd4UJnHqACzTppDy0kHizl/yuPRB5nggIM0A6IE4GuA34EQFtoBUQuwGm7kbwb+eaEEXmuV5dAAAAJXRFWHRjcmVhdGUtZGF0ZQAyMDA5LTExLTEwVDE5OjM4OjI0LTA3OjAwdDKp4gAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxMC0wMi0yMFQyMzoyNjoyNC0wNzowMC7DUNYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTAtMDEtMTFUMDg6NTc6MzUtMDc6MDCruapPAAAAMnRFWHRMaWNlbnNlAGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUHVibGljX2RvbWFpbj/96s8AAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMTEtMTBUMTk6Mzg6MjQtMDc6MDArg9/WAAAAGXRFWHRTb3VyY2UAVGFuZ28gSWNvbiBMaWJyYXJ5VM/tggAAADp0RVh0U291cmNlX1VSTABodHRwOi8vdGFuZ28uZnJlZWRlc2t0b3Aub3JnL1RhbmdvX0ljb25fTGlicmFyebzIrdYAAAAASUVORK5CYII=') left center no-repeat;
> }.error-text-div {
> display: inline-block; vertical-align: top; height: 32px;}.label { font-weight:bold; display: inline-block;}.value { display: inline-block;}</style></head><body><div class="header"><div class="error-div"></div><div class="error-text-div">Error processing request</div></div><div class="label">Context Path:</div><div class="value">/war-example</div><br/><div class="label">Servlet Path:</div><div class="value">/simple</div><br/><div class="label">Path Info:</div><div class="value">null</div><br/><div class="label">Query String:</div><div class="value">null</div><br/><b>Stack Trace</b><br/>javax.servlet.ServletException: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal<br/>org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestServlet.doGet(DefaultContextServiceTestServlet.java:74)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:687)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:790)<br/>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)<br/>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)<br/>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)<br/>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)<br/>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)<br/>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)<br/>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)<br/>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)<br/>io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)<br/>io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)<br/>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)<br/>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)<br/>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)<br/>io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)<br/>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)<br/>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)<br/>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)<br/>java.lang.Thread.run(Thread.java:785)<br/></body></html>
> at java.util.concurrent.FutureTask.report(FutureTask.java:133)
> at java.util.concurrent.FutureTask.get(FutureTask.java:217)
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:51)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:81)
> at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.testServlet(DefaultContextServiceServletTestCase.java:67)
> Caused by: java.io.IOException: HTTP Status 500 Response: <html><head><title>ERROR</title><style>body {
> font-family: "Lucida Grande", "Lucida Sans Unicode", "Trebuchet MS", Helvetica, Arial, Verdana, sans-serif;
> margin: 5px;
> }
> .header {
> background-image: linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -o-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -moz-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -webkit-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -ms-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
>
> background-image: -webkit-gradient(
> linear,
> left bottom,
> left top,
> color-stop(0.08, rgb(153,151,153)),
> color-stop(0.54, rgb(199,199,199))
> );
> color: black;
> padding: 2px;
> font-weight: normal;
> border: solid 1px;
> font-size: 170%;
> text-align: left;
> vertical-align: middle;
> height: 32px;
> }
> .error-div {
> display: inline-block; width: 32px; height: 32px; background: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAgAAAAIACH+pydAAAGGElEQVRYw8WXW2wcVxnHf+fM7NXrdXbdtZ3ipGqCEzvQKmlFoUggwkvvGBoaqVVV5Y0nkCoQPPCAhMQbQlzUh/IWHoh6QUVKZVLxUCGogKZRW9uJkyg0iVzZ2dhre9c7u7M7c87hYWc2M7t2bBASI306O/85+v7/7zLn24H/8yV2u/EcFNvwVNK2X0DKw1qpYaX1gCWlY0m5arRe8JQ6I2DmaVj/nwk4CxO2Zf1aw9dKo6N67+eOZHN7x0gViiSHBmlXa7hrazjLt1i+eKmxUi5bwpg/e8a8PA3X/msBr0MyJ+WvgFOffehY8v7HH5OW78HqGjgOtNrge2AnIJWAgQEYLqBsm3/NvKM/mZ1rYczpRa2/9x3w/iMBM1BCiHfuGRmZevClF9NJ5cP1m9B0+/aa3t/ZDNw3TtuSfPy737trK6sXtTGPPwOruxLwNhSEEHMHpqZGDz93wubKFdio3ZXUGNOHs2cIDh/g6pt/9G8uXLnlGPP5k1Dt5bN60m6lhXj34OTkxKET37SZm4d6oz/KgFRH7yOrBozbwlTWGf7ql6RZrWTcytrxaTj9Ro9OGb3JS/mz0nDxgYnnvmWbuUsdJ6FTY2JmImShqZA83N90UbOXOXDiG4nCcPFoTsqfbluCP8DenJQLx1/+7pBcXILaZl9qo2svFmalb48xkM9hxkf5+29+u9HSenIayn0ZyEr5i0NHpnKy7aGrtW6UehsLozRBRlRQEh3BwzLpWh3h++yfPJRLSvnzvhK8DkPamOl7n3nCUjcXtyXuK0X0WViaAFc9QtSNJe594uu2MubZGcjHBGTgqeFiQQml0K12nDgSpd4iyi4uRMci6Q8xJSWq7SGEZCg/qD14LCYgIcTzoxMHc6qygYk40aETKTFSdh2aANOWhbEsjJSYCK6C/V0LcH+9xvCB/TlbiBdCAXbQMJPZ/fvQjUbXEULAa6/1deyuh0dwNU+e7DSzEOhmi8xn9iI+ujgVE6ChlBwpYcqVjuIgA3IXBMYYtNbd30IIpJQI0ZEa+gPQnk9ieA8GSrESaGNyiWIBrVQntUHqdrq01iiluo0WilBK4fs+WutOr4S9YAyJoRzamMGYAClEve046ETyTr13EKCU6kZ+N4GNCxfwKpVOryQSuOUVhBCbsRIIuN1cWRkaSCfRrdaOTncijgltNPDn5xHZLIn7x3GNh4CVmADgcv3a9YmBY0cxm06nAQH31KlOao3BL5fxbtzAOE73hAt7JXb6RU7PGO44WK5Do1ZHw6WYAN+YM+X5S8dLXziWizVNvY5aWcFfWuq8Idsctb1Yr8DwmRwrUr1yfVMbcyYmwIWZ2mbdai9+gvfBAsaAbrUwrrtllLuJPibIGGQ2hUlIHLdlA+diTXgSqkKIt5b/OevL+8bwqlWU63anW3jyhaa4c9T2Hs0hrsL5EOCJQ/sov7/gS8Mb07AZEwDgav2D5aVy3eSziEL+Dllk0PSRcmcMqx6BUeGykINsksrttboPP4w2aVfACVhGiFevvft+I/XwJCad3DF6tc2MiD4zmRSZhyZY/OusI4V4JTqKYwIA6lr/2Gm6s5/+7UMv/egDmEyqL7VbRR/LViR6sikGvniYpffm2m6r/VFd65/0vqZ9R/tbsMeG+WKpMDL+lWMJ58Jl/NVqvOG26PAoDmCXhhg4epDl9+a9zUp1uQkPbvWfcMvZchbuEXAuk0kf2X/84YxpuDQv3kA5zW1fw9CswSyZyXFEJsmnf/m46bntuTY8+SxUtuLadri9CokxeEUK8WJhtJgaeeSIxG3RurWGv+Gg3RbaU5CwkOkU1lCWxFgBmbS4ff6qX7297rXh9Gn4/llobMcjtsFywACQ+zZMTsOP8vBIOpNS+bFiJj2cxx7MYg+k8ZwmrWqD9lqNjVvrTc9tWRtw/k345dtwFagDTmTdUUA2EDAYXffB2JPw6FH4ch7GUpCzIemD50J9A1Y+hH/8Cc4vdTq9Tud9D9dNOt+MajclyNL53xZmIhusmcBSQJLOd4UJnHqACzTppDy0kHizl/yuPRB5nggIM0A6IE4GuA34EQFtoBUQuwGm7kbwb+eaEEXmuV5dAAAAJXRFWHRjcmVhdGUtZGF0ZQAyMDA5LTExLTEwVDE5OjM4OjI0LTA3OjAwdDKp4gAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxMC0wMi0yMFQyMzoyNjoyNC0wNzowMC7DUNYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTAtMDEtMTFUMDg6NTc6MzUtMDc6MDCruapPAAAAMnRFWHRMaWNlbnNlAGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUHVibGljX2RvbWFpbj/96s8AAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMTEtMTBUMTk6Mzg6MjQtMDc6MDArg9/WAAAAGXRFWHRTb3VyY2UAVGFuZ28gSWNvbiBMaWJyYXJ5VM/tggAAADp0RVh0U291cmNlX1VSTABodHRwOi8vdGFuZ28uZnJlZWRlc2t0b3Aub3JnL1RhbmdvX0ljb25fTGlicmFyebzIrdYAAAAASUVORK5CYII=') left center no-repeat;
> }.error-text-div {
> display: inline-block; vertical-align: top; height: 32px;}.label { font-weight:bold; display: inline-block;}.value { display: inline-block;}</style></head><body><div class="header"><div class="error-div"></div><div class="error-text-div">Error processing request</div></div><div class="label">Context Path:</div><div class="value">/war-example</div><br/><div class="label">Servlet Path:</div><div class="value">/simple</div><br/><div class="label">Path Info:</div><div class="value">null</div><br/><div class="label">Query String:</div><div class="value">null</div><br/><b>Stack Trace</b><br/>javax.servlet.ServletException: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal<br/>org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestServlet.doGet(DefaultContextServiceTestServlet.java:74)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:687)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:790)<br/>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)<br/>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)<br/>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)<br/>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)<br/>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)<br/>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)<br/>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)<br/>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)<br/>io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)<br/>io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)<br/>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)<br/>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)<br/>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)<br/>io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)<br/>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)<br/>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)<br/>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)<br/>java.lang.Thread.run(Thread.java:785)<br/></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.processResponse(HttpRequest.java:156)
> at org.jboss.as.test.integration.common.HttpRequest.access$000(HttpRequest.java:45)
> at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:78)
> at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1989:
--------------------------------
Actually, buffer pools can be used more widely:
* Sending of message batches and single messages
** Also for {{TCP_NIO2}} once JGRP-1991 is in place
* Reception of message batches
** The message batches are de-serialized from the buffer, so the buffer can be reused immediately after deserialization (in {{TP.handleMessageBatch}})
* Reception of single messages
** Can we assume that - after the {{receive()}} callback returned - we can reuse the buffer?
** Asynchronous Invocation API?
** User cannot store the buffer somewhere, but needs to copy if it wants to hang on to the buffer
** Possibly make this configurable
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"DSLFpmlUniversalContainerCacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
Thomas Leung created DROOLS-1000:
------------------------------------
Summary: Race condition occured when executing Drools
Key: DROOLS-1000
URL: https://issues.jboss.org/browse/DROOLS-1000
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Thomas Leung
Assignee: Mario Fusco
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"DSLFpmlUniversalContainerCacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFBUILD-16) Support subsystem templates within a feature-pack
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-16?page=com.atlassian.jira.plugin... ]
Stuart Douglas commented on WFBUILD-16:
---------------------------------------
1.1.2.Final is release with this change. You can now include a subsystem in a subsystem-templates directory in the feature pack.
> Support subsystem templates within a feature-pack
> -------------------------------------------------
>
> Key: WFBUILD-16
> URL: https://issues.jboss.org/browse/WFBUILD-16
> Project: WildFly Build Tools
> Issue Type: Feature Request
> Affects Versions: 1.1.0.CR2
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
> Fix For: 1.1.2.Final
>
>
> Users should be able to customize subsystems when extending a feature-pack without being forced to have a subsystem artifact where the config file would be located.
> Accordingly with [~swd847], something like "so you could just have it in a subsystem-templates in the feature pack src" would be enough.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFBUILD-16) Support subsystem templates within a feature-pack
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-16?page=com.atlassian.jira.plugin... ]
Stuart Douglas resolved WFBUILD-16.
-----------------------------------
Fix Version/s: 1.1.2.Final
Resolution: Done
> Support subsystem templates within a feature-pack
> -------------------------------------------------
>
> Key: WFBUILD-16
> URL: https://issues.jboss.org/browse/WFBUILD-16
> Project: WildFly Build Tools
> Issue Type: Feature Request
> Affects Versions: 1.1.0.CR2
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
> Fix For: 1.1.2.Final
>
>
> Users should be able to customize subsystems when extending a feature-pack without being forced to have a subsystem artifact where the config file would be located.
> Accordingly with [~swd847], something like "so you could just have it in a subsystem-templates in the feature pack src" would be enough.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5731) PollSelectorImpl's FD leak for asyncServlet
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5731?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5731.
----------------------------------
Fix Version/s: 10.0.0.CR5
Resolution: Done
The update to XNIO 3.3.3.Final should have fixed this.
Note that you can still run out if you create and destroy a lot of threads in a very short period of time, as the Garbage collector may not be able to keep up. In general you will get way better performance with a thread pool anyway.
> PollSelectorImpl's FD leak for asyncServlet
> -------------------------------------------
>
> Key: WFLY-5731
> URL: https://issues.jboss.org/browse/WFLY-5731
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: OS:Red Hat Enterprise Linux Server release 5.5 (Tikanga)
> MW:wildfly-8.1.0.Final
> JDK:
> java version "1.7.0_25"
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
> Reporter: 浩 陈
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.CR5
>
> Attachments: DemoServlet.java
>
>
> AsyncServlet doGet() like this:
> protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
> resp.setContentType("text/html;charset=UTF-8");
> AsyncContext ctx = req.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx) {
> this.ctx = ctx;
> }
> public void run() {
> try {
> char[] data = new char[1024 * 1024 * 1];
> PrintWriter out = ctx.getResponse().getWriter();
> out.write(data);
> out.flush();
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> do request this Servlet some times , run linux cmd :
> lsof -p [JAVAPID]|grep pipe|wc -l
> this number increases by two every one request,but never decrease! when this number up to OS's open file limit everything is not OK.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months