We are using Spring XD for executing some batch jobs and considering to use Spring Cloud Dataflow. For this I wanted to remote debug a execution of a Task and I was not able to make it working.
I tried to export the following environment variable before the SCDF server is started:
spring.cloud.deployer.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Also tried to pass as argument in the GUI while invoking the task:
app.<appname>.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Nothing seems to be working.
I'm able to debug the composed-task-runner launched by SCDF using the listen debugger mode, this will also work for your task as well.
Run Debugger in your IDE in listen mode on port 5006. (this project's classpath should have composed-task-runner sources, put break point some where )
Run SCDF with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 option, attach debugger to the SCDF process in your IDE on port 5005 (attach mode).
Put breakpoint at this line :
String javaOptsString = getValue(deploymentProperties, "javaOpts");
in JavaCommandBuilder class (for spring-cloud-deployer-local v.1.3.0.M2 it's line #83).
Launch your task - debugger stops at breakpoint.
Step Over once in your IDE, the value of javaOptsString is null now. Using IDE, set the value of javaOptsString to
-agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y
Press Resume in IDE.
Your breakpoint set in #1 should be hit in few seconds.
If you know how to pass javaOpts as deployment properties of your task - you will be able to debug in listen mode without this nightmare ;-). I've not found a way to escape = and , characters in the -agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y javaOpts deployment property.
We are working on an improved solution for the local-deployer - you can follow spring-cloud/spring-cloud-dataflow#369 for tracking purpose.
There is, however, the following option that exists to aggregate all the application logs into the server console directly, which might be useful while in active development.
stream deploy --name myStream --properties "deployer.*.local.inheritLogging=true"
Finally I was able to remote debug a composed task or regular task. Follow the below steps:
In scdf UI go to tasks and click on the definition section
Click play button (invoke) on the task/composed task that you want to invoke.
On the launch task page define your task arguments
Add the following properties by clicking 'Add Property' button:
- deployer.composed-task-runner.local.debugPort=12103
- deployer.composed-task-runner.local.debugSuspend=y
Now launch the task
You can now see in the log that when the composed task's java process is launched it is called with the debug parameter.
If you want to control the heap memory or any java options you can do by adding the following property:
deployer.composed-task-runner.local.javaOpts=Xmx2048M
Note that 'composed-task-runner' is the name of the App (Not the name of the task).
Related
I have set
spring.cloud.deployer.local.workingDirectoriesRoot=D:\\Deploy
in application.properties to define log folder.
However, It does not works, the log of task when I launched is written on java.io.tmpdir (C:/..../temp/).
I am using spring-cloud-dataflow-server-core version 2.3.0.RELEASE
Does I need to put these config in dataflow-server.yml ?
How can I configure the log folder of SCDF and their tasks?
We just added some tests for windows and noticed that correct format (assuming task name is timestamp) which actually works on windows when using drive letter is:
deployer.timestamp.local.working-directories-root=file:/C:/tmp
Think is how in a spring world binding works from String to java.nio.file.Path. For those interested to know more, It's spring core's PathEditor which uses Paths.get(URI), thus need for file:.
The property workingDirectoriesRoot is a local deployer property and not an application property. Hence, it needs to be passed when launching the task.
task launch <task-name> --properties "deployer.<task-name>.local.workingDirectoriesRoot=D:\\Deploy"
I face the following problem: whenever i try to start Jetty with an application instance i need check if the application is running. I need to do that from an ant target.
I want to have something behaving like the following pseudocode:
**
<target name="target1"
depends="run-jetty-with-application"
description="Target1">
<--when run-jetty-with-application is ok(jetty is up and application is running)-->
<antcall target="target2"/>
<--end when-->
</target>
**
I should also mention that i have no publicly exposed urls that could give me the status of the application.
I'm not after the hacky solution like waitfor.
Thanks in advance!
There are only 2 ways to know if Jetty is started, all webapps are deployed without error, all lifecycle is started successfully, and the server is available to serve content.
Periodically ask for a resource on that web app, confirming that it is up and running. (timeout with failure if resources doesn't make itself available after a period of time)
Hook into the LifeCycle.Listener on the Server component, wait for the .lifeCycleStarted(LifeCycle event) for the server, then walk the entire handler tree, looking for any Handler component that failed to deploy via the DeploymentManager.
As you can imagine, the first technique is the easiest.
This is the <waitfor> facility in Ant, and is what the Jetty project itself uses.
The second approach requires a custom Ant task.
You can either write it yourself, and know that it will do what you want. Or use the jetty-ant tasks with daemon mode to get almost the same thing (the JettyRunTask in daemon mode starts up the server, but it does not wait for start to finish or the webapps to deploy successfully before it returns control to ant).
Whenever a specific Windows service fails I want to run a program I've created myself. However, I simply can't find a way to make it fail on purpose, so that I can actually test that everything works correctly.
Note that the service in question is not something I've written myself, so I can't make it fail programmatically from inside the code. I wouldn't, however, mind writing a program that can make a service fail.
Of course I would prefer just having a "Make service fail" button somewhere in services.msc ... ;)
The server I'm doing this on is running Windows Server 2012.
If you don't want to use command line :
As an admin open the Windows Task Manager, in the Services tab find the service you want to test. Right click the service and click on Go to process. The selected process (if any) is the one corresponding to your service. Kill this process to simulate a service failure.
Be aware that killing a process this way can lead to problems.
Define "fail". If you want the process to end, just use pskill or a similar tool that can terminate a process elevated (as an admin).
I am thinking the modified dlls will create a log file some where in the remote system so I can open it later after load test but all I found was a log file in $(SystemRoot)\Temp\EQATECProfilerLogs saying nothing other than app started. Do I need to install EQATEC profiler on the remote server?
Thanks
This scenario is adressed in this EQATEC forum thread:
A profiled app needs to be told when we want it to produce its profiling report. For plain apps this is simple and has therefore been automated: when Main exits. But your web-service has no similar "exit point" - it just keeps on running until you kill it.
Therefore you have to explicitly/manually tell the profiled web-service to take a snapshot. The easiest way is to simply run the profiler on the same machine as the web-service is running on: when the web-service is starting up it will automatically connect to the profiler and you can then run your tests and control/dump timing info at will using the "take snapshot" and "clear counters"-buttons.
Alternatively, you can make a reference to the supplied runtime-module from within your code and make explicit calls to the API (TakeSnapshot etc) precisely where you want in your code. The runtime-modules reside in C:\Program Files\EQATEC\EQATECProfiler\RuntimeDLL.
I have a few Windows Services written in C# that I have setup to support being run from the command line as a console app if a specific parameter is passed. Works great but I would love to be able to detect whether the app is being run by the service control mananger or from a command line.
Is there any way to tell at runtime if my app was started by the SCM?
Environment.UserInteractive will return false if the process is running under the SCM.
The SCM will call your OnStart method, so you could mark that event and make sure when you run from the command line, you don't call OnStart. Or, you could check the startup parameters to see how the application was started.
In C the function StartServiceCtrlDispatcher() will fail with ERROR_FAILED_SERVICE_CONTROLLER_CONNECT. This is the best way in C, wonder if C# exposes any of this?
ERROR_FAILED_SERVICE_CONTROLLER_CONNECT
This error is returned if the program is being run as a console application rather than as a service. If the program will be run as a console application for debugging purposes, structure it such that service-specific code is not called when this error is returned.