[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Pietro Paolini updated JGRP-2262:
---------------------------------
Description:
This is the result of an investigation I carried out for a problem we have experienced within our
application, the scenario it has been re-created by pausing the JVM using a debugger.
The discovery mechanism is JDBC_PING.
If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
This seems to be caused by the "continue" statement at
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I have prepared a simple application which can help in replicating the problem.
To replicate the problem :
1) Make sure the JGROUPSPING is empty
2) Run the application using an IDE and attaching a debugger to cause the JVM to
be paused at line Main.java:67, wait for it.
3) Run the application in non debug mode or with gradle using "gradle run" and it will
hang indefinitely
Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
was:
This is the result of an investigation I carried out for a problem we have experienced within our
application, in this scenario it has been re-created by pausing the JVM using a debugger.
The discovery mechanism is JDBC_PING.
If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
This seems to be caused by the "continue" statement at
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I have prepared a simple application which can help in replicating the problem.
To replicate the problem :
1) Make sure the JGROUPSPING is empty
2) Run the application using an IDE and attaching a debugger to cause the JVM to
be paused at line Main.java:67, wait for it.
3) Run the application in non debug mode or with gradle using "gradle run" and it will
hang indefinitely
Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Pietro Paolini updated JGRP-2262:
---------------------------------
Description:
This is the result of an investigation I carried out about a problem we have experienced within our
application, in this scenario it has been re-created by pausing the JVM using a debugger.
The discovery mechanism is JDBC_PING.
If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
This seems to be caused by the "continue" statement at
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I have prepared a simple application which can help in replicating the problem.
To replicate the problem :
1) Make sure the JGROUPSPING is empty
2) Run the application using an IDE and attaching a debugger to cause the JVM to
be paused at line Main.java:67, wait for it.
3) Run the application in non debug mode or with gradle using "gradle run" and it will
hang indefinitely
Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
was:
This is the result of an investigation I carried out about a problem we have experienced within our
application, in this scenario it has been re-created by pausing the JVM using a debugger.
The discovery mechanism is JDBC_PING.
If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
This seems to be caused by the "continue" statement at
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I have prepared a simple application which can help in replicating the problem but unfortunately I can't upload it on Jira as it complains because of a "missing token".
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out about a problem we have experienced within our
> application, in this scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Pietro Paolini updated JGRP-2262:
---------------------------------
Attachment: jdbc_test.xml
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out about a problem we have experienced within our
> application, in this scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem but unfortunately I can't upload it on Jira as it complains because of a "missing token".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Pietro Paolini updated JGRP-2262:
---------------------------------
Attachment: jgroup.zip
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out about a problem we have experienced within our
> application, in this scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem but unfortunately I can't upload it on Jira as it complains because of a "missing token".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Pietro Paolini (JIRA)
Pietro Paolini created JGRP-2262:
------------------------------------
Summary: "Frozen" coordinator causes the whole cluster to hang
Key: JGRP-2262
URL: https://issues.jboss.org/browse/JGRP-2262
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.7
Reporter: Pietro Paolini
Assignee: Bela Ban
This is the result of an investigation I carried out about a problem we have experienced within our
application, in this scenario it has been re-created by pausing the JVM using a debugger.
The discovery mechanism is JDBC_PING.
If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
This seems to be caused by the "continue" statement at
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
I have prepared a simple application which can help in replicating the problem but unfortunately I can't upload it on Jira as it complains because of a "missing token".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10227) Insufficient error when resource adapter is added with incorrect module
by Erich Duda (JIRA)
Erich Duda created WFLY-10227:
---------------------------------
Summary: Insufficient error when resource adapter is added with incorrect module
Key: WFLY-10227
URL: https://issues.jboss.org/browse/WFLY-10227
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 12.0.0.Final
Reporter: Erich Duda
Assignee: Stefano Maestri
When you try to add new resource adapter with incorrect module, the operation fails with error message {{WFLYJCA0073: Failed to load module for RA \[...\]}}. It is not clear why the loading of module failed. The error message should contain root cause why the loading of module failed. In this case the module doesn't meet the resource adapter criteria.
{code:title=Example}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=org.jboss.genericjms.provider:add(module=org.jboss.genericjms.provider,transaction-support=XATransaction)
{
"outcome" => "failed",
"failure-description" => "WFLYJCA0073: Failed to load module for RA [org.jboss.genericjms.provider]",
"rolled-back" => true
}
{code}
In the above example the correct module should be {{org.jboss.genericjms}}. The module {{org.jboss.genericjms.provider}} contains only additional jars required for connecting to the third party messaging server.
I saw that users (including me) ran into this problem here \[1\] and here \[2\].
\[1\] https://issues.jboss.org/browse/JBEAP-14299?focusedCommentId=13559726&pag...
\[2\] https://developer.jboss.org/thread/275460
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10222) Problems in a JAX-RS deployment can cause issues with reading resources from the management model
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-10222?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFLY-10222:
----------------------------------
Summary: Problems in a JAX-RS deployment can cause issues with reading resources from the management model (was: Unable lo load deployments)
> Problems in a JAX-RS deployment can cause issues with reading resources from the management model
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10222
> URL: https://issues.jboss.org/browse/WFLY-10222
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 12.0.0.Final
> Reporter: Aquiles Remon
> Assignee: Stuart Douglas
>
> I have installed wildfly 12.0.0 final, or it says the file name I just downloaded from your site. It was working perfectly. After a while, I just installed Keycloak server 3.4.3 and the corresponding adapter for wildfly. From this moment on, every time I access to my local installation of wildfly through the web console I cannot see my deployments anymore, it returned the following error:
> 12:24:44,481 WARN [org.jboss.modules] (External Management Request Threads -- 1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 12:24:44,484 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "main-project-1.0.ear"),
> ("subdeployment" => "web-toxi-0.0.1-SNAPSHOT.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.apache.hadoop.hdfs.server.namenode.web.resources.NamenodeWebHdfsMethods")
> ]): java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> I have read that this is a known issue and can ignore it; this thing is every time I need to modify or redeploy something I have to remove the corresponding tag from standalone.xml and restart wildfly server. Anyway it's working in local environment but a I have to set the production wildfly server by installing Keycloak server and its adapter and I don't know if this is going to break something; considering the wildfly is already installed (same version as mine) and working properly, but without keycloak.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10222) Unable lo load deployments
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-10222?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFLY-10222:
----------------------------------
Priority: Major (was: Blocker)
> Unable lo load deployments
> --------------------------
>
> Key: WFLY-10222
> URL: https://issues.jboss.org/browse/WFLY-10222
> Project: WildFly
> Issue Type: Feature Request
> Components: Server, Web Console
> Affects Versions: 12.0.0.Final
> Reporter: Aquiles Remon
> Assignee: Stuart Douglas
>
> I have installed wildfly 12.0.0 final, or it says the file name I just downloaded from your site. It was working perfectly. After a while, I just installed Keycloak server 3.4.3 and the corresponding adapter for wildfly. From this moment on, every time I access to my local installation of wildfly through the web console I cannot see my deployments anymore, it returned the following error:
> 12:24:44,481 WARN [org.jboss.modules] (External Management Request Threads -- 1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 12:24:44,484 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "main-project-1.0.ear"),
> ("subdeployment" => "web-toxi-0.0.1-SNAPSHOT.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.apache.hadoop.hdfs.server.namenode.web.resources.NamenodeWebHdfsMethods")
> ]): java.lang.NoClassDefFoundError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module "deployment.main-project-1.0.ear.web-toxi-0.0.1-SNAPSHOT.war" from Service Module Loader): com/sun/jersey/spi/inject/InjectableProvider
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:456)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:717)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:623)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:404)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:279)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:86)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
> at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:190)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.lambda$execute$0(DeploymentRestResourcesDefintion.java:188)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:232)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:232)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:992)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> I have read that this is a known issue and can ignore it; this thing is every time I need to modify or redeploy something I have to remove the corresponding tag from standalone.xml and restart wildfly server. Anyway it's working in local environment but a I have to set the production wildfly server by installing Keycloak server and its adapter and I don't know if this is going to break something; considering the wildfly is already installed (same version as mine) and working properly, but without keycloak.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months