Stuck on "Loading Nexus UI" at https://oss.sonatype.org/

Hi when navigating to https://oss.sonatype.org/ the UI is stuck showing “Loading Nexus UI…” and in the top right corner (Nexus Repository Manager 2.14.16-01)

Opening the browser console, see the following errors …
nx-all.js?nexusVersion=2.14.16-01:1 An unknown error has occurred.
The following information may be useful:
“Uncaught Error: Load timeout for modules: static/js/nexus-healthcheck-base-all.js?v=2.14.16-01,static/js/nexus-smartproxy-plugin-all.js?v=2.14.16-01,static/js/nexus-outreach-plugin-all.js?v=2.14.16-01,static/js/nexus-archive-browser-plugin-all.js?v=2.14.16-01,static/js/nexus-staging-plugin-all.js?v=2.14.16-01,static/js/nexus-pgp-plugin-all.js?v=2.14.16-01,static/js/nexus-analytics-plugin-all.js?v=2.14.16-01,static/js/nexus-procurement-plugin-all.js?v=2.14.16-01,static/js/nexus-indexer-lucene-plugin-all.js?v=2.14.16-01,static/js/nexus-m2-settings-template-plugin-all.js?v=2.14.16-01,static/js/nexus-lvo-plugin-all.js?v=2.14.16-01,static/central_stat_plugin/central_stat_plugin.nocache.js?v=2.14.16-01,static/js/centralstat-register.js?v=2.14.16-01,static/js/nexus-dependency-report-plugin-all.js?v=2.14.16-01,static/js/nexus-ssl-plugin-all.js?v=2.14.16-01,static/js/nexus-capabilities-plugin-all.js?v=2.14.16-01,static/js/nexus-atlas-plugin-all.js?v=2.14.16-01,static/js/nexus-wonderland-plugin-all.js?v=2.14.16-01,static/js/nexus-siesta-plugin-all.js?v=2.14.16-01\nhttp://requirejs.org/docs/errors.html#timeout”
https://oss.sonatype.org/js/202001141459/sonatype-lib.js
2
1949
{“requireType”:“timeout”,“requireModules”:[“static/js/nexus-healthcheck-base-all.js?v=2.14.16-01”,“static/js/nexus-smartproxy-plugin-all.js?v=2.14.16-01”,“static/js/nexus-outreach-plugin-all.js?v=2.14.16-01”,“static/js/nexus-archive-browser-plugin-all.js?v=2.14.16-01”,“static/js/nexus-staging-plugin-all.js?v=2.14.16-01”,“static/js/nexus-pgp-plugin-all.js?v=2.14.16-01”,“static/js/nexus-analytics-plugin-all.js?v=2.14.16-01”,“static/js/nexus-procurement-plugin-all.js?v=2.14.16-01”,“static/js/nexus-indexer-lucene-plugin-all.js?v=2.14.16-01”,“static/js/nexus-m2-settings-template-plugin-all.js?v=2.14.16-01”,“static/js/nexus-lvo-plugin-all.js?v=2.14.16-01”,“static/central_stat_plugin/central_stat_plugin.nocache.js?v=2.14.16-01”,“static/js/centralstat-register.js?v=2.14.16-01”,“static/js/nexus-dependency-report-plugin-all.js?v=2.14.16-01”,“static/js/nexus-ssl-plugin-all.js?v=2.14.16-01”,“static/js/nexus-capabilities-plugin-all.js?v=2.14.16-01”,“static/js/nexus-atlas-plugin-all.js?v=2.14.16-01”,“static/js/nexus-wonderland-plugin-all.js?v=2.14.16-01”,“static/js/nexus-siesta-plugin-all.js?v=2.14.16-01”],“contextName”:"_"}

It seems to be working fine when I try to visit it. Maybe try clearing your browser cache? Otherwise it might be something on your machine is blocking a script (like an ad blocker or firewall).

Ok, I just navigated to the link and it’s working now without deleting cookies/etc, whatever was done or not done, it’s fixed :slight_smile:

Thanks!!!

I am running into this “LOADING UI” hanging problem consistently. Then gives error – “warning -
cannot connect to nexus”

This occurs commonly, randomly, throughout the day.

I am using Nexus 2.14.18.01.

If I keep trying, it eventually loads… but then the same problem. Is this a BUG?

Nexus logs (wrapper.log / nexus.log) show NO problems.

No. Check your system for things that interfere with requests.

1 Like

A likely culprit is any ad-blocker plugins you might be using. It’s also possible if you have a proxy server in-between your system and nxrm that it might be blocking something.

1 Like

There is nothing. (Like what specifically?)

This is from my machine directly to Nexus.

The request is making it to Nexus – Nexus is just hanging on this.

Is Nexus doing something internally?

Please advise?

Thanks both…

I wrote another posting just on this a few minutes go (separate).

Good ideas… thanks!

But.

No proxy

No VIP

No pop-up blockers.

Where is the delay coming from? When it says LOADING UI what is technically occurring in Nexus?

It’s just resolving js files and doing some initial ajax requests. You could try checking the js console to see if any of the files didn’t resolve or if there were js errors.

Ok thank you! I will look at the browser to see what is occurring.

When I learn more I will post back.

One thing – if I keep hitting “retry” the page eventually loads. But then has the same problem later in the day.

THANK YOU EVERYONE – looking at browser on my side…

It’s also possible that something on the nxrm server could be preventing it from fulfilling requests in a timely manner (perhaps a slow disk, or another process eating up CPU time or something).

Hello Sonatype Community,
We resolved our “LOADING UI / Cannot connect to Nexus” problems.
Thanks again for everyone’s help & comments.
In short: the LDAP Realm position order in NEXUS SERVER configuration was the problem.
The fix: we put LDAP below the XML realms (as mentioned in NEXUS documentation).
Summary below – Maybe the below explanation can help other people…
The problem manifested itself in a really odd way.
Regards,
~ John Dove

################################################
####### THE PROBLEM
################################################

1
Web Browsers (Firefox / Chrome / Edge) all suffered random, but frequent,
“LOADING UI… / Cannot connect to Nexus” errors. After a period of time (2-3 minutes)
Nexus behavior returned to normal. Very mysterious…

2
In a different machine architecture of build machines, our Jenkins SLAVE machines’ MAVEN java processes suffered severe (2-3 minute) lags during artifact downloads. Jenkins was so robust however, that Jenkins kept trying artifact downloads again and again, and eventually succeeded in the builds. But the Nexus lag problem was still there the whole time.

3
Importantly, when either of the above behaviors occurred (in Browser or Maven process)
then the other suffered as well. Meaning, either type of mechanism could perform the instigating requests. The fact Maven builds could trigger the NEXUS lag was a key-indicator that the problem was NOT browser-caused. That lead us to look at Nexus…

################################################
####### RESEARCH
################################################

We set the NEXUS server ROOT logger to DEBUG level.

Watched the NEXUS’ WRAPPER.LOG file.

Saw LDAP errors were getting spammed whenever Nexus was contacted.

################################################
####### THE CAUSE
################################################

The NEXUS “anonymous” user was used for all artifact download requests & browser access.

NEXUS “anonymous” user was NOT in our LDAP realm

NEXUS “anonymous” user was only inside the NEXUS’ proprietary XML realm.

LDAP was listed FIRST (at top).

LDAP failed to find “anonymous” user, and thus spammed exceptions into WRAPPER.LOG.
Randomly NEXUS would “choke” on this (for lack of better term) and performance degradation occurred horribly, which caused lag to browsers & maven builds. The browsers crashed. Maven builds waiting, retried, and succeeded.

################################################
####### THE FIX
################################################

One change. One field.

Inside NEXUS we moved the LDAP realm to the BOTTOM of the list.

XML first.

Then LDAP second.

Problem gone.

################################################
####### INTERESTING NOTE
################################################

Nexus + Jenkins performance testing did NOT reveal the above problem.
Only the browser symptoms made me aware of this dilemma.
Why?

As it turns out, Jenkins Maven build processes are extremely robust; the Maven builds worked after waiting 2 or 3 minutes and trying again. So Jenkins never made it clear there was a problem. Only the browser LOADING UI… screen made it apparent.

THANKS AGAIN FOR THE HELP IN SUGGESTIONS FROM THE FORUM
VERY MUCH APPRECIATED.
IF/WHEN INTERESTING PROBLEMS / SOLUTIONS ARISE, I WILL KEEP THIS FORUM UPDATED.
John Dove

2 Likes

Thanks for posting this very useful analysis.

No problem. Welcome.

Thanks. Just switching DarkReader to off, without even disabling the extension, immediately fixed this problem for me (Nexus Repository Manager 2.15.1-02 at Nexus Repository Manager on 2023.07.05@12:28NZST)