[JBoss JIRA] (WFLY-13929) Intermittent failures in DeploymentOverlayCLITestCase
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-13929?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-13929:
------------------------------------
WFLY-13870 (merged on Sept. 15th) brought in component upgrade for Undertow 2.2.0.Final and XNIO 3.8.2.Final.
[~flavia.rainone] could you please check if there are changes in these component upgrades that would explain these failures?
> Intermittent failures in DeploymentOverlayCLITestCase
> -----------------------------------------------------
>
> Key: WFLY-13929
> URL: https://issues.redhat.com/browse/WFLY-13929
> Project: WildFly
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Major
>
> Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g.
> https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu...
> {code}
> java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75)
> at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241)
> at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256)
> at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117)
> at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310)
> at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
> at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
> 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.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> 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.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> 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:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: User limit of inotify instances reached or too many open files
> at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64)
> at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73)
> ... 49 more
> </pre></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383)
> {code}
> Tests started failing fairly often on September 17.
> https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (DROOLS-5687) NullPointerException on second consecutive declared type update
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5687?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5687:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28)
> NullPointerException on second consecutive declared type update
> ---------------------------------------------------------------
>
> Key: DROOLS-5687
> URL: https://issues.redhat.com/browse/DROOLS-5687
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: npe-consecutives-declare-update.zip
>
>
> When updating a {{KieContainer}} with {{updateToVersion}} with a change in a declared type two consecutive times, a {{NullPointerException}} is raised.
> Minimal example DRL triggering the issue (notice at least two declared types are needed):
> {noformat}
> declare FactType1
> x : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> first update:
> {noformat}
> declare FactType1
> x : int
> z : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> second update:
> {noformat}
> declare FactType1
> x : int
> z : int
> w : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> The second update will raise the following exception:
> {noformat}
> java.lang.NullPointerException
> at org.drools.compiler.kie.util.ChangeSetBuilder.build(ChangeSetBuilder.java:106)
> at org.drools.compiler.kie.builder.impl.InternalKieModule.getChanges(InternalKieModule.java:132)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:241)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:237)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:195)
> at org.example.reproducer.KjarUpdateTest.update(KjarUpdateTest.java:37)
> at org.example.reproducer.KjarUpdateTest.testConsecutiveUpdates(KjarUpdateTest.java:48)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (ELY-2025) Resource leak in ElytronXmlParser.
by Ilia Vassilev (Jira)
Ilia Vassilev created ELY-2025:
----------------------------------
Summary: Resource leak in ElytronXmlParser.
Key: ELY-2025
URL: https://issues.redhat.com/browse/ELY-2025
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Client
Reporter: Ilia Vassilev
Assignee: Ilia Vassilev
Resource leak in ElytronXmlParser.get() method. The resource FileInputStream is not closed on exception.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13929) Intermittent failures in DeploymentOverlayCLITestCase
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13929?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13929:
------------------------------------
Forum Reference: https://wildfly.zulipchat.com/#narrow/stream/174177-ci-servers/topic/Too....
There's a zulip thread about this at https://wildfly.zulipchat.com/#narrow/stream/174177-ci-servers/topic/Too....
> Intermittent failures in DeploymentOverlayCLITestCase
> -----------------------------------------------------
>
> Key: WFLY-13929
> URL: https://issues.redhat.com/browse/WFLY-13929
> Project: WildFly
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Major
>
> Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g.
> https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu...
> {code}
> java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75)
> at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241)
> at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256)
> at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117)
> at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310)
> at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
> at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
> 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.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> 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.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> 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:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: User limit of inotify instances reached or too many open files
> at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64)
> at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73)
> ... 49 more
> </pre></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383)
> {code}
> Tests started failing fairly often on September 17.
> https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13929) Intermittent failures in DeploymentOverlayCLITestCase
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13929?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13929:
------------------------------------
Summary: Intermittent failures in DeploymentOverlayCLITestCase (was: Intermittent failures in https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...)
> Intermittent failures in DeploymentOverlayCLITestCase
> -----------------------------------------------------
>
> Key: WFLY-13929
> URL: https://issues.redhat.com/browse/WFLY-13929
> Project: WildFly
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Major
>
> Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g.
> https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu...
> {code}
> java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75)
> at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241)
> at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256)
> at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117)
> at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310)
> at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
> at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
> 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.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> 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.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> 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:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: User limit of inotify instances reached or too many open files
> at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64)
> at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
> at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73)
> ... 49 more
> </pre></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415)
> at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383)
> {code}
> Tests started failing fairly often on September 17.
> https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13929) Intermittent failures in https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=&tab=testDetails&testNameId=2647618872173241261&order=TEST_STATUS_DESC&branch_WF_PullRequest=__all_branches__&itemsCount=50
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13929:
---------------------------------------
Summary: Intermittent failures in https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
Key: WFLY-13929
URL: https://issues.redhat.com/browse/WFLY-13929
Project: WildFly
Issue Type: Bug
Components: Management
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Two tests in DeploymentOverlayCLITestCase are failing intermittently but fairly often, e.g.
https://ci.wildfly.org/viewLog.html?buildId=225079&tab=buildResultsDiv&bu...
{code}
java.lang.RuntimeException: java.io.IOException: User limit of inotify instances reached or too many open files
at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:75)
at org.xnio.nio.NioXnio.createFileSystemWatcher(NioXnio.java:241)
at io.undertow.server.handlers.resource.PathResourceManager.registerResourceChangeListener(PathResourceManager.java:256)
at org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:117)
at io.undertow.server.handlers.resource.CachingResourceManager.registerResourceChangeListener(CachingResourceManager.java:131)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:310)
at io.undertow.servlet.core.ManagedServlet.forceInit(ManagedServlet.java:212)
at io.undertow.servlet.handlers.ServletChain.forceInit(ServletChain.java:130)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:63)
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.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
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.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
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:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: User limit of inotify instances reached or too many open files
at sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:64)
at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
at org.xnio.nio.WatchServiceFileSystemWatcher.<init>(WatchServiceFileSystemWatcher.java:73)
... 49 more
</pre></body></html>
at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:61)
at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:82)
at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.simpleOverrideInEarAtWarLevelExplodedTest(DeploymentOverlayCLITestCase.java:415)
at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideInEarAtWarLevelExploded(DeploymentOverlayCLITestCase.java:383)
{code}
Tests started failing fairly often on September 17.
https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
The first failure was against a PR that hasn't been merged yet, so it's likely the problem is in master, not one of the PRs shown on that page.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (DROOLS-5687) NullPointerException on second consecutive declared type update
by Matteo Casalino (Jira)
Matteo Casalino created DROOLS-5687:
---------------------------------------
Summary: NullPointerException on second consecutive declared type update
Key: DROOLS-5687
URL: https://issues.redhat.com/browse/DROOLS-5687
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.43.0.Final
Reporter: Matteo Casalino
Assignee: Mario Fusco
Attachments: npe-consecutives-declare-update.zip
When updating a {{KieContainer}} with {{updateToVersion}} with a change in a declared type two consecutive times, a {{NullPointerException}} is raised.
Minimal example DRL triggering the issue (notice at least two declared types are needed):
{noformat}
declare FactType1
x : int
end
declare FactType2
y : int
end
{noformat}
first update:
{noformat}
declare FactType1
x : int
z : int
end
declare FactType2
y : int
end
{noformat}
second update:
{noformat}
declare FactType1
x : int
z : int
w : int
end
declare FactType2
y : int
end
{noformat}
The second update will raise the following exception:
{noformat}
java.lang.NullPointerException
at org.drools.compiler.kie.util.ChangeSetBuilder.build(ChangeSetBuilder.java:106)
at org.drools.compiler.kie.builder.impl.InternalKieModule.getChanges(InternalKieModule.java:132)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:241)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:237)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:195)
at org.example.reproducer.KjarUpdateTest.update(KjarUpdateTest.java:37)
at org.example.reproducer.KjarUpdateTest.testConsecutiveUpdates(KjarUpdateTest.java:48)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13928:
------------------------------------
Priority: Minor (was: Major)
> EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13928
> URL: https://issues.redhat.com/browse/WFLY-13928
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Minor
>
> This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
> EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
> Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
> Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13928) EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13928:
------------------------------------
Description:
This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
was:
This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; it works because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
> EndpointService should determine if a security-domain is elytron or legacy using capabilities, not MSC
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13928
> URL: https://issues.redhat.com/browse/WFLY-13928
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Major
>
> This is a follow on to https://github.com/wildfly/wildfly/pull/13597/files
> EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if things are present by doing MSC service lookups. Generally that's unreliable; but it works in this case because all subsystems install their services before deployment processing begins, and EndpointService is part of deployment processing.
> Still, the services that are being looked up are associated with a capability. So these methods can just use CapabilityServiceSupport.hasCapability to see if that capability is present.
> Semi-related, in various places related to security domain integration EndpointService is using different strategies for creating a ServiceName for the security-related service. Some of those would be eliminated by the main change I discuss above. The others should consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months