Hi All,
I’ve activated audit log to trace some strange behaviors of our stack, but analyze it by hand is a really hard stuff.
Mainly I’d like to follow the flow execution, start, finish progression using contexts (root,parent,current) but as-of-now I’ve to do tracing lines on a paper sheet…
Is there some tool to do this (And something more, too)? I know Monitor and portal could help me in this task, but we do not have them installed, and our logging is on filesystem, not on a database (yet).
Sandro,
I’ve only ever looked at the context items in the session logs. There is a way to tie them together once you know how each field is used. I tried to build a reporting mechanism around this. I stopped just short of going insane… although some people would disagree with that.
We typically use the auditing so we can review the data in Monitor. It also allows us to resubmit if we need to. I suppose you could have a writePipelineTo File step in the service so that you could later step through the flow service with the actual data.
Why don’t you start a thread on exactly what you’re seeing and see if anyone can advise you on that.
Hi Randy,
I’m stuck in a strange concurrency issue: we fire in different thread come processes, and they callback to a single re-entrant service (let’s call it RS). RS checks if subprocesses had problems, and if none it execute another step.
Sometimes, RS checks subprocesses and identify an error never happen! Since the subproc status is written in a database, I think there is a timing issue in write result & RS check.
Thus, using audit log (to trace services execution) could help me in identify the error. Sadly, read “by-hand” audit log is a pain… So, a helping tool would help.
Hello,
If the db table you are using is a custom item, you may want to setup a three-state check. At the start of each sub process, they good from initial (maybe ‘norun’) to a wait (maybed ‘pending’) to a final (maybe ‘success’ or ‘fail’). that way the callback knows to keep waiting and sleep for all values to join to a final state. You could also build a polling application that could allow you to see this and tell which process are taking longer to change state. Good day.
Hi Yemi,
indeed we trace as you say the services execution. The issue is that (I suppose) the final state of some subprocesses is written after the check of called-back service. I simply don’t know how it’s possibile, since first the state is written, then the subprocess is marked as “closed” then the callback service is invoked.
It’s for that reason I’d like to have analyze audit log, to find the concurrent issue.