I have started a Flink Cluster via start-cluster.bat in the windows terminal.
Starting a local cluster with one JobManager process and one TaskManager process.
You can terminate the processes via CTRL-C in the spawned shell windows.
Web interface by default on http://localhost:8081/.
I was able to access the localhost URL but the Available Task Slots is given as 0. By default, it is expected to have one task (as configured in yamlfile). Anyone had a similar issue?
Have your processes started yet? It is possible that your JobManager startup failed. It is also possible that your system is running out of checks.
One possible solution:
Attach the remote JVM Debugger to TaskManager.
or: suspend=n
My Case:
FLINK_PROPERTIES=
jobmanager.rpc.address: jobmanager
taskmanager.memory.process.size: 2728m
taskmanager.memory.flink.size: 2280m
taskmanager.numberOfTaskSlots: 4
env.java.opts: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005"
parallelism.default: 4
Before:
The JobManager and TaskManager can be started normally with memory correctly configured. TaskManager log:
Starting taskexecutor as a console application on host bb166efde8f4.
Listening for transport dt_socket at address: 5005
After submitting the Job, it tries to create for about 3 minutes. And then fails with NoResourceAvailableException. Also, the dashboard show available task slot is 0.
Solution:
Set Remote JVM Debug in IDEA as follows:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 attach to remote jvm at localhost 5005
launch debugger.
submit the job.
Or you can set suspend=n instead of suspend=y in env var.
Now the available task slot is 4.
Related
I have installed HTcondor on my cluster of Dell Optiplex 390s they all are running Centos 8 and I am not able to run condor_status I get the following error --> Error: can't find collector
I am new to using condor and all I want to be able to do is have a master node that can manage jobs and execute them and for the rest to just execute the jobs. I have opened port 9618/tcp on all the nodes to run the daemon.
Ok, well there are two possibilities: One, the collector isn't running, and two, it is running, but condor_status can't find it.
Let's start with potential problem number one. If you run
ps auxww | grep condor_collector
on you machine that should be the central manager, is there a collector process running?
If so, that's good.
problem 2 is to set the condor_config variable COLLECTOR_HOST to point to this machine e.g.
COLLECTOR_HOST = my_central_manager
Bamboo-jmeter task: Should time gap there before starting the jmeter master/slave. We have created bamboo task (SSH task1-with slave host, SSHtask2-with 2nd slave host, SSH task3-with master host and run commands). When first time the the task getting an error remote engine is not able to configured whereas able to telnet the hosts, also jmeter-server is already started.
However when disable SSHtask1 and task2 for the 2nd time run, it is able to run successfully and getting results also.
Should jmeter master start after 1/2 minutes of server started? Please suggest
Able to overcome the problem by adding sleep time of 120 seconds after running the jmeter-server before starting the jmeter master.
i am facing the issue in webshpere ..the server is not staringReading configuration for server: server1
ADMU3028I: Conflict detected on port 8896. Likely causes: a) An instance of
the server server1 is already running b) some other process is
using port 8896
ADMU3027E: An instance of the server may already be running: server1
ADMU0111E: Program exiting with error:
com.ibm.websphere.management.exception.AdminException: ADMU3027E: An
instance of the server may already be running: server1
The error seems quite explicit: another program is using port 8896.
To verify this you can use these commands:
(Linux) sudo netstat -lptu|grep 8896
(Windows) netstat -a -b (or other tools)
You can decide to stop the process that create the conflict or change the ports used by WAS:
Updating ports in existing profile
This can be caused when the services don't shut down correctly and the java.exe processes hold a lock on the applications port. (8896).
To resolve this problem you can use one of the following options.
1) Open your taskmanager and end task the java.exe process for your JVM that is holding a lock on the servers port then restart the JVM from the WebSphere console
2) You can restart the physical server so the java.exe process shuts down and releases the port. Once the server starts back up you can start JVM and bring the application up.
I am trying to run remote jboss in debug mode to debug my application and i have set
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS%
in run.bat file, and am trying to start the jboss server using ant jboss.start but it is taking some time and then timing out, am not sure why this is happening, is there a way out?
Also as jboss is timing out, I would like to increase bootup time for the server, how can i do it from the command line?
Side note, server.log file does not show any messages which jboss is trying to bootup in debug mode (not sure if this would help but thought so sharing this info.)
Any clue or suggestions?
You should set:
suspend=n
in debugger startup settings.
suspend - True if the target VM is to be suspended immediately before the main class is loaded; false otherwise.
Your JBoss waits infinitely for debugger connection, this is useful when you want to troubleshoot startup issues, otherwise do not suspend your VM and let the debugger be connected any time you want.
I was frustated to get jboss started in debug mode through command line
Finally following seemed to work
1.Below should be the last line in /bin/run.conf.bat
rem # Sample JPDA settings for remote socket debugging
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS%
If there is anything below this, delete it.
2.Also when you are running jboss from command prompt please check whether -Xdebug is at the start of JAVA_OPTS.
Then it should display following message
Listening for transport dt_socket at address: 8787
3.In eclipse use 127.0.0.1 instaed of localhost.
I don't know the reason behind it...but when I changed localhost to 127.0.0.1 it worked
(Make sure you replace localhost with 127.0.0.1 at 2 locations 1.Eclipse remote debug and 2.URL while running your application in browser)
Also check project name.
Sometimes we need to change the port number.
I never had such issues with tomcat.
When I add the following Java options to enable debugging:
JAVA_OPTS="$JAVA_OPTS -noverify -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
I get the following error whenever I try to shutdown the tomcat:
ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L500]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
Thank you for a nice short explanation, PHeath! Following your advice, I found the best way to solve the problem is simply to use CATALINA_OPTS instead of JAVA_OPTS.
Looking into catalina.sh, one can see CATALINA_OPTS is only used by the "start" and "start-security" commands, whereas JAVA_OPTS is also used by the "stop" command (at least with Tomcat 6.0.33 on openSUSE 12.1).
At least if you have Tomcat installed on Linux using a package manager then modifying the CATALINA_OPTS variable in /etc/tomcat6/tomcat6.conf (or whatever path in your distribution) is cleaner than changing the catalina.sh script directly, for the package manager assumes that the user changes only configuration files and breaking this assumption may cause problems when upgrading the Tomcat packages (e. g. lost settings because the catalina.sh file is overwritten).
I think one should prefer CATALINA_OPTS over JAVA_OPTS not only for JDWP but for many other options as well: e. g. if one uses the heap size option -Xmx... then it would be reasonable to put it into CATALINA_OPTS, as the "stop" command does not need much heap.
You are trying to debug tomcat on startup, so it binds to port 5005 when the jvm starts.
When you run catalina.sh stop, it starts up another jvm which also tries to bind to port 5005.
You need to move the debug args to the run and start arguments (in catalina.sh) of tomcat, putting them straight into the JAVA_OPTS is the cause of the issue you're having.
The problem is your tomcat is still running on the debug port(5005) or some other service running on the same port(5005).
If tomcat still running, you can kill it
if it in linux environment ps -ef|grep java, and identify the process id of it. and kill the process using sudo kill -9 .
If it in windows environment got to task manager and kill the tomcat and java process.
Now you should be able to start the server in debug mood without any prob.
This can happen on debugging unit test through the tool(eclipse) which has been executed through the maven. To sole this you can flow the same process.
First close the Eclipse and kill the java process as well and start it again.
This is due to both applications are listening the same port number i.e 8000 while running in debug mode.
One quick solution is change the debug port to 8001 in startup.bat
SET DEBUGPORT=8001
It seems that the port 5005 is already in use. Check open ports with netstat command.
This may be because you already opened tomcat. Check your processes.
It appears you are starting Tomcat with the Debugger enabled, This causes the JVM to attach to the Process for Debugging, However in the catalina.sh there is a case statement for start, stop, restart, so on and so forth. Issuing the stop command still adds this in as it is part of your Global JAVA_OPTS and tries to start the debugger listening on the same port for the shutdown command. If you remove the address=50005 from your JAVA_OPTS or use the start jdpa commands to start the VM with the debugger this will fix your problem.
Look at the default catalina.sh in the latest Tomcat distribution if you need a clean copy. It sounds like someone has made changes inside yours that are invalid and causing JDPA to run on start, stop, any command issued.
set JPDA_ADDRESS=8001 in catalina.bat i.e debug port
and change all 3 ports in server.xml
In my case (Tomcat installed form tarball) I had those debug options unintentionally set in my env. This fixed the error:
$ unset JAVA_OPTS