Clarity

Hi Folks,

I am getting an error -NJS-0401: Execution of job failed.

The bg log message is below

BG-Log- Caused by: java.sql.batchupdateException: ORA-00001: unique constraint (CLARITY.PRJ_BLB_SLICES_U2) violated.

Version 12.1 db oracle.

Helps are appreiciated

Thanks in advance..

Renu Jacob

Hi Jacob,

This is  unique constraint error thrown by your Timeslicing job. Please in order to resolve it, refer to our KB article TEC520262:

https://support.ca.com/irj/portal/kbtech?docid=520262

Please let me know how it goes.

Kind Regards
Nika

Nika Hadzhikidi

Thanks for your reply. The solution you provided is for time slice job.I got failed the search index job.

As a workaround i restarted the bg services and for that day the job was sussessful and the next day onwards got failed status.

The job details is given below.

NJS-0401: Execution of job failed.
Scheduled job failure:
Job name:  Index contents and  documents for  searches
Run Id:        13165295
Scheduled time: 7 PM
 
 

I don't think that the "Index contents and  documents for  searches" job is affecting the time slices at all - you probably need to do some more investigation if this is a continuing problem for you.
 

Hi Jacob,

Dave is correct,the issue you are now getting with the Index contents and documents for searches isn't in any way related to Timeslices or the initial problem you reported.
NJS-0401: Execution of job failed. is a very generic error message that will get thrown for any job failure, and the reasons for the failure can be many.

To troubleshoot it, please could you check your bg-ca log for the time of the failure : You should be having the exact root cause in there.

Please let me know your feedback.

Kind Regards
Nika

Hello All,

Thanks for your help. I opened a case with CA and the resolution is given below.

1. Pause the "Index contents and documents for search" scheduled job

2. Turn off synchronous indexing in the NSA. NOTE: Make sure you restart
services after doing this.

3. Using NSA add "-Djava.io.tmpdir=c:\javatmp" to app service jvm
parameters (unless this parameter is already present)

4. Using NSA add "-Djava.io.tmpdir=c:\javatmp" to bg service jvm parameters
(unless this parameter is already present)

5. Search for and delete any files that end in write.lock on your app
server(s).
They will look something like this:
lucene-62db5567fbeaae16396e79fb8fe42895-write.lock

8. Restart app and bg services.

9. Delete the nspider and nspiderfile folders from the file server

10. Log into the app server as someone who has full control of the
filestore folders including the ability to create new folders/files like
the nspiderfiles folders

11. Run the "nikuadmin search recreate-index-data" command

12. Run the "nikuadmin search recreate-index-files" command

13. When this has completed, turn on synchronous indexing or restart the
"Index contents and documements" job.

If you are getting frequent search errors that cause you to reindex too
frequently or frequent problems with orphaned write.lock, consider running
only the synchronous indexing or only the "Index contents and documents"
job. I believe that I have seen instances where the running both at the
same time have caused more errors to occur.

Both methods accomplish essentially the same thing. All documents will be
indexed using either one. The synchronous indexing indexes documents as
they are added to the system which allows users to search for their
document or its contents almost immediately after the document is added to
the Clarity system. The disadvantage to this method is that it can provide
extra system overhead in systems where lots of documents are being added
and/or changed. The "Index Contents and Documents" job indexes documents
only when the job is run. Most customers schedule this job to run anywhere
from once every 15 minutes to once every hour. The job also does more
optimization of the index than the synchronous indexing does. The
disadvantage to this method is that users cannot search successfully for
recently added documents until the next the job is run.

If you choose to use the synchronous indexing option, I recommend running
steps 11 and 12 to recreate your indexes once every month or once every 3
months depending on how heavily used your system is. This will optimize
the index and improve the performance of your searches.

If you are using the "Index Contents and Documents" job, you do not need to
run these commands quite so frequently. Once or twice a year is probably
sufficient.