Hello,
We have a Dev, Perf, and Prod version of an application instrumented, and in the production version we have a particular attribute of interest that I want to create a Business Transaction from.
Unfortunately I get the following when I check the details of the Servlet PurePath: <unable to query value>
This attribute works in all other environments, and this is where usernames are stored.
Here is a screenshot for context:
Thanks!
Dave
Answer by Andreas G. ·
In this case I assume that the session attribute name is wrong. It seems you have specified the class name of the object you expect in the session. However - here you have to specify the name of the session attribute, something like "userBean", "userState", ...
If you dont know what the name of the session attributes are you can specify an "*" (asterisk) in the name column of your sensor properties. This will capture ALL session attributes. This allows you to see which session attributes are available. once you have identified the correct name you can remove the * and use the correct name instead
Andreas,
I am indeed using the * character and it returns this
<unable to query value>
I am not specifying it by name at all.
-Dave
Just to clarify. You used the * for the attribute name but not for the "accessor" column in the Sensor Properties?
That's correct, I used this technique in our performance testing environment and it worked just fine.
I am not sure what could be configured differently between the two environments that would cause this unable to access behavior.
Please check the agent log files - maybe you find some information there.
Otherwise I suggest opening a support ticket
Andreas, I checked the agent logs and didn't find anything interesting, I will be opening a ticket and I will reply back with the case# and the results.
Thanks for all your help.
-Dave
hi Dave,
this message is returned when there was an exception thrown when calling this attribute's toString() method. unfortunately we currently do not log information about the exception details on any log level.
so i guess there's something special about this environment or the data in this attribute.
however, i have to say i'm a little sceptical about toString() implementations which may throw exceptions ...
hope this helps,
Christian
no, because it's an exception which originates from dynaTrace code itself.
dynaTrace only captures exceptions which originate from application code.
there is an agent debug flag which captures all exceptions and logs them to the agent log. however, this will potentially result in a lot of log spam and the desired exception may not be found easily.
anyway, if there's problems finding the toString() issue here, let me know and i'll give you instructions on how to set this debug flag.
I see, so the session state could either be encrypted, or our code could actually be disallowed from calling the two string method in this section of the code?
Sounds like I may need to talk to the application engineers (I have already talked to the operators, but it looks like elevation is necessary).
Thanks Christian.
As Christian said. The problem lies in the ToString() method that we call in order to capture this value. Best is to talk to the developers and ask them why the ToString() method cant be called on its own - why it might thrown an exception
JANUARY 15, 3:00 PM GMT / 10:00 AM ET