NullPointerException in UpdateIndexJob.getAndMarkPendingUpdates during solr update

[Former Member]

Every time we run HMC->System->Indexer Operation Wizard -> update we get the following stacktrace in the log. Does anybody know why?

 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.946 | FATAL [Cluster 0: Lucenesearch-UpdateIndex-Job::de.hybris.platform.lucenesearch.jalo.UpdateIndexJob] (Cluster 0: Lucenesearch-UpdateIndex-Job) [Job] Caught throwable null
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.965 | java.lang.NullPointerException
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.969 |     at de.hybris.platform.lucenesearch.jalo.UpdateIndexJob.getAndMarkPendingUpdates(UpdateIndexJob.java:376)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.981 |     at de.hybris.platform.lucenesearch.jalo.UpdateIndexJob.performCronJob(UpdateIndexJob.java:250)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.989 |     at de.hybris.platform.cronjob.jalo.Job.execute(Job.java:1297)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:20.996 |     at de.hybris.platform.cronjob.jalo.Job.performImpl(Job.java:815)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:21.003 |     at de.hybris.platform.cronjob.jalo.Job.access$1(Job.java:772)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:21.008 |     at de.hybris.platform.cronjob.jalo.Job$JobRunable.run(Job.java:677)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:21.015 |     at de.hybris.platform.util.threadpool.PoolableThread.run(PoolableThread.java:198)
 INFO   | jvm 1    | srvmain | 2014/11/26 23:02:21.023 | 

[Former Member]

Any clues to how we might resolve this?

[Former Member · Accepted solution]

After a check with Hybris, it seems that this is caused by a crash in the job, which holds old data to index and crashes trying.

Here is a fix that worked for me:

1. Disable all UpdateIndex jobs (Example: Cluster 0: Lucenesearch-UpdateIndex-Job ; Cluster 1: Lucenesearch-UpdateIndex-Job)

2. Manually run the first RebuildIndex job (Example: Cluster 0: Lucenesearch-RebuildIndex-Job )

3. Check for index updates: Run the FlexibleSearch query via the hac: Select * FROM {IndexUpdate} The list should be empty; or only contain items created recently. If not, continue with point 4. Otherwise, go to point 6.

4. Manually delete updates: Run the ImpEx statement via the ImpEx import console in the hac:

   REMOVE IndexUpdate[batchmode=true];itemtype(code)[unique=true] ;IndexUpdate

5. Check for index updates: Run the FlexibleSearch query via the hac: Select * FROM {IndexUpdate} The list should now be empty; or only contain items created recently.

6. Enable and run the UpdateIndex jobs one by one (enable 0; run 0 ; enable 1 ; run 1 ; etc.)

Hope this helps!

[Former Member]

Problem still present in hybris 5.7 ... Does anybody have any clue on this ?

[Former Member]

Ditto 5.7.0.3

 FATAL [Cluster 1: Lucenesearch-UpdateIndex-Job::de.hybris.platform.lucenesearch.jalo.UpdateIndexJob] (Cluster 1: Lucenesearch-UpdateIndex-Job) [Job] C
 aught throwable null
 java.lang.NullPointerException
         at de.hybris.platform.lucenesearch.jalo.UpdateIndexJob.getAndMarkPendingUpdates(UpdateIndexJob.java:376)enter code here

[Former Member]

Hello.

I have the exact same issue that the original poster has asked. The excact same stack-trace.

I have examined this issue a little bit and it seems that the implementation of UpdateIndexJob does not check for null-pointers.

In the function "getAndMarkPendingUpdates" things are called and return-values are never checked.

Now, it seems that at some point a return-value is atually a null-pointer and then operations on this null-pointer obviously will cause this unhandled null-pointer exception.

Can anyone from the Hybris-team possibly evaluate why stuff in the getAndMarkPendingUpdates-Function could possibly become null-pointer?

What excatly has to happen, under what condition?

This flooding the logs and it is bothering me. What is the issue here?

PS: We are using Hybris-Version 4.8.17.

Edit: You are probably better off just setting the CronJob (UpdateIndexJob) to inactive. It's useless and apparently buggy. And noone will ever respond or offer any fix here, so just go do it.