I am deploying a WebApplication with several separate war and ear-files to a wildfly 10.1 server.
What I do is this: I clean the deployments, data/content and tmp folder, then copy all necessary war and ear files into the deployments-folder.
Then, I start the Server either in Debug-Mode via Spring Tool Suite 3.8.1 (basically Eclipse Neon) or directly via standalone.sh.
The server starts up normally, gets deploys all projects and publishes this message:
[org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 326001ms - Started 5819 of 6193 services (642 services are lazy, passive or on-demand)
The next message that follows, roughly half a second later, is the first Unregistered web context-message, followed by a general deployment stop.
There is no message in the log connected to this, neither an ERROR, nor a WARNING, SEVERE or FATAL in sight.
After stopping all Deployments, the server still runs, but no context is reachable.
When deploying the applications one-by-one, the server accepts, deploys and keeps running, which leads be to believe that there is something wrong with the server itself.
the memory-relevant VM-Arguments are these: -Xms1024m -Xmx4096m.
The server does not run on a timeout, as that has been thorougly tested and produces error messages.
Okay, long story short: comment was solution.
The parameters deployment-timeout in standalone.xml and jboss.as.management.blocking.timeout as command line parameter do work together on the same thing, considering blocking the command line parameter seemingly has precedence.
So if both values are set, and the management blocker is higher than the deployment-timeout, the following happens:
Deployment is started
Deployment timeout triggers
Management timeout still has time left and does not trigger to stop the server
Applications deploy within the management timeout period.
The After-Deployment Scanner checks the deployments directory for failures
Deloyment-timeout marked all deployments as failures
All Deployments are being undeployed as they are faulty
So: No error message, Deployment as usual, followed by instant undeployment. Should anyone else have that, check those values.
Related
Tomcat version: 8.0.47
Tomcat is running as a container using: "FROM tomcat:8.0.47" in the Dockerfile.
Tomcat starts up and is able to serve my web application with no problems.
After approximately 7-10 minutes, I get a 502 server error:
Error: Server Error
The server encountered a temporary error and could not complete your
request.
Please try again in 30 seconds.
When I check the container ps -ax, I still see tomcat process running.
When I check catalina logs, the last log line: INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 72786 ms
When I check application-specific logs, there are no errors.
My expectation: How do I figure out what is wrong and why is it silently dying whilst the process is still active? There is 7 minutes of proof that the application & tomcat was deployed correctly since it works with no problems in the first 7 minutes of start up?
So I am deploying my REST webservice... Normally I always had it locally hosted on my own computer, but now I am done with the application so I want to host it for real, yet I am stuck deploying it, it keeps on saying: deploying...
So locally it works, but now I've added a remote server and I've tested it with a blanco webservice, and that does work.
Does anyone know what is going on? Because there is no error at all...
BTW I have tested to deploy it with the admin site thing, the [website]:4848 > application > deploy > [add war] --- but that crashes as well... after like 30 seconds of nothing, the webpage says: The connection was reset.
No clue what it is, but if anyone else sees this in the future, where they cannot deploy their webservice, because it takes forever, here's the solution:
Copy your .war that you have build onto the server
./asadmin deploy (For glassfish 4.1, this is located in the [main directory]/bin)
Fill in all information needed
That's it :) I don't like it either, but at least it's a way to deploy!
I want to check some cli commands if they are valid from java. I cant use the config file I'm currently running on. Additionally I can't use a running Wildfly at all, since I would have to do reloads every now and then.
So I want to use offline-cli (cli with embedded server)
What I'm doing:
Connect to CLi using org.jboss.as.cli.scriptsupport.CLI
CLI cli = CLI.newInstance();
cli.connect("127.0.0.1",9990,"admin","admin".toCharArray());
starting an embedded server via cli.cmd
cli.cmd("embed-server --server-config=standalone.xml --std-out=discard");
But apart from me waiting forever for this command to finish (?) nothing happens.
One thing I noticed was, after deploying my application configuration-management.war to wildfly, state changes to "deployed". But then, a service fails to start. I did not pay much attention to it, because after that I can see an output from my application. Maybe this has something to do with it?
2016-06-29 15:59:55,333 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 83) WFLYUT0021: Registered web context: /configuration
2016-06-29 15:59:55,364 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0016: Replaced deployment "configuration-management.war" with deployment "configuration-management.war"
2016-06-29 15:59:55,364 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."configuration-management.war".POST_MODULE
2016-06-29 16:00:29,530 INFO [stdout] (default task-1) this is mine!
All there is is just that little spinning wheel of death at the upper left corner of my mozilla firefox, indicating that I'm still waiting for a response.
Any hints?
When you start an embedded server it doesn't start any interfaces. This includes the management interface. It doesn't look like the script support allows for embedded CLI. You could file a feature request to support it though.
However you can use the CLI CommandContext API to achieve this.
final CommandContext commandContext = CommandContextFactory.getInstance().newCommandContext();
commandContext.handle("embed-server --jboss-home=/path/to/wildfly-10.0.0.Final");
commandContext.handle(":read-resource");
commandContext.handle("stop-embedded-server");
Do note some command, like module add, will require the jboss.home.dir system property to be set as well.
I am working on an web application deployed in tomcat, the problem I am facing is neither it is allowing me to add to tomcat server nor it is allowing me to run on debug mode.
To debug an application running on an external tomcat, set that tomcat to allow remote debugging, e.g. with JVM params like this:
-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n
Then create a new remote "Remote Java Application" debug config, select connection type "Standard (Socket Attach)" and provide host and port (in the example above the port would be 8787).
To run and debug a Java web application in Eclipse, you need to have a dynamic web project. The error message in your screen shot implies you haven't one. Have a look at the excellent tutorials of Lars Vogel:
http://www.vogella.com/tutorials/EclipseWTP/article.html
I am trying to set up JBoss 4.2.2 and JConsole for remote monitoring. As per many of the how-to's I have found on the web to do this you need to enable jmxremote by setting the following options in run.conf. (I realize the other two opts disable authentication)
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=11099"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
Which results in the following exception:
13:06:56,418 INFO [TomcatDeployer] performDeployInternal :: deploy, ctxPath=/services, warUrl=.../tmp/deploy/tmp34585xxxxxxxxx.ear-contents/mDate-Services-exp.war/
13:06:57,706 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:57,711 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,070 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,071 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,138 ERROR [MainDeployer] start :: Could not start deployment: file:/opt/jboss-4.2.2.GA/server/default/tmp/deploy/tmp34585xxxxxxxxx.ear-contents/xxxxx-Services.war
java.lang.NullPointerException
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.getPublishLocation(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:103)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
...
My application uses JWS which according to this bug:
https://jira.jboss.org/jira/browse/JBWS-1943
Suggests this workaround:
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
(https://developer.jboss.org/wiki/JBossWS-FAQ#jive_content_id_How_to_use_JDK_JMX_JConsole_with_JBossWS)
I've tried that however that then throws the following exception while trying to deploy a sar file in my ear which only contains on class which implements Schedulable for a couple of scheduled jobs my application requires:
Caused by: java.lang.NullPointerException
at EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.hash(ConcurrentReaderHashMap.java:298)
at EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.get(ConcurrentReaderHashMap.java:410)
at org.jboss.mx.server.registry.BasicMBeanRegistry.getMBeanMap(BasicMBeanRegistry.java:959)
at org.jboss.mx.server.registry.BasicMBeanRegistry.contains(BasicMBeanRegistry.java:577)
Any suggestions on where to go from here?
EDIT:
I have also tried the following variation:
JAVA_OPTS="$JAVA_OPTS -DmbipropertyFile=../server/default/conf/mbi.properties -DpropertyFile=../server/default/conf/mdate.properties -Dwicket.configuration=DEVELOPMENT"
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
I'm using JDK 1.6.0_01-b06
I have honestly never tried this remoting approach. But, if both your client machine and the server happen to both be linux boxes or similar *nixes with SSH, then you can ssh -XCA to the server and start JConsole on the server and have the GUI display on your client machine with X port forwarding. A JConsole running locally to the server JVM you want to monitor should not have any trouble connecting.
I personally think that's a nifty trick but I realize that it dosn't really solve the problem of getting JConsole to connect remotely through JWS.
First thing I would do is to delete both /tmp and /work directories under JBoss /default and redeploy the WAR. If that doesn't, I would upgrade the JDK to use a more recent version of 1.6. 1.6.0_01 is pretty old.
I'm not sure if there's a specific reason you're trying to use WS to access the mbean server, but with JConsole you can directly access a remote JVM. To do this use "service:jmx:rmi:///jndi/rmi://<remote-machine>:<port>/jmxrmi" (where <remote-machine> is whatever machine your trying to connect to and <port> is 11099) as the remote process.
I have used this to connect to any 1.6 JVM that exposes an mbean server (JBoss, ActiveMQ, etc).
I don't know if this is related, but JBoss has a tendency to redirect to itself. If you connect to a host, say jboss.localdomain:3873, wanting to connect to a ejb, JBoss might lookup its own hostname and redirect to the address it gets from there. If you have a public hostname, it might find that instead (say jboss.publicdomain.com), and tell the client to reconnect to jboss.publicdomain.com:1099. Depending on your DNS, this might or might not be a reachable address from your client.
There are various varations of this problem, and as a bonus, sometimes the initial "connection check" works, so the client app deploys, but fails later on connect.
Had a similar issue, but with JBoss Seam: take a look at JBSEAM-4029. As one of the workarounds it suggests to override the class running into the NPE - in Seam's case the JBossClusterMonitor.
I bet the JWS code is running into exact same issue, i.e. ending up calling MBeanServerFactory.findMBeanServer(null) at some point in time. The stack trace should reveal which exact class does this.