Did anyone encounter this error on any of your WAS monitored applications?
This application is running on a WAS 7.6 (which is not supported, I know) but all other monitored applications work fine. I even searched for other uses of the "ebanking.framework.filters.EncryptionFilter.doFilter" method that generates this issue and all others work. Except this one.
I have to mention that this WAS process was formerly monitored with AppMon and had no issues. Yesterday we deactivated the AppMon agent and installed OneAgent on the host.
Do you guys have any ideea on how could I resolve this?
Root causes for requests that failed with HTTP 500 - Internal Server Error
100 % were caused by javax.servlet.http.HttpServletResponse.setStatus
Exception messages of javax.servlet.http.HttpServletResponse.setStatus
HTTP ***** setStatus called
Stacktraces of exceptions
My take on this is that the presence of our agent in a stacktrace is not usually indicative of us causing the problem, but simply a side effect of our code being hit while intercepting the the information we gather in the code. Are you suspecting us of causing the exception and not just reporting it?
Indeed, the last execution that is faulty is the "java.lang.Thread.getStackTrace". My logic was that doFilter triggered the IBM wrapper which called setStatus which is monitored and called updateResponseStatusOnTraceTag and that called the getStackTrace, but I now realize that getStackTrace could just be the actual cal from setStatus.
I was suspecting DT could be the culprit but I wasn't sure.
I agree with Dave, just because we're in the stack trace does not automatically implicate our agent.
In this situation the stack trace tells us the thread was processing a web request, specifically setting the response status code. Dynatrace instruments this code to fiddle with this response and immediately a stack trace is involved, which makes me suspicious that in this situation we are the root cause of the exception.
I would open a support case, but since WAS 7.6 is not supported, this makes it challenging and likely they won't work your case.
Actually, there was an issue yesterday on the application that uses that particular service (application which is not yet monitored with Dynatrace) and it turned out that the problem is not caused by this service.
I reanalyzed the stacktrace and it makes sense what you're saying.
I thought of opening a support ticket but firstly WAS7.6 is not in the supported matrix and secondly the issue is not affecting anything (as far as we know). I am going to do some digging inside the application logs to see if these issues occurred before OneAgent was there thus clearing our (Dynatrace's) name :).