Anonymous_User Absent Member.
Absent Member.
224 views

Debugging multithreaded driver


Hi,

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.

Thanks!


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

Labels (1)
0 Likes
13 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver

On 26.08.2013 10:54, YLivay wrote:
>
> 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.


It can be very difficult to read a trace from a busy driver, I
understand your problem and have experienced it myself.

> 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?


Each channel is independently threaded. So you can't really limit the
driver to 1 thread total. You will always have two channels.

> 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.


The event id is useful for tracking an event in a trace.

It was my understanding that the IDM engine will try and assign an
event-id that includes the driver which originated the change (but only
if that driver is part of the same driverset). Otherwise, it simply
indicates the server which originated the change.

Regardless, the event-id plus the channel indicator should be enough to
get you by.

Colour coding the channels can also help. I use baretail to view my log
files on windows with custom colour/highlighting rules to help make it
easier to distinguish each channel.

--
----------------------------------------------------------------------
Alex McHugh
NetIQ Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support is provided via email.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver


Problem with ID is that it is visible only in the event nds and not in
the actual trace lines,
so till you reach the end of a policy you can't be sure what event
you're tracing.

Isn't there a utility to help read logs and not only display them?


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

0 Likes
Knowledge Partner
Knowledge Partner

Re: Debugging multithreaded driver

YLivay wrote:

> Isn't there a utility to help read logs and not only display them?


Apart from the situation you just experience here, traces are really well
readable and you do not need any tool to do it.

Would indeed be *very* helpful if it was possible to have subscriber an
publisher write to separate log files. You could enter an enhancement request
for it, should'nt be too hard to implement: try http://www.novell.com/rms
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver

On 26.08.2013 12:44, YLivay wrote:
>
> Problem with ID is that it is visible only in the event nds and not in
> the actual trace lines,
> so till you reach the end of a policy you can't be sure what event
> you're tracing.


You can infer this, by looking at the channel.

There aren't multiple *active* threads within a channel, so the trace
will clearly indicate if it starts processing a new event.

When a policy requires a new thread (for example a query, or a direct
write) the context of the existing thread is saved and the thread is paused.

Then the new thread is processed and once it completes, control is
returned to the original thread.

Take a look at:

https://www.netiq.com/communities/coolsolutions/comprehending-idm-traces-part-1/

and

https://www.netiq.com/communities/coolsolutions/comprehending-idm-traces-part-2/

for more details.

> Isn't there a utility to help read logs and not only display them?


My ex-colleague once talked about writing such a util, I don't believe
he ever got beyond a prototype.


--
----------------------------------------------------------------------
Alex McHugh
NetIQ Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support is provided via email.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver


If you separate the subscriber and publisher, wouldn't
tracing queries and direct commands become a pain?

For example shouldn't a result for a query sent by the subscriber
channel
to the connected application return through the publisher channel as it
needs to go through the schema mapping, input policies etc?
(Not too familiar with IDM, didn't get to test that yet)


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver

On 26.08.2013 14:14, YLivay wrote:
>
> If you separate the subscriber and publisher, wouldn't
> tracing queries and direct commands become a pain?
>
> For example shouldn't a result for a query sent by the subscriber
> channel
> to the connected application return through the publisher channel as it
> needs to go through the schema mapping, input policies etc?
> (Not too familiar with IDM, didn't get to test that yet)


Schema mapping, input and output policies are not considered to be
exclusively part of either the publisher or subscriber channel.

An event from either channel will normally go through all three of the
components listed above.

I can see there could be advantages to the separate subscriber and
publisher channels. Not sure if it'd be worth the engine, designer &
iManager changes though. But hey, they've just recently changed the
fishbone to include startup and shutdown policies.


--
----------------------------------------------------------------------
Alex McHugh
NetIQ Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support is provided via email.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver


Oh, right - completely forgot about that.

And a simple GCV will do. After thinking about it,
there really is no sense putting two thread outputs in the same log
file.


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

0 Likes
Knowledge Partner
Knowledge Partner

Re: Debugging multithreaded driver


> I can see there could be advantages to the separate subscriber and
> publisher channels. Not sure if it'd be worth the engine, designer &
> iManager changes though. But hey, they've just recently changed the
> fishbone to include startup and shutdown policies.


Have you figured out how to make Designer show those yet? Also, do we
know the value in DirXML-Policies that they get (two ints, one
identifies the policy set/GCV/ECMA/whatever in the flow, other is order
within that set). Should update my article with the new info now.




0 Likes
Knowledge Partner
Knowledge Partner

Re: Debugging multithreaded driver


> for more details.
>
>> Isn't there a utility to help read logs and not only display them?

>
> My ex-colleague once talked about writing such a util, I don't believe
> he ever got beyond a prototype.


Hey! So did mine! And got about as far!

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver

On 26.08.2013 12:44:01, YLivay Wrote:
>


>
> Problem with ID is that it is visible only in the event nds and not in
> the actual trace lines,
> so till you reach the end of a policy you can't be sure what event
> you're tracing.
>
> Isn't there a utility to help read logs and not only display them?


Thanks to an employee of NetIQ/Novell, there is now a simple perl
script to help with this.

https://www.netiq.com/communities/coolsolutions/cool_tools/idm-engine-trace-split-tool/

You could use this in conjunction with a log viewer that can
synchronize scroll two log files based on the timestamps in the log
files so that you could quickly switch between the two channels and
retain context.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver


Awww, I already finished the splitting part, but thanks! I'll take a
look at it and see if I missed something.

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.


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver

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...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Debugging multithreaded driver


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:

Code:
--------------------
[08/22/13 15:58:40.105]:Active Directory Driver :Remote Interface Driver: Received.
--------------------

makes no sense in the current context so I add it to the other channel.
(Yes, that means i'll be implementing a "superficial" IDM engine
logic).

Again, I know in advanced it probably won't be something extremely
accurate and will not cover
weird end cases, but it's for "casual" use and i'll be adding
functionality as I go and learn more 🙂


--
YLivay
------------------------------------------------------------------------
YLivay's Profile: https://forums.netiq.com/member.php?userid=5678
View this thread: https://forums.netiq.com/showthread.php?t=48480

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.