I'm trying to follow a driver's trace but much too often an event on the other channel arrives and the trace gets messy and starts jumping back and forth, rendering the trace completely unreadable.
My example is going through a heavy user add operation while a modify user flows from the connected system. The trace goes back and forth between the events and it's hard to tell apart query results and the modify event.
Is there any way to automatically tell when it's hopping from one event to the other? Should I perhaps limit the driver to 1 thread anyways? Is that even possible? I thought about using the event-id but from what I've read so far it doesn't look too consistent and is more a "best effort" type.
On 02.09.2013 12:44:02, YLivay Wrote: > >EDIT: Ok, I took a look at it. Very basic but it get's it might get it >wrong in cases where >the IDM engine switches threads before printing an "untagged" message.
From what I understood, it spits out the untagged messages into both files because it wasn't always possible to determine which channel the untagged messages belonged to.
Definitely this could be improved on somewhat, is your splitting code also in perl?
-- If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...
The splitting code, like the rest of the util is C# and will output an HTML with some jQuery tricks to help navigate the page. Untagged lines are annoying. They can originate from both subscriber and publisher channel, custom shim implementations, remote loader etc and are not necessarily even on one of the channel threads. Ugghh...
I have a short term solution and a long term for this. The short one is extremely naive and will fail with busy drivers but otherwise it's fine most of the time: Simply compare the line's time-stamps to see if it makes more sense to belong to the last transaction or the next one.
The long one will be implemented after I've added more parsing capabilities and should be able to determine where the line goes by understanding the context. If i'm in the middle of a subscriber channel policy's action for example, I know that this line: