Discussion Feed

Devika,   It sounds as if the agent may not be capturing all the thread hand-offs in your application scenario.   There could be several explanations for this.  Can you post a screenshot of the waterfall view of a snapshot?   Are you using an asynchronous client driver to talk to some backend (maybe a database?) that we do not support out of the box?  That might provide an explanation. (it's important to note that in general peformance issues in applications build using  asynchronous frameworks such as Vert.X often do not manifest as slow code running, but rather as long waits for replies from external services)   It will probably be easiest for you to open a support ticket and work through the detail with our support team to identify what is missing if none of the above is helpful.   Warm regards, Peter ... View more

Sailesh,   You should not need to, since agent logging and application / container logging should be entirely separate.  If you find that not to be the case, I would really appreciate it if you could file a ticket, or post full details of your scenario.   That said, you can switch the agent back to using log4j by setting the  appdynamics.agent.log4j2.disabled system property to true, but you should not need to do this.   Warm regards, Peter     ... View more

There were issues with how a few of the early 4.5.x agents used log4j   This issue is fixed in any recent 4.5.x agent (the most recent is 4.5.11)   If you experience the same issue with v4.5.11 of the agent, please create a new post with details, or open a support ticket.   Warm regards, Peter ... View more

Pranay,   What do you see in the agent log you will find in the  "/home/ec2-user/apache-tomcat-7.0.82/webapps/appagent/ver4.5.9.25648/logs/<nodename>" directory   (where <nodename> is the name of the node you configured)   You will likely find some explanation of what is happening in here.   Warm regards, Peter. ... View more

Vikas,   I am beginning to wonder if your scenario is a JVM crash (i.e. the JVM terminated, due to a JVM bug) or a terminal out of memory error due to insifficient headroom in the heap.   For the JVM crash case, you will see a Fatal Error Log.  If you have one of these, please share it.   For the out of memory case, you should see one or more java.lang.OutOfMemory exceptions in the application logs.  Alternatively, if you see no out of memory exceptions logged, you could double confirm that memory headroom is not the root cause by setting the JVM to heap dump on out of memory and making sure there is no heap dump created.   If you do find a fatal error log, you will need to try and match the symptoms in the log with known JDK bugs.  The fix for out of memory would be to increase Xmx to allow additional operating headroom.   Warm regards, Peter                 ... View more

Vikas,   1.8.0_91 is extremely old (dating from April 2016) and there are a huge number of bug fixes in the subsequent releases.   Experience shows that JVM crashes of this kind are almost always fixed by upgrading to the latest JVM version, so I would recommend you try that (and make sure to pay attention to Oracle's licensing changes)   Warm regards, Peter     ... View more

OK, so the good news is that we have established that your agent installation is fine.   Does your spring boot application work fine when the agent is loaded via the command line?   What does the "jps -v" command show when it is running?   It might be easier to troubleshoot this via a support ticket if we don't uncover anything via the above suggestions. ... View more

Sorry, my mistake, I reversed the options.   What happens when you run:   "java -javaagent:D:/Applogs/appagent/javaagent.jar -version" ... View more

Do you see any agent logs written under D:/Applogs/appagent/ver4.x.y.x/logs/<nodename>?   What happens if you run "java -version -javaagent:D:/Applogs/appagent/javaagent.jar"  from the command line? ... View more