Skip to main content

This content is closed to future replies and is no longer being maintained or updated.
Links may no longer function. If you have a similar request, please write a new post.

Question

 Jeremy Becker (jpbecker)
Wells Fargo N.A.
Software Architect
Wells Fargo N.A.
US
jpbecker Member since 2005 34 posts
Wells Fargo N.A.
Posted: Feb 19, 2018
Last activity: Oct 5, 2018
Posted: 19 Feb 2018 15:03 EST
Last activity: 5 Oct 2018 2:17 EDT
Closed

Tracing and activity and recovering from fail

I'm trying to understand how Pega Tracer implements a lock when tracing a particular activity. I have a developer who has had an issue with a trace error and when the trace fails due to the tracer session not closing or terminated properly (due to session getting timed out or due to getting stuck for some reason), it doesn’t open again. Even switching to another node doesn't allow the user to start tracer on the rule in question. Additionally, terminating the requestor via System->Operations-> Requestor Management. We've experimented with Activity rules to see this behavior. The error message is formatted as:

"Tracer session error: This rule <rule key> is being traced by operator <operator ID> from requestor <requestor ID> - Please restart tracer."

I was able to duplicate the error received by opening a two sessions in different nodes trying to trace the same activity. The second trace attempt fails with the error message. I assume this has something to do with the architecture of how the tracer "traces" and spits the data back to a user. If I navigate to System->Operations-> Requestor Management and execute a Terminate Tracer on the first requestor from the second requestors session, I am able to pick up and trace with the second session.

(Note: I did not replicate the exact scenario my developer was seeing with a tracer fail ... this may make a difference in the ability to select Terminate Tracer, or if it's an option at all. I'm unclear what they'd be able to see in this scenario for options).

Show More

I'm trying to understand how Pega Tracer implements a lock when tracing a particular activity. I have a developer who has had an issue with a trace error and when the trace fails due to the tracer session not closing or terminated properly (due to session getting timed out or due to getting stuck for some reason), it doesn’t open again. Even switching to another node doesn't allow the user to start tracer on the rule in question. Additionally, terminating the requestor via System->Operations-> Requestor Management. We've experimented with Activity rules to see this behavior. The error message is formatted as:

"Tracer session error: This rule <rule key> is being traced by operator <operator ID> from requestor <requestor ID> - Please restart tracer."

I was able to duplicate the error received by opening a two sessions in different nodes trying to trace the same activity. The second trace attempt fails with the error message. I assume this has something to do with the architecture of how the tracer "traces" and spits the data back to a user. If I navigate to System->Operations-> Requestor Management and execute a Terminate Tracer on the first requestor from the second requestors session, I am able to pick up and trace with the second session.

(Note: I did not replicate the exact scenario my developer was seeing with a tracer fail ... this may make a difference in the ability to select Terminate Tracer, or if it's an option at all. I'm unclear what they'd be able to see in this scenario for options).

I can't see a lock in pr_sys_locks, so where is the lock being held if at all in session/memory/database?

My questions

Is there any information to confirm the tracer architecture and why you can only trace an activity from one requestor at a time?

Does it make a difference when you terminate the requestor FIRST (and are unable to Terminate Trace as it is no longer an option)? Does this somehow leave you to waiting for the system to release the trace lock on it's own?

If terminating the trace AND terminating the requestor both fail to release the lock, is the only other option to restart the node?

Where is the lock being held and can it be viewed using any Pega or database viewing tools?


Show Less
To see attachments, please log in.
Low-Code App Development

Posted: 6 years ago
Posted: 1 Mar 2018 10:21 EST
Jeremy Becker (jpbecker)
Wells Fargo N.A.
Software Architect
Wells Fargo N.A.
US

Any news on this thread? It has happened intermittently in our Dev environment and is hard to recover from without restarting the node which is obviously not the best solution.

To see attachments, please log in.
Posted: 6 years ago
Posted: 21 Mar 2018 0:05 EDT
Jeff Houle (HOULJ) Senior Software Engineer
Pegasystems Inc.
US

I've reached out to some folks about your question, and so far there are some questions from them:

  1. What version of Pega are you using?
  2. What type of rule(s) are you tracing. Any Service rules?
  3. Have you seen/used the options in the System Management Application (SMA) under "Logging and Tracing? You may find a "Clear All Rule Watches" option that could help.
To see attachments, please log in.
Posted: 6 years ago
Posted: 21 Mar 2018 8:17 EDT
Jeremy Becker (jpbecker)
Wells Fargo N.A.
Software Architect
Wells Fargo N.A.
US

This isn't something that happens often, but when it happens it does present us occasionally with a productivity halt until it is resolved for the developer in question.

1. We're on 7.3.1

2. Flow, Task, Activity, UI, Connector ... no Service rules.

3. No. I will pass along that suggestion should this happen in the future.

Am I to assume then that the "lock" placed on a rule being traced and/or the singular instance of a Trace session isn't something I can see or refer to anywhere?

To see attachments, please log in.
Posted: 6 years ago
Posted: 21 Mar 2018 10:50 EDT
Jeff Houle (HOULJ) Senior Software Engineer
Pegasystems Inc.
US

I believe your assumption here is correct. I am not the highest authority on this topic, but my earlier response was influenced by those who work in this area more often than I do, and they did not mention any way of viewing the locks.

To see attachments, please log in.
Posted: 6 years ago
Posted: 1 Oct 2018 14:03 EDT
Martin Delira (Martin Delira)
Boeing Employees Credit Union
Software Engineer
Boeing Employees Credit Union
US

Hi jpbecker. 

Have you found a solution for this? We are also on 7.3.1 and this is very frustrating. I would appreciate it if you could share any updates on this. 

Thank you

To see attachments, please log in.
Posted: 6 years ago
Posted: 4 Oct 2018 10:20 EDT
Jeremy Becker (jpbecker)
Wells Fargo N.A.
Software Architect
Wells Fargo N.A.
US

Hey Martin,

What you see here is what you get. None of the Pega resources that replied to the post identified a better way to deal with these issues than what is documented here. Using the System->Operations-> Requestor Management will occasionally fix the issue (see earlier in the post) and restarting certainly fixes things. The Pega resources that replied on the post mention an SMA option (Logging and Tracing -> Remote Tracing; then Clear Rule Watches). We never had an opportunity to try this as a possible solution to the problem we had, as it never returned and we were unable to duplicate it. Additionally, as we're all being told that SMA is on the outs I don't know that this is going to be replaced or added to the functionality they are making available in the Developer portal itself.

Best,

J

To see attachments, please log in.

We'd prefer it if you saw us at our best.

Pega Collaboration Center has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice