We have successfully installed both Wildfly 10.0 and Wildfly 10.1 in Windows system (Windows 10 and Windows server 2008/2012) as a service but when we try to stop it this operation fails.
If we try to stop it from Windows Service Manager we get error 1053, instead if I launch service.bat stop from <WILDFLY_ROOT>\bin\service I get the error "Failed to load service service_name configuration". In both cases service remains forever in "Stopping" state in Windows services manager.
I now there are some documented issues like this but I have already done many trials.
In my service.bat for Wildfly 10 I have set both JBOSSUSER and JBOSSPASS variables to be used in shutdown command and I set them both with the ones used for Wildfly management console (I know that not setting up management console will prevent Wildfly from being stopped) and with a real Windows ones (my login account in Windows). I know they are correctly used as CREDENTIALS for shutdown when running .bat file.
That does not work.
Moreover, I thought the problem was caused as we have both JDK 6 and JDK 8 installed. JDK 8 is to run Widlfly while JDK 6 is still (unfortunately) used to develop our software. I set JAVA_HOME variable in jboss-cli.bat file to JDK 8 but that does not work too. For sure, java -version command prints 1.8.0_171 and echo %JAVA_HOME% commands prints path to jdk1.8.0_144
How can I solve this?
Related
Situation: I installed JRE 8, and configured Tomcat 8.5 on my Eclipse Neon.3 Release (4.6.3).
Problem : I added a project and the server console shows server start-up in 41935 ms. But the background process keeps showing "Starting...." This is shown in the ScreenShot below.
Later, the server stops because it times out. Please help me resolve this.
I don't know how this worked, but merely restarting the PC and cleaning Eclipse's Tomcat server solved this issue.
Also, if at any point of time there is a Security alert asking permission to allow Java to access Public or Private networks, check all the boxes.
This can happen if already an instance of Tomcat server is running on the port(default is 8080). Kindly run below command in command prompt
netstat -ano
to list down the list of process and the port they acquire that are running currently and see if there a process running on the Port that your tomcat server is trying to acquire.
If yes, kill it and run the server again
had the same problem with Tomcat 7 (Liferay server), seems to be a compatibility bug in eclipse, I had to change to a lower version of eclipse.
Background:
I am currently working in a Linux Virtual Machine on some Java plugins that I install into Eclipse by placing them into the /opt/eclipse/dropins folder. My plugins need to support both CentOS 6 and CentOS 7 VMs (shouldn't be a big deal since they are written in Java and both flavors of CentOS have Java 1.8.0 installed). My plugins build and install just fine on both OSs. I see them in Eclipse and can interact with them as expected.
The VMs I need to support can either be local to my machine (opened with VMWare Player/Workstation) or hosted on a cloud server. We use Windows Remote Desktop to get into the cloud VMs through xrdp on the Linux server.
Problem:
One of my plugins needs nddsjava.so from /opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2.
On both local VMs (CentOS 6 and 7), I can just set the LD_LIBRARY_PATH in an /etc/profile.d script so that any user that logs in can get the path to the required C++ library.
On CentOS 7 cloud VMs, however, when this plugin is invoked, I get java.lang.UnsatisfiedLinkError: no nddsjava in java.library.path. This happens only when opening Eclipse via the Linux menus. If I open a terminal and start Eclipse from there, the plugin can find the C++ library (because my LD_LIBRARY_PATH is set in my /bin/bash terminal). I did a little digging and found out that running chmod g-s /usr/bin/ssh-agent fixes the issue when opening Eclipse from the Linux menus (yes I understand that the chmod opens a security vulnerability. I am willing to look past this).
On CentOS 6 cloud VMs, I have never gotten the plugin to find the C++ library. LD_LIBRARY_PATH seems to get wiped when signing in through xrdp and for whatever reason, CentOS 6 appears to be explicitly not sourcing any of the profile scripts in the main top-level gnome-session process, which means other processes spawned from the GUI will not have LD_LIBRARY_PATH either.
I have also tried adding -Djava.library.path to my eclipse.ini file with no luck. It will fail on the next C++ library needed even though it lives in the same directory: java.lang.UnsatisfiedLinkError: /opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2/libnddsjava.so: libnddsc.so: cannot open shared object file: No such file or directory
Question:
Is there a single place that I can set my LD_LIBRARY_PATH for all flavors of Linux I am attempting to support (local CentOS 6, xrdp CentOS 6, local CentOS 7, and xrdp CentOS 7)?
Note: When I say cloud VM below, I mean server hosted VM in which I Windows-Remote-Desktopped into via xrdp.
This answer from server fault worked for me in the CentOS 6 cloud VM. The CentOS 7 cloud VM did not have the startwm.sh script in /etc/xrdp. Instead, it lived in /usr/libexec/xrdp and did not contain the xinitrc lines (referenced in the server fault link) causing the issue in the CentOS 6 cloud VM. Something else must be wiping the LD_LIBRARY_PATH variable in the CentOS 7 cloud VM, so I still needed to perform chmod g-s /usr/bin/ssh-agent to allow my /etc/profile.d script to be invoked on startup.
When I unzip the wildfly-10.1.0.Final.zip file on my computer at home. Then WildFly starts running automatically. I had verified this through going to localhost:8080. Because of this I can't run my Java EE project on Netbeans (I have added WildFly as server in Netbeans). In the logs I see:
Address localhost: 8080 is already in use
I also can't shutdown WildFly through the following command:
$ ./jboss-cli.sh --connect command=:shutdown
However I can shutdown WildFly by killing his process. But this still doesn't fixed my issue on Netbeans. Because I still get to see: Address localhost: 8080 is already in use.
At my work when I had unzipped the wildfly-10.1.0.Final.zip file. It didn't start automatically I also had no problems with running my project on WildFly. And I also can shutdown WildFly through the command line or Netbeans.
Anyone that maybe knows how I can fix my WildFly server problem on my computer at home?
Which version of NetBeans are you using ? Until 8.2 WildFly 10 isn't correctly identified.
You may try NetBeans 8.2 RC1 from https://netbeans.org/community/releases/82/ or a nightly build as this would fix your issue.
NetBeans checks if there the instance is already running before trying to start it, so you don't have to start it beforehand but you can :)
I am using Eclipse Galileo and I have the BEA WebLogic Server v.10 installed.
The problem that I am facing is that the server cannot be stopped anymore(running in debug mode).
For example it shows the progress bar of stopping until 93% and after that it gives the message "The server cannot be stopped within timeout."; I can only restart eclipse in order to start again the server.
In the console I see the message:
"C:/bea1001/jrockit_150_11/bin/java -classpath C:/bea1001/wlserver_10.0/server/lib/weblogic.jar weblogic.Admin -url t3://localhost:80 -username weblogic -password 12345678 FORCESHUTDOWN AdminServer
Server "AdminServer" was force shutdown successfully ..." -
But it seems that something is blocking to stop the server.
Can anyone tell me what I can do?
p.s. I tried to delete and create a new server in the eclipse but I still have the same problem
Thanks and regards,
Luisa
I have found the problem: I changed the port of the BEA WebLogic to be 80 and this port was used also by Skype.
I changed the port of the Skype and now the server stops
Luisa
I've had the same problem and another solution may be to start Eclipse with java command (in my case Weblogic was running as java.exe, but Eclipse as javaw.exe). Also check if the same version of JDK is used for running both Weblogic and Eclipse.
We have a Java process which we run as a Windows service (using srvany). It runs with Java 1.6 (1.6.0.23 at the moment).
In the past (Windows XP), I could connect JConsole to the processes, on Windows 7 I cannot do this anymore.
If I run jconsole <pid> I get “Invalid process id:4488”. The services are running as SYSTEM user.
If I make the service run as my desktop user (using “Log On as This Account”) the services process ID appear in JConsole, but they are grayed out and I cannot connect.
Is it impossible to dynamically connect to Java processes when they are running as a Windows 7 service?
Perhaps it is a 64bit/32bit problem, I have several applications compiled with 32bit JDK, which could not be opened with JConsole from 64bit JDK on Windows 7 64bit, after I downloaded the 32bit JDK it worked.
Others have been able to run jstack on 2008r2 which may provide some insight on how to get jconsole to connect on Windows 7. As you noted in your comment, the permissions are important. If the service and jconsole can't access the temp directory to write to the appropriate hsperf subdirectory, it won't work. What is also important is the location of the temp directory, the user the service is running, and the user that is running jconsole.
Running SysInternals psexec -s -i <jdk_home>\bin\jconsole <PID> can be used to run jconsole as Local System, the same user that I believe you are using to run your service.
My experience running jconsole from JDK 1.5 in Server 2008 as a system user was unsuccessful. With permissions that I thought should have been sufficient, I got a Could Not Open PerfMemory error. Java 1.6 may be a different story.
In light of all the challenges with running jconsole locally, you would probably have better luck setting it up to accept remote connections. You could set it up for local-only access with your firewall blocking that port from external access.
Add the following to JAVA_OPTION
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then,
Use JConsole to connecet remote session:
localhost:8086
I am currently facing the same problem but on Windows 2003 R2 (SP2). There is on open bug in Oracle Bug database (bug id 6399729)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6399729
Also there is a work-around posted towards the end. It talks about installing java in "install" mode :-), but didn't work for me on Windows 2003 though. But your mileage may vary!!
Change Environment Variable TEMP and Tmp to a different folder that you created.
Like c:\theTemp
It might be a problem with the folder %TMP%/hsperfdata_{USER_NAME}.
In my case, it worked after I :
close all applications running over the JVM
delete the folder %TMP%/hsperfdata_{USER_NAME} (exemple: C:/Temp/hsperfdata_MyUser)
reopen JConsole (it recreates the folder)
Hope it helps. You can also take a look at this thread in Oracle community.