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

[seberly]

So, how long does it take you to load an item_option_new record?  Do you see any lag in loading the list of tables when creating a new report?  Thanks!

[Rolf Nyhus]

Apologies, got a little side tracked on another topic, thus this horribly late response.

About 10 seconds to load an item_option_new record. No noticable delay for list of tables loading when creating new report.

Though it seems according to jankølbek's response below that the issue indeed is fixed in patch 3.

[seberly]

Rolf,

No worries on the delay.  10 seconds is still a bit unacceptable in my opinion, but it is better than what we are seeing.

After upgrading to Patch 3 in our dev instance we are still seeing performance issues.  Here's a sampling of load times on our instances (these are average times in seconds):

• dev (release: LP3) - 13632 (we've still seen as bad as 30445 after the upgrade to P3)
• test (LP1) - 39609
• sandbox (JP9) - 4310

I still see it too when loading the drop down on the report UI when selecting a table.

Thanks,
Scott

[Rolf Nyhus]

Scott,

I assume your numbers are in millisecond, otherwise your instances really have major issues.

As our 10 second delay is on the backend only (not end user facing), it has not been prioritized.

If we patch up in the near future I'll post back with results.

Thanks,

Rolf

[ABouland]

I too received a response from HI today.

re: errors as a result of running report - support indicated this matched those described in PRB1302760. Setting property "glide.ui.list.optimize" to false may suppress the errors. However, the longterm fix is set to London Patch 3

re: errors as result of accessing catalog variables - support indicates this issue matches PRB PRB1193055. Because of this PRB, unnecessary tables are being loaded up which cause the load time to go up. This PRB is also set to fixed in London Patch 3.