I'm trying to debug a Java application in Kubernetes using a Cloud Code plugin.
There is no trouble with the default debug.
I just click debug and it works, but... I don't know how to connect to application on the start.
I've tried to add option -agentlib:jdwp=transport=dt_socket,server=n,suspend=**y**,address=,quiet=y
but JVM crushed because Cloud Code adds its own option agentlib and JVM can't handle two options with the same name.
How can I edit the agentlib option for Cloud Code? (to add suspend=y) or maybe disable that option.
Or maybe there is another way to debug the application while it starts?
I've tried to add agentlib option to JDK_JAVA_OPTIONS, but scaffold(library inside cloud plugin) try to find agentlib in JAVA_TOOL_OPTIONS
I've put the option in the right place and it works well
Adding this as an answer to provide additional context.
Skaffold doesn't currently support this feature. There is an open feature request on Skaffold to add this ability.
Adding support for this has not been a high-priority item for Skaffold as suspending on startup often causes puzzling problem cascades as startup, readiness, and liveness probes time out, leading to pod restarts, and then debug sessions being terminated, and then new sessions established. And container startup problems are often more easily debugged in isolation (e.g., running as a normal Java app and emulating the Kubernetes startup through env vars, sending messages, etc).
All that said, Skaffold should respect existing -agentlib settings passed on the command-line or in JAVA_TOOL_OPTIONS. So as you found, you can pass along your own JDWP setting in your JAVA_TOOL_OPTIONS.
Related
I want to activate graceful shutdown on an existing Spring Boot (v2.3.9) app.
Initially, to test the feature out, I created a sample app and added the property
server.shutdown: graceful in the application.properties. I could see the server shutting down gracefully in the logs when I kill the app.
Satisfied with the output, I added the same property to the existing app. However, when I kill that particular app, the shutdown doesn't happen gracefully. No logs like above are produced. This made me wonder whether the property was actually getting set so just to double down I also set it as a run-time argument -Dserver.shutdown=graceful. It didn't work even after that.
I have confirmed the Spring Boot/Tomcat versions running for the existing app and they are above the minimum required to enable this property.
The existing application has a convoluted logging structure with a variety of libraries (log4j, logback etc) in the mix. Could it be the case that the graceful shutdown is happening but due to a higher logging level, the logs don't show up? If that's the case, which property should I set/override to enable them.
It was a logging issue indeed. A logging property deep inside the legacy code was overriding the outer log level. The shutdown works just fine.
Hi am working on very very old projects which contain 10 to 15 dependencies am very curious to know any tool or some utility to track flow execution of java class,method,lines,return type,get query executed while operation ..etc
for example:
if am calling soap request from SoapUI its goes into #WebService() and flow goes on..
How do I trace methods calls in Java? i have seen this link not sure how to incorporate and execute in existing project am doing manual job right now by debug with eclipse.kindly help on if way to write code or tool which i can see executions
JPDA. any decent IDE will connect to your container via JDPA protocol and allow you to debug from inside the container. you have to configure the container using some configuration switches (which get passed onto the JVM at startup time). check the documentation for you app server for how it prefers to be configured for JPDA.
I have a tomcat service with a single application, and set the following property in setenv.bat:
set JAVA_OPTS=%JAVA_OPTS% -Dspring.profiles.active=production
This uses spring-boot and ensures the application always runs in production profile mode.
Problem: I now want to drop a 2nd application in that should not run in production. How could I configure the java opts application specific?
Is that possible at all? Or would I have to create a 2nd tomcat instance?
The JAVA_OPTS variable is used by Java in the creation of the Java virtual Machine (the real process) so you can't told Java to create in one process 2 different processes.
I think the only solution will be to duplicate the web server (quite easy with most of them) and (having care of the ports !biggest problem!) running a second JVM for developing.
hope it helps
Is it possible to configure launch4j to enable remote debuggin of the resulting application depending on a command line parameter? I aware that you can achive this by having the launched application launch another java application but I would like to eliminate that overhead.
According to launch4j's documentation one can pass additional parameters to the application using a file called ApplicationName.l4j.ini.
So you could just create such a file besides your application and write the debug configuration to it (As described here):
-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=4000,suspend=n
Currently we have J2EE applications that run on WebSphere and log4j 1.x is our company's standard for Java logging. We'd like to investigate the ability to change the log4j configuration xml file at runtime so we can change to the DEBUG level, for example, when problems are identified, and return to the ERROR level once those problems are cleared up and DEBUG is no longer needed. We'd like to do all this without having to recycle the application to reread the config file.
I see that DOMConfigurator.configureandWatch() is an available method that would allow the config file to be reread at runtime. However, because it spawns a separate thread that won't be shut down when the application is shut down, it is unsafe to run in a J2EE environment.
http://logging.apache.org/log4j/1.2/faq.html#a3.6
Does anyone know if this was fixed in log4 2? I haven't found anything definitive yet from the documentation and was curious if it is safe to change the config file at runtime in J2EE.
Re-reading the configuration file is not something you want to do in production. It means that you're changing resources which many app servers don't expect to change. Development environments can get away with it on the grounds that blowing up the app server isn't a big deal. It also means that your app might behave differently if it has to be restarted.
You're going to want to change the log levels programmatically. You can do this by using LogManager.getLogger() for the packages you care about. Once you have the logger, change the level to debug, and change it back when you are done.