[JBoss JIRA] (WFLY-11108) Enforce the short-running-threads requirement to a distributed workmanager
by Claudio Miranda (Jira)
Claudio Miranda created WFLY-11108:
--------------------------------------
Summary: Enforce the short-running-threads requirement to a distributed workmanager
Key: WFLY-11108
URL: https://issues.jboss.org/browse/WFLY-11108
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Claudio Miranda
Assignee: Stefano Maestri
A distributed-workmanager is allowed to remove its short-running-threads, but it is a required resource to a dwm and once the short-running-threads, Wildfly fails to start the dwm.
To add a distributed-workmanager:
{code}
batch
/subsystem=jca/distributed-workmanager=dwm1:add(name=dwm1)
/subsystem=jca/distributed-workmanager=dwm1/short-running-threads=dwm1:add(max-threads=11,queue-length=22)
run-batch
{code}
Remove the short-running-threads
{code}
/subsystem=jca/distributed-workmanager=dwm1/short-running-threads=dwm1:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{code}
Then Wildfly fails to reload the dwm
{code}
12:31:34,497 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "jca"),
("distributed-workmanager" => "dwm1")
]) - failure description: {
"WFLYCTL0412: Required services that are not installed:" => ["jboss.thread.executor.short-running-threads.dwm1"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.connector.workmanager.dwm1 is missing [jboss.thread.executor.short-running-threads.dwm1]"]
}
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (AG-94) "Closing connection in incorrect state" log spam
by Luis Barreiro (Jira)
[ https://issues.jboss.org/browse/AG-94?page=com.atlassian.jira.plugin.syst... ]
Luis Barreiro commented on AG-94:
---------------------------------
[~rcd] thanks for the report.
I was unable to reproduce the race condition. I ask if you can run with Agroal from https://github.com/barreiro/agroal/tree/AG-94 (build the project then upgrade agroal-pool.jar in modules/system/layers/base/io/agroal/main folder of your WildFly distribution)
Look for "{{WFLYAG0601: (...): AG 94: ...}}" warning messages. Those should not appear, but even if they do the connection won't be closed.
> "Closing connection in incorrect state" log spam
> ------------------------------------------------
>
> Key: AG-94
> URL: https://issues.jboss.org/browse/AG-94
> Project: Agroal
> Issue Type: Bug
> Components: pool
> Affects Versions: 1.1
> Environment: WildFly 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Luis Barreiro
> Priority: Major
>
> My WildFly application gets a lot of log spam like this:
> {code}
> 13:45:39,741 WARN [io.agroal.pool] (Agroal_17017539771) WFLYAG0601: DLS_DS: Closing connection in incorrect state CHECKED_IN
> {code}
> In trying to debug it, I found a potential cause. ConnectionPool line 251 comments that "handler not in CHECKED_OUT implies FLUSH" but that appears to be a bad assumption. For the stack trace below (obtained by setting a breakpoint at ConnectionPool line 346), the state was CHECKED_IN.
> I also filed WFLY-11037, but nobody has looked at it and this seems more like an Agroal bug at this point.
> {code}
> "default task-2" #149 prio=5 os_prio=0 tid=0x000000002315c800 nid=0x10498 at breakpoint[0x0000000035c5b000]
> java.lang.Thread.State: RUNNABLE
> at io.agroal.pool.ConnectionPool$FlushTask.<init>(ConnectionPool.java:346)
> at io.agroal.pool.ConnectionPool.returnConnection(ConnectionPool.java:252)
> at io.agroal.pool.ConnectionHandler.returnConnection(ConnectionHandler.java:68)
> at io.agroal.pool.wrapper.ConnectionWrapper.close(ConnectionWrapper.java:186)
> at io.agroal.narayana.NarayanaTransactionIntegration$InterposedSynchronization.afterCompletion(NarayanaTransactionIntegration.java:127)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization$$Lambda$711/1634329013.accept(Unknown Source)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:223)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.afterCompletion(AbstractTransaction.java:306)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> - locked <0x00000000f6201298> (a java.lang.Object)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:232)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:178)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept(TransactionalInterceptorRequired.java:53)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept(TransactionalInterceptorBase.java:88)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:47)
> at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> at com.sg.song.dls.config.unified.UnifiedConfig$Proxy$_$$_WeldSubclass.changeConfigValues(Unknown Source)
> at com.sg.song.dls.config.unified.UnifiedConfig$Proxy$_$$_WeldClientProxy.changeConfigValues(Unknown Source)
> at com.sg.song.dls.rest.ui.config.UIUnifiedConfigService.changeSettings(UIUnifiedConfigService.java:45)
> at com.sg.song.dls.rest.ui.config.UIUnifiedConfigService$Proxy$_$$_WeldClientProxy.changeSettings(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: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.ResourceMethodInvoker$$Lambda$765/920149366.get(Unknown Source)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> - locked <0x00000000f61fac30> (a org.jboss.resteasy.core.interception.PostMatchContainerRequestContext)
> 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$763/354670022.run(Unknown Source)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.SynchronousDispatcher$$Lambda$764/1839877196.get(Unknown Source)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> - locked <0x00000000f61f9880> (a org.jboss.resteasy.core.interception.PreMatchContainerRequestContext)
> 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:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 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.security.SecurityContextThreadSetupAction$$Lambda$677/604722672.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFCORE-4149) Uploading content from HAL in SSL doesn't work
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFCORE-4149?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved WFLY-11089 to WFCORE-4149:
--------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4149 (was: WFLY-11089)
Component/s: Management
(was: Web (Undertow))
(was: Web Console)
Affects Version/s: 7.0.0.Alpha2
(was: 14.0.0.Final)
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFCORE-4149
> URL: https://issues.jboss.org/browse/WFCORE-4149
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha2
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Major
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFLY-11089:
-------------------------------------
Git Pull Request: (was: https://github.com/undertow-io/undertow/commit/0193d128ea1b79d571a2ab96dc...)
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Major
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11107) [EAT] : Variable/Parameter resolution needed for JBEAP-14874
by Panagiotis Sotiropoulos (Jira)
[ https://issues.jboss.org/browse/WFLY-11107?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos moved JBEAP-15579 to WFLY-11107:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11107 (was: JBEAP-15579)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Target Release: (was: 7.backlog.GA)
> [EAT] : Variable/Parameter resolution needed for JBEAP-14874
> ------------------------------------------------------------
>
> Key: WFLY-11107
> URL: https://issues.jboss.org/browse/WFLY-11107
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> Type resolution as part of the implementation of the 4th AT Structure.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10912) CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10912?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10912:
-------------------------------------
[~mmiura] I see your point, however, it is not the responsibility of the session config to validate the incoming session ID. This happens when the session is actually requested by the servlet. In this case, the incoming session ID will be invalidated and a new one assigned.
> CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
> -----------------------------------------------------------------------------------
>
> Key: WFLY-10912
> URL: https://issues.jboss.org/browse/WFLY-10912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Final, 14.0.0.Beta2
> Reporter: Masafumi Miura
> Assignee: Paul Ferraro
> Priority: Major
>
> This issue is very similar to WFLY-10262/JBEAP-14641 but the condition causing the problem is a bit different.
> The issue happens when the client sends JSESSIONID Cookie in the request to the web application does NOT use HttpSession. JSESSIONID Set-Cookie response header should not be sent in this scenario, but WildFly/EAP 7 returns the response with JSESSIONID reusing the requested session id which does not exist in the session manager.
> The fix for WFLY-10262 / JBEAP-14641 added AttachmentKey SESSION_ID_SET to avoid invoking CodecSessionConfig#setSessionId() more than once. However, the fix does not help for this issue because CodecSessionConfig#setSessionId() is not invoked (= SESSION_ID_SET is null) before the problematic CodecSessionConfig#findSessionId() processing in this scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months