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

[Patrick Boutet]

Same problem after upgrade to London

Performance degradation observed too

[Manolis Sgouro1]

Hello,

Same problem here.

Almost 6.5k logs per day. Just wanted to let you know and to follow up the discussion.

If you have any feedback from /Hi, please let us know.

Cheers,

Manolis.

[Manolis Sgouro1]

Hello Again,

I found the following in /hi:

Rafael Buria (NOW)

Additional comments•

2018-10-17 10:22:42

Enzo, 

As pointed by Pedro, the behavior is relevant to problem record PRB1302760, I'm attaching this incident to this problem record now. 

We are indeed seeing other customers experiencing the same behavior, and at this point in time, we cannot see any direct impact to users, other than errors in the logs. 

As mentioned previously, the workaround is to create a new system property ( glide.ui.list.optimize ) and set its value to "false". This property has corrected the issue in some instances, but in past versions of the platform, we have seen performance impacts associated with it. We don't advise on the use of this workaround. 

At the moment as we haven't see any impact other then errors in log, we can just ignore the property workaround and wait until a resolution is determined for the PRB. 

if you decide to test the workaround, you need to change the property first in a sub-production instance, troubleshoot thoroughly and then determine if you wish to apply the workaround in production. 

Best regards, Rafael

I hope that helps you.

Cheers,

Manolis

[rosa8]

We are having similar problems with the London upgrade, both error messages and performance issues. We have also opened an Incident on HI and are still waiting for a response.

Rosa

[Rolf Nyhus]

Let me share my update from the HI ticket I have registered.

I too got told to create the system property "glide.ui.list.optimize" and set it's value to false. This did not alleviate the errors, and I was then directed to update a script include (https://hi.service-now.com/kb_view.do?sysparm_article=KB0655906). Neither this did solve anythig.

Upon further HI investigation I got the following response:

"our development team has confirmed that this is not actually related to the previous problems i have mentioned but rather a new one PRB1308349, i have associated with this incident and replicated it on an OOB instance. The errors are triggered when a filed of type Table Name is present on a form , the errors are not impacting the behavior of the platform and the root cause has been fixed in London Patch 2 HotFix 2and in our next release Madrid, i would recommend to upgrade to one of these releases in order to benefit from the fix. There is no workaround available for this problem. The fields of Type Table Name are present under the Type Specification section of the item_option_new form."

Interestingly, the version I upgraded to was indeed London Patch 2, HF 2. So again I challenged HI support. I then got this response:

"i can see the problem states it was fixed in London Patch 2 HotFix 1 and normally the fixes are forwarded to the next release. It might be that for some reason this was not forwarded as per the normal process, i will followup with the development team and provide another update."

then...

"it appears that the fix for this particular problem has skipped a couple of releases, however our development team has confirmed that this will be available in London Patch 4 release, at this time i am not sure when this will be released however considering that patch 3 is not yet out, i would recommend to upgrade to the particular release when it will be available. Until that time you can remove all Table Name type fields from forms in order to stop the error, however as the error does not actually impact the behaviour i would recommend to disregard it at this time."

As I have not seen performance impact on my system, I will for now opt to follow the recommendation and simpy ignore the errors. Based on the above, it would seem that P2HF1 should work if you're able to move to this, otherwise you will have to wait for future fix like me.