dT 4.2 - Filters on Exception Sensor Property doesnt work as expected
Hello,
This is with regards to Exception Sensors.
For an agent group --> under sensor config --> exceptions --> property, we have:
Exclude all but include these:-
javax.faces.application.ViewExpiredException --> Match Equals
org.springframework.webflow.execution.repository.NoSuchFlowExecutionException --> Match Equals
However looking at the exceptions dashlet we are seeing exceptions that include the 2 mentioned above and few others that don't match the definition:
Ex:
com.sun.el.parser.ELParser$LookaheadSuccess
org.apache.el.parser.ELParser$LookaheadSuccess
org.apache.lucene.queryParser.QueryParser$LookaheadSuccess
My understanding is, please correct me, if we configure the exceptions sensor to Exclude All and Include “javax.faces.application.ViewExpiredException” and “org.springframework.webflow.execution.repository.NoSuchFlowExecutionException” then it shouldn’t capture other classes.
While I do have a support case open, just looking for a 2nd opinion. I did check the Exceptions KSP and dint find these classes subscribed there.
Thank you for your help.
Srikar
hi Srikar,
the rules basically look fine, but there's something i forgot to mention: you see in the exception method rule the pattern '<init>'?
so this pattern is only working for constructors. if you have '<all methods>' as a pattern, it will only handle methods except constructors.
so you basically exclude all methods, but not the constructors from these classes, but we're only interested in them.
so please edit these exclusion method rules and switch the radio button from 'method' to 'constructor'. then you should be all set!
hot sensor placement should be enough, a JVM restart should generally not be needed.
and the active/inactive setting does not matter at all for exclusion rules. it's only important that they are placed!
best,
Christian
Christian, a long overdue THANK YOU for helping me on this.
The only other change (other than changing type to Constructor) was to set the visibility to public/default/private/protected and now we are gathering only the required exceptions.
Once again Thank you for your help.
Srikar
hi Srikar,
Andi's right, thoser are actually no Exceptions, but Errors. and there was a known issue, which is fixed in dT5.
before dT5, the best way to deal with that would be to place exclude rules (no global exclude rules) in the exception sensor pack at the very beginning (in client debug mode).
best,
Christian
Hi Christian,
Thanks for your input...I tried "exclude" for the different exception classes on the Exception sensor pack and placed it high on the list, then did a hot sensor placement.
However looking at the deployed sensor for the agent (after performing a HSP), we still see those exception classes being subscribed. Dashlet still reports on those excluded classes.
I will try recommending a jvm restart to see if that changes anything.
Thanks,
Srikar
Thanks Andi,
Do you think an exclude / global exclude on those exception classes (that we don't want) would work? The end goal being only catching the exceptions from the above mentioned classes.
I will update once support gets back.
Hi
I do remember a known issue in 4.2 where we didnt exclude these types of Exceptions because they are from a different base type than Throwable. I do believe this was fixed and should work in dT5. But - please get the confirmation from support
Andi
