loadRow failure java.lang.NullPointerException after Upgrade to London

[seberly]

After upgrading to London from Jakarta we noticed our instance performance was degraded.  We can replicate reliably by navigating to Catalog Item Variables.  Other transactions are hit or miss.  For example, I can log in with ease, but my colleague waited around 20 seconds to login.

Loading the Catalog Item Variable takes around 3-4 times longer than the normal duration of a server response (based on what we're seeing in our instances that have not been upgraded to London).  Upon searching the logs, the one consistent message that seems to be a symptom is "*** ERROR *** loadRow failure java.lang.NullPointerException".  This error appears around 1,000 times within the period of 5 seconds for any given transaction where we run into the long loading problem.  In total today, this error appears in the log about 21,000 times (we've been working for just over 2 hours).

Any ideas what's going on here?

Thanks in advance!
Scott

[jank_lb_k]

For your information, I've also submitted an Incident to HI with the log being spammed with this error message. The reply from ServiceNow was, that this was fixed in London patch 3, which has just been released. And that there was no performance issue as such, only the log being spammed.

After upgrading our instance to London patch 3, the errors no longer occur in the log. So the issue seems to be fixed with this patch.

[holly-t]

We just upgraded to London patch 4 hot fix 2 and we are getting tons of these errors in the log.

[taylor21]

Hi Holly,

We also upgraded our sub-prod instances to London Patch 4 hotfix 2 and are receiving a ton of these errors.

Update: I have submitted with HI support, I'll post here if I receive any significant answers.

[taylor21]

Hi Holly,

HI Support responded regarding this issue. They stated that these errors are caused by virtual tables (v_rrd) that are leftover tables from the London upgrade. The tables are scheduled to be removed 60 days after you upgrade your instance. There is a sys_trigger job named "ASYNC: Cleanup pre-jakarta pattern table". You can wait for that schedule to kick off or you can set the date and time earlier to perform the cleanup.

I went to sys_trigger.list in my app nav and rescheduled the job for as soon as I could and that has worked to solve the issue.

[holly-t]

Thanks for the information, I just tried that and they are still continuing to happen. 😞