[JBoss JIRA] (WFLY-4437) NPE for all requests on Linux host
by Nicklas Karlsson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4437?page=com.atlassian.jira.plugin.... ]
Nicklas Karlsson commented on WFLY-4437:
----------------------------------------
The host probably runs in a VM but so does other hosts I've seen running WF. The instance is running with the same user privileges as owns the home directory so file permissions shouldn't be a problem. I don't know about SELinux etc but if that would be a problem one would think it would manifest itself more widely. Strange issue.
> NPE for all requests on Linux host
> ----------------------------------
>
> Key: WFLY-4437
> URL: https://issues.jboss.org/browse/WFLY-4437
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Nicklas Karlsson
> Assignee: Stuart Douglas
>
> I have a WF9 upstream master from a few week back running in standalone mode on a CentOS 5.2 Final with a 64bit 1.8.0_25b17 JDK.
> However, every request returns a 500 because of the NPE below. The startup/deployment is normal with no errors in the log
> {code}
> 2015-03-03 10:56:39,790 ERROR [io.undertow.request] (default I/O-1) Undertow request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:57)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:53)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:189)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:113)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:143)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:90)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:49)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {code}
> A WF 8.1.0 runs fine on the host and the same WF9 have run on other Linux hosts but I'm unable to pin down what affects Undertow in this way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4437) NPE for all requests on Linux host
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4437?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-403 to WFLY-4437:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-4437 (was: UNDERTOW-403)
Affects Version/s: (was: 1.2.0.Beta8)
Component/s: Web (Undertow)
(was: Servlet)
> NPE for all requests on Linux host
> ----------------------------------
>
> Key: WFLY-4437
> URL: https://issues.jboss.org/browse/WFLY-4437
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Nicklas Karlsson
> Assignee: Stuart Douglas
>
> I have a WF9 upstream master from a few week back running in standalone mode on a CentOS 5.2 Final with a 64bit 1.8.0_25b17 JDK.
> However, every request returns a 500 because of the NPE below. The startup/deployment is normal with no errors in the log
> {code}
> 2015-03-03 10:56:39,790 ERROR [io.undertow.request] (default I/O-1) Undertow request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:57)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:53)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:189)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:113)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:143)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:90)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:49)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {code}
> A WF 8.1.0 runs fine on the host and the same WF9 have run on other Linux hosts but I'm unable to pin down what affects Undertow in this way.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBJCA-1254) Tracer improvements
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1254?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1254:
-----------------------------------
Description:
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
* MANAGED_CONNECTION_POOL_CREATE
* MANAGED_CONNECTION_POOL_DESTROY
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
was:
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
> Tracer improvements
> -------------------
>
> Key: JBJCA-1254
> URL: https://issues.jboss.org/browse/JBJCA-1254
> Project: IronJacamar
> Issue Type: Task
> Components: Core
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Fix For: 1.2.3.Final
>
>
> Add the following events:
> * CREATE_CONNECTION_LISTENER_GET
> * CREATE_CONNECTION_LISTENER_PREFILL
> * CREATE_CONNECTION_LISTENER_INCREMENTER
> * DESTROY_CONNECTION_LISTENER_RETURN
> * DESTROY_CONNECTION_LISTENER_IDLE
> * DESTROY_CONNECTION_LISTENER_INVALID
> * DESTROY_CONNECTION_LISTENER_FLUSH
> * DESTROY_CONNECTION_LISTENER_ERROR
> * MANAGED_CONNECTION_POOL_CREATE
> * MANAGED_CONNECTION_POOL_DESTROY
> Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBJCA-1254) Tracer improvements
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1254:
--------------------------------------
Summary: Tracer improvements
Key: JBJCA-1254
URL: https://issues.jboss.org/browse/JBJCA-1254
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.3.Final
Add the following events:
* CREATE_CONNECTION_LISTENER_GET
* CREATE_CONNECTION_LISTENER_PREFILL
* CREATE_CONNECTION_LISTENER_INCREMENTER
* DESTROY_CONNECTION_LISTENER_RETURN
* DESTROY_CONNECTION_LISTENER_IDLE
* DESTROY_CONNECTION_LISTENER_INVALID
* DESTROY_CONNECTION_LISTENER_FLUSH
* DESTROY_CONNECTION_LISTENER_ERROR
Also add the ManagedConnectionPool instance information to each event, and use this for a lifecycle report
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-263:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1202610
> Cancelling management op on slave HC tree is broken
> ---------------------------------------------------
>
> Key: WFCORE-263
> URL: https://issues.jboss.org/browse/WFCORE-263
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Attachments: unundeployable.zip
>
>
> If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via:
> /host=master/core-service=management/service=management-operations:find-non-progressing-operation
> /host=slave/core-service=management/service=management-operations:find-non-progressing-operation
> Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again.
> If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive.
> Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled.
> Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBASMP-53) Support --runtime-name for deployment on server groups
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-53:
-------------------------------------
Also I'm not sure where I got this idea from because I can't find the where I'd set it with the deployment plan API :)
> Support --runtime-name for deployment on server groups
> ------------------------------------------------------
>
> Key: JBASMP-53
> URL: https://issues.jboss.org/browse/JBASMP-53
> Project: JBoss AS Maven Plugins
> Issue Type: Enhancement
> Components: wildfly
> Reporter: James Perkins
> Assignee: James Perkins
>
> The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).
> It would be nice if the JBoss Maven plugin could add another configuration parameter for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBASMP-53) Support --runtime-name for deployment on server groups
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-53:
-------------------------------------
This is the definition for the `--runtime-name`. Does this fit what you'd need?
{quote}
optional, the runtime name for the deployment. This will
form the basis for such things as default Java EE
application and module names. This would typically be the
same as --name, and if not specified the value used for
--name will be used. In some cases users may wish to have
two deployments with the same 'runtime-name' (e.g. two
versions of "example.war") both available in the management
configuration, in which case the deployments would need to
have distinct 'name' values but would have the same
'runtime-name'. Within an individual server, only one
deployment with a given 'runtime-name' can deployed.
However, multiple deployments with the same 'runtime-name'
can exist in the configuration, so long as only one is
enabled.
{quote}
> Support --runtime-name for deployment on server groups
> ------------------------------------------------------
>
> Key: JBASMP-53
> URL: https://issues.jboss.org/browse/JBASMP-53
> Project: JBoss AS Maven Plugins
> Issue Type: Enhancement
> Components: wildfly
> Reporter: James Perkins
> Assignee: James Perkins
>
> The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).
> It would be nice if the JBoss Maven plugin could add another configuration parameter for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBASMP-68) execute-commands does not work for module command
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.... ]
James Perkins commented on JBASMP-68:
-------------------------------------
I'm not sure this will be solvable as there will not be any more JBoss AS releases. I've got a PR for WildFly core to fix this so we'll have a resolution in WildFly 9.
> execute-commands does not work for module command
> -------------------------------------------------
>
> Key: JBASMP-68
> URL: https://issues.jboss.org/browse/JBASMP-68
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Affects Versions: 7.6.Final
> Reporter: Alfio Gloria
> Assignee: James Perkins
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
> <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
> <execute-commands>
> <commands>
> <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
> </commands>
> </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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:483)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> ... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> ... 23 more
> {code}
> (tested with the last snapshot too)
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFCORE-34) Move jboss-invocation & jboss-classwriter to full repo
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-34?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFCORE-34:
------------------------------------
Assignee: (was: Stuart Douglas)
Component/s: Server
(was: Modules)
This is unlikely to happen any time soon, as classes from these projects are used as part of the core server API that is used by downstream projects (namely ClassReflectionIndex). If we moved this to another module it would present serious compatibility problems for these projects.
> Move jboss-invocation & jboss-classwriter to full repo
> ------------------------------------------------------
>
> Key: WFCORE-34
> URL: https://issues.jboss.org/browse/WFCORE-34
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: Tomaz Cerar
>
> We discussed this and idea was to get rid of deps if not absolutely needed
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months