Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Also, when the error looks like this:

 

There was an error in the diagnostic task DiagnosticLoaderJobTest, Loader job LDAP_SIMPLE__inst:community:someGroup_systemOfRecord__381b6af6779f4f03a866669339ad5afa

:Cant find a success in job CHANGE_LOG_consumer_someConsumer, expecting one in the last 30 minutes,

 

That is the threading thing I was talking about where it has trouble knowing which job is an issue.  The error is not with the first job listed, but instead it is with the second job listed.

 

Thanks

Chris

 

-----Original Message-----
From: Scott Koranda [mailto:]
Sent: Monday, November 07, 2016 9:07 AM
To: Hyzer, Chris <>
Cc: grouper-users <>
Subject: Re: [grouper-users] understanding diagnostic servlet output for loader jobs

 

> Give me a full screen copy of the status servlet, and look in logs and get full error message there.  Sometimes it fails on a job but its really another job (but threaded so it say both, if you know what I mean).  IF that doesn't help find the problem job...

>

> Maybe run this in the database:  (is it oracle?  If not you need to change the SYSDATEs to whatever else for your DB...

>

>    SELECT DISTINCT 'loaderRunOneJob("' || job_name || '");' AS script

>      FROM grouper_loader_log gll

>     WHERE     started_time > SYSDATE - 1

>           AND status != 'SUCCESS'

>           AND gll.job_name NOT LIKE 'subjobFor%'

>           AND NOT EXISTS

>                      (SELECT 1

>                         FROM grouper_loader_log gll2

>                        WHERE     gll2.started_time > SYSDATE - 1

>                              AND gll2.status = 'SUCCESS'

>                              AND gll2.job_name = gll.job_name);

 

For the archives:

 

The issue was that the copy of grouper-loader.properties in

the WS and UI deployment directories was out of sync with the

one in the "API" deployment directory (the one from which the

loader process actually runs).

 

So although there was no issue with the loader, the diagnostic servlet

was not working from a "proper" configuration.

 

After synchronizing that file across the API, UI, and WS and

restarting Tomcat the diagnostic servlet is reporting 200 OK,

the expected value based on the state of the loader jobs.

 

Thanks,

 

Scott K