[JBoss JIRA] (WFCORE-2025) CLI SSLContext Priority
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2025?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2025:
-------------------------------
Fix Version/s: 3.0.0.Alpha18
(was: 3.0.0.Alpha17)
> CLI SSLContext Priority
> -----------------------
>
> Key: WFCORE-2025
> URL: https://issues.jboss.org/browse/WFCORE-2025
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha18
>
>
> We have three different places an SSLContext could come from for the CLI: -
> # CLI Configuration
> # AuthenticationClient Configuration
> # Default interactive SSLContext
> We need to ensure they are prioritised as above.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2149) Io subsystem worker pool threads cannot die even if task-keepalive is specified
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2149?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2149:
----------------------------------------
Assignee: David Lloyd (was: Jason Greene)
> Io subsystem worker pool threads cannot die even if task-keepalive is specified
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2149
> URL: https://issues.jboss.org/browse/WFCORE-2149
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Reporter: Mathieu Lachance
> Assignee: David Lloyd
>
> The Wildlfy io subsystem should allow to set thread keep alive time as documented in wildfly_io_1.1.xsd:
> {code}
> <xs:attribute name="task-keepalive" type="xs:int" default="60"/>
> {code}
> Though when you have a look at the XNIO implementation i.e. https://github.com/xnio/xnio/blob/f1bd055381436683789c7e69a3f6455b7141ad2...:
> {code}
> taskPool = new TaskPool(
> threadCount, // ignore core threads setting, always fill to max
> threadCount,
> optionMap.get(Options.WORKER_TASK_KEEPALIVE, 60000), TimeUnit.MILLISECONDS,
> taskQueue,
> new WorkerThreadFactory(threadGroup, optionMap, markThreadAsDaemon),
> new ThreadPoolExecutor.AbortPolicy());
> final class TaskPool extends ThreadPoolExecutor {
> TaskPool(final int corePoolSize, final int maximumPoolSize, final long keepAliveTime, final TimeUnit unit, final BlockingQueue<Runnable> workQueue, final ThreadFactory threadFactory, final RejectedExecutionHandler handler) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler);
> }
> protected void terminated() {
> taskPoolTerminated();
> }
> }
> {code}
> The created TaskPool/ThreadPoolExecutor will have both the core and max thread size equals. By setting them both equals, means that if ThreadPoolExecutor#allowCoreThreadTimeOut is not true, no thread will ever be able to die even if there's a keepAliveTime set.
> I think previously there's was a setting to set the actual amount of "core" thread pool but I think it was removed in Wildfly 9. But from an outsider, it is not really clear reading the code that this is really the case.
> That said, I think having either that setting back or setting the "allowCoreThreadTimeOut" set to true will fix the issue.
> Not letting thread die:
> # is a "waste" of resource
> # can lead to some ThreadLocal grows out of proportions (even if bad practice)
> Also, the documentation should be more precise to specify the time unit that will be used when configuring the keep alive time; from what I understand, it should state milliseconds.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2149) Io subsystem worker pool threads cannot die even if task-keepalive is specified
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2149?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-6649 to WFCORE-2149:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2149 (was: WFLY-6649)
Component/s: IO
(was: IO)
Affects Version/s: (was: 10.0.0.Final)
> Io subsystem worker pool threads cannot die even if task-keepalive is specified
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2149
> URL: https://issues.jboss.org/browse/WFCORE-2149
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Reporter: Mathieu Lachance
> Assignee: Jason Greene
>
> The Wildlfy io subsystem should allow to set thread keep alive time as documented in wildfly_io_1.1.xsd:
> {code}
> <xs:attribute name="task-keepalive" type="xs:int" default="60"/>
> {code}
> Though when you have a look at the XNIO implementation i.e. https://github.com/xnio/xnio/blob/f1bd055381436683789c7e69a3f6455b7141ad2...:
> {code}
> taskPool = new TaskPool(
> threadCount, // ignore core threads setting, always fill to max
> threadCount,
> optionMap.get(Options.WORKER_TASK_KEEPALIVE, 60000), TimeUnit.MILLISECONDS,
> taskQueue,
> new WorkerThreadFactory(threadGroup, optionMap, markThreadAsDaemon),
> new ThreadPoolExecutor.AbortPolicy());
> final class TaskPool extends ThreadPoolExecutor {
> TaskPool(final int corePoolSize, final int maximumPoolSize, final long keepAliveTime, final TimeUnit unit, final BlockingQueue<Runnable> workQueue, final ThreadFactory threadFactory, final RejectedExecutionHandler handler) {
> super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler);
> }
> protected void terminated() {
> taskPoolTerminated();
> }
> }
> {code}
> The created TaskPool/ThreadPoolExecutor will have both the core and max thread size equals. By setting them both equals, means that if ThreadPoolExecutor#allowCoreThreadTimeOut is not true, no thread will ever be able to die even if there's a keepAliveTime set.
> I think previously there's was a setting to set the actual amount of "core" thread pool but I think it was removed in Wildfly 9. But from an outsider, it is not really clear reading the code that this is really the case.
> That said, I think having either that setting back or setting the "allowCoreThreadTimeOut" set to true will fix the issue.
> Not letting thread die:
> # is a "waste" of resource
> # can lead to some ThreadLocal grows out of proportions (even if bad practice)
> Also, the documentation should be more precise to specify the time unit that will be used when configuring the keep alive time; from what I understand, it should state milliseconds.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2068:
-------------------------------
Fix Version/s: 3.0.0.Alpha18
(was: 3.0.0.Alpha17)
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Fix For: 3.0.0.Alpha18
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7062) Infinispan query NPE on caches created by EmbeddedCacheManager
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7062?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7062.
------------------------------
Resolution: Rejected
@Resource(lookup = "java:jboss/infinispan/APM") will not resolve to anything, hence the NPE during init().
To inject a cache instance into the application, use the following:
@Resource(lookup = "java:jboss/infinispan/cache/APM/stringsContainer")
private Cache<String, StringWrapper> cache;
> Infinispan query NPE on caches created by EmbeddedCacheManager
> --------------------------------------------------------------
>
> Key: WFLY-7062
> URL: https://issues.jboss.org/browse/WFLY-7062
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Fedora 24
> openjdk version "1.8.0_102"
> OpenJDK Runtime Environment (build 1.8.0_102-b14)
> OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)
> Reporter: Pavol Loffay
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
> Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
> Application source code: https://github.com/pavolloffay/infinispan-wildfly10
> Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
> {code:java}
> 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> 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 io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 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:131)
> 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 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 io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 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:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 42 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months