[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Radim Vansa (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Radim Vansa commented on WFLY-13259:
------------------------------------
[~smarlow]I believe that simply setting TRACE level on PutFromLoadValidator gives you all the details.
I think Sorin's analysis is correct; the pending put is not removed from the cache if the entity is not found. IIRC there was no call from Hibernate's side that would tell the cache that it is not going to put anything to the cache, so we're relying on the expiration. With current codebase it might be possible to register a synchronization to remove the entry when the transaction completes/when the session is closed; I can't see if that could break anything or if it would just have performance impact (allocations, synchronized entry access...).
If the same key is repeatedly accessed, every time we check if there's more than 10 'pending puts' (hardcoded GC_THRESHOLD) and in that case we try to remove all records that are older than cache's {{expiration.maxIdle}}. That's where the 60 seconds come from, you can lower the value, but there's no option to let the transaction clean up immediately.
I don't think that this would be specific to 5.3; there were very little changes with regards to the invalidation mode.
You can also try if {{NONSTRICT_READ_WRITE}} access strategy would work for you; this is enabled for non-clustered caches, too. This has the downside of short period during transaction commit when the DB is already committed but cache would return stale values.
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5198) Infinite loop induced by backward chaining
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5198?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5198:
--------------------------------
Sprint: 2020 Week 13-15 (from Mar 23)
> Infinite loop induced by backward chaining
> ------------------------------------------
>
> Key: DROOLS-5198
> URL: https://issues.redhat.com/browse/DROOLS-5198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.34.0.Final
> Reporter: Ivan Zilotti
> Assignee: Mario Fusco
> Priority: Major
>
> I could not find an out-of-the-box mechanism in Drools for stopping loops induced by backward chaining. I've found some research e.g., [Avoiding Infinite Loops in Rule-Based Systems with Backward Chaining|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.8356...], indicating this is a recurring problem.
> When undeterred, these loops cause an OutOfMemoryError.
> I've already tried to:
> * Find configuration options in Drools to limit the behavior, but apparently there are't any;
> * Step through the code, trying to find ways to break the recursive behavior;
> * Change my rules to check for possible loops but that resulted either in partial facts being added to working memory (WM) or computationally expensive logic.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13256:
-----------------------------------------
[~jim.ma] [~aabdelsa] Any PicketLink relationship is interesting. At some point, probably WF 22 if not before, I see us dropping the PicketLink subsystem from WildFly, as the community project is archived. I actually did a quick branch to do that -- https://github.com/bstansberry/wildfly/commits/drop-plink. (It's out of date now; would need a rebase.)
To the extent any problem with this upgrade on JDK 13 is limited to PicketLink scenarios, my concern about doing it is reduced a lot. I try to use careful language when describing WildFly's support for JDKs after 11, e.g. from https://wildfly.org/news/2019/10/03/WildFly18-Final-Released/
{quote}
Our goal with WildFly is to have our releases run well for most use cases on the most recent GA JDK version available on the WildFly final release date. I’m pleased to report that this is the case with WildFly 18 and JDK 13. By run well, I mean the main WildFly testsuite runs with no more than a few failures in areas not expected to be commonly used. We want developers who are trying to evaluate what the latest JVM means for their applications to be able to look to WildFly as a useful development platform.
{quote}
Problems due to use of PicketLink fall into the "not expected to be commonly used" area IMHO.
Please note though that I don't want to ignore a broader problem that might affect lots of use cases beyond PicketLink. But if it is a PicketLink problem that would be very good to know.
> Upgrade bouncycastle to 1.65.0
> ------------------------------
>
> Key: WFLY-13256
> URL: https://issues.redhat.com/browse/WFLY-13256
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, Server
> Reporter: Bartosz Spyrko
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 20.0.0.Beta1
>
> Attachments: handshake-error.log, handshake-success.log
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5198) Infinite loop induced by backward chaining
by Ivan Zilotti (Jira)
Ivan Zilotti created DROOLS-5198:
------------------------------------
Summary: Infinite loop induced by backward chaining
Key: DROOLS-5198
URL: https://issues.redhat.com/browse/DROOLS-5198
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.34.0.Final
Reporter: Ivan Zilotti
Assignee: Mario Fusco
I could not find an out-of-the-box mechanism in Drools for stopping loops induced by backward chaining. I've found some research e.g., [Avoiding Infinite Loops in Rule-Based Systems with Backward Chaining|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.8356...], indicating this is a recurring problem.
When undeterred, these loops cause an OutOfMemoryError.
I've already tried to:
* Find configuration options in Drools to limit the behavior, but apparently there are't any;
* Step through the code, trying to find ways to break the recursive behavior;
* Change my rules to check for possible loops but that resulted either in partial facts being added to working memory (WM) or computationally expensive logic.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4870) Improve add-user handling to allow custom dictionary/keyboard
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFCORE-4870?page=com.atlassian.jira.plug... ]
Bartosz Baranowski updated WFCORE-4870:
---------------------------------------
Issue Type: Feature Request (was: Enhancement)
> Improve add-user handling to allow custom dictionary/keyboard
> -------------------------------------------------------------
>
> Key: WFCORE-4870
> URL: https://issues.redhat.com/browse/WFCORE-4870
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> As is:
> - default Keyboard is properties based setup, it is locked to default EN keyboard layout, properties file, that it reads are locked in management-domain jar
> - default Dictionary is properties based setup, it is locked with few example word definitions, properties file, that it reads are locked in management-domain jar
> - SimplePasswordStrengthChecker - default implementation of password check algorithm. Sadly with private fields, so it is not extendable( seems like oversight )
> - bin/add-user.properties - config file with properties that allow change how SimplePasswordStrengthChecker or other implementation behaves. It allows to load custom implementation of PasswordStrengthChecker
> Ideally, user should be able to:
> - configure layout/dictionary content
> - configure implementation of keyboard/dictionary
> - extend SimplePasswordStrengthChecker to change keyboard/dictionary, implement more checks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0
by Jim Ma (Jira)
[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ]
Jim Ma edited comment on WFLY-13256 at 3/26/20 7:31 AM:
--------------------------------------------------------
[~aabdelsa] I upgraded BC to version 1.65b16 and get the same error "javax.net.ssl.SSLException: readHandshakeRecord" as log from https://ci.wildfly.org/viewLog.html?buildId=192989&tab=buildResultsDiv&bu.... It looks test WSTrustTestCase#testPicketLink breaks testBearer() and testHolderOfKey tests,exclude this test will get all tests passed. From handshake logs(please find from attachement) , I can't find there is something wrong in client side. It's possible there are settings in PicketLinkSTS server endpoint affects ssl setting for other endpoints, or there is still something in 1.65b16 to be fixed. I didn't get this error with BC 1.62 and JDK13.
was (Author: jim.ma):
[~aabdelsa] I upgraded BC to version 1.65b16 and get the same error "javax.net.ssl.SSLException: readHandshakeRecord" with https://ci.wildfly.org/viewLog.html?buildId=192989&tab=buildResultsDiv&bu.... It looks test WSTrustTestCase#testPicketLink breaks testBearer() and testHolderOfKey tests. I looked at the handshake log(please find from attachement) , there is no more findings. It seems there are setting in PicketLinkSTS server endpoint affects ssl setting for other endpoints. I still don't know why. But JDK8 doesn't share this problem. Is it possible some jdk13 bug ?
> Upgrade bouncycastle to 1.65.0
> ------------------------------
>
> Key: WFLY-13256
> URL: https://issues.redhat.com/browse/WFLY-13256
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, Server
> Reporter: Bartosz Spyrko
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 20.0.0.Beta1
>
> Attachments: handshake-error.log, handshake-success.log
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5056) [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5056?page=com.atlassian.jira.plug... ]
Jozef Marko closed DROOLS-5056.
-------------------------------
Resolution: Cannot Reproduce
[~dadossan] I was also not able to reproduce the issue clicking, moving the nodes inside, whole service quite intensively. I am closing this, feel free to reopen any time in future if you spot stable steps to reproduce. Thank you.
> [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
> -------------------------------------------------------------------------------
>
> Key: DROOLS-5056
> URL: https://issues.redhat.com/browse/DROOLS-5056
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: issue.mp4, taxRate.dmn
>
>
> Sometimes the nodes inside the Decision Service are positioned outside from the Decision Service when the .DMN is saved an open again.
> I was unable to map exact when this happen, but I noticed that this happens depending on the changes you do in the position and size of the Decision Service and its inner nodes.
> I recorded a video with 2 minutes when the issue happens in the last seconds.
> As it can be notice it takes lots of trials to reproduce the issue.
> Also I was unable to reproduce the issue in the Business Central, so I'm not sure if it is related to DMN Editor in VS Code or DMN Editor itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-11566:
--------------------------------------
bq. I understand that this fix requires this PR as well, https://github.com/jbossas/jboss-classfilewriter/pull/20, correct?
No, that PR should actually be reverted (it was an initial attempt at solving this which caused further problems). I thought we did that already, I'll send a PR there.
> 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, 1 month
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Enrique González Martínez (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Enrique González Martínez commented on DROOLS-5106:
---------------------------------------------------
[~alessandrolt] This is drools. Artifcat is not being resolved in local maven repository.
{code}
./gradlew install
curl -X PUT "http://localhost:8080/kie-server/services/rest/server/containers/test" -H "accept: application/json" -H "content-type: application/json" -d "{ \"container-id\" : \"test\", \"release-id\" : { \"group-id\" : \"com.j2eeguys.demo\", \"artifact-id\" : \"KieServerDemo\", \"version\" : \"0.1.0-SNAPSHOT\" }}"
{code}
vanilla installation 7.33
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Luca Molteni
> Priority: Major
> Labels: Drools, drools-compiler, maven
> Attachments: settings.xml
>
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 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:358)
> 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:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> 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:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month