ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
Captain
Captain
514 views

Remote Loader Cache - Get Cache file view and see statistics

Hi All,

We have IDM version 4.5 (on Linus OS) and we have a JMS driver connected to Message Queue system via Java remote loader. Its a UniDirectional (From Message queue to IDM).

From iManager when we see the statistics, there are no events pending. But when we see the Remote Loader logs, we see the events are getting processed (sent to driver and getting response back slowly) continuously for long time.

Question 1:
We are unable to find whats the current RL cache events, statistics like we see it iManager. Is there a way that this can be done?

Question 2:
Also, we see that the events are very slow in processing. Like from the logs we could see that for 1 min it processes 10 events. Can the JMS driver performance be improved.?

please help.

thanks
dk
Labels (1)
0 Likes
4 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

On 11/21/2018 12:24 PM, dkdng wrote:
>
> From iManager when we see the statistics, there are no events pending.
> But when we see the Remote Loader logs, we see the events are getting
> processed (sent to driver and getting response back slowly) continuously
> for long time.


There is no such thing as a generic cache for the Publisher channel within
IDM for any driver. Each driver works in a different way depending on how
its application publishes events to IDM. For example, LDAP environments
may have a changelog, which means the "cache" is actually within the LDAP
environment itself, and the LDAP driver knows how to ask the changelog for
the next event. eDirectory's so-called "bidirectional" driver and the
microsoft active directory (MAD) driver work a similar way. Relational
databases have a couple options, either a table of changes for a triggered
setup, or a driver-managed set of intermediate tables for a triggerless setup.

JMS environments are their own caches as well, or at least have been in my
experience, and the driver queries for the next events from the queue.
Usually that slowness for any driver is because of the time waiting for
the previous event to be completely processed, which can be delayed even
more because of a high trace level.

> Question 1:
> We are unable to find whats the current RL cache events, statistics like
> we see it iManager. Is there a way that this can be done?


iManager only shows statistics for the subscriber channel because that is
the only place there is really a cache. As a result there is nothing to
see anywhere else, other than watching events as they come in via a trace.

> Question 2:
> Also, we see that the events are very slow in processing. Like from the
> logs we could see that for 1 min it processes 10 events. Can the JMS
> driver performance be improved.?


That's definitely slow compared to the norm, but depending on what the
driver is doing that could also be as fast as it can go. Please post a
trace, level three (3) or higher, from the engine side and Remote Loader
(RL) side too of the same events if possible. Seeing a few events back to
back will help see where the delays are.

For example, a common reason for slowness on the Publisher channel (for
any driver) is in tie taken to run matching policies. If you match based
on names, so the system must do a search based on surname and giveName, a
lack of index for those attributes can make the search for a user, whether
found or not, very slow, wasting seconds per event. If you have multiple
matching attempts, even shorter delays per search can, combined, waste
seconds per operation. Because the channels only process on event at a
time per channel, this can mean the channel overall is slow at processing
unassociated objects.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

dkdng wrote:

> Also, we see that the events are very slow in processing. Like from the
> logs we could see that for 1 min it processes 10 events. Can the JMS
> driver performance be improved.?


Check your trace levels.

As Aaron already mentioned, higher (engine side) trace levels slow down event
processing a lot. I've seen cases where level 3 was 10-40x slower than level 0
(which is what you should be using in production unless troubleshooting an
issue).

Remote loader trace levels have usually less impact, but I the JMS shim may be
an exception, so play with it to verify.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

> events are very slow in processing.

PS: if your driver does searches in IDV (matching, queries from policies) you
may want to check your indexes as well. Engine side trace level 2 should reveal
if the response time to IDV queries is unusually high.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Lothar Haeger wrote:

> PS: if your driver does searches in IDV (matching, queries from policies) you
> may want to check your indexes as well. Engine side trace level 2 should
> reveal if the response time to IDV queries is unusually high.


....as Aaron already said. (note to self: read all post completely before
replying...)
______________________________________________
https://www.is4it.de/identity-access-management
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.