Query Widget says "Data is inaccessible" after cold start

[CameronLacelle]

Spent a day and a bit configuring a Query Widget in an Experience Builder my team is creating for our end users. Got everything in the Query Widget working fine and come in the following Monday morning after the weekend and load up the Experience Builder in view mode to find that a few (3-5) layers are throwing errors in the Query Widget and say "Data is inaccessible". I turn on visibility for those layers in the map and they seem to work fine (symbology, labelling, pop-ups all working). So I refresh the Experience Builder view and those layers are fixed now, but now 3-5 other random layers show the same issue as the previous ones did. After refreshing several times the same thing would happen (previous layers worked fine again in the widget but a new set of layers said data was inaccessible and showed a big red 'X'). Then all of a sudden one refresh everything was working fine again and subsequent refreshes showed no errors.

We are working with Registered/Referenced data on our Portal we share from ArcGIS Pro (mostly SQL data, eGDB, some shapefiles, but all sources are registered with the server). We are using a dedicated instance configuration option as opposed to shared instance when we shared our layers to Portal as we expect heavy usage out of this app and its data when it's complete and sent to our end users. I am wondering if this error shown by the Query Widget could have something to do with the dedicated instance having a slower "cold start" than a shared instance, or if anybody has had a similar issue and has any insights. We would rather our app not throw random errors when it is in operation across our organization.

[JakeSkinner]

Hi @CameronLacelle, what version of ArcGIS Enterprise are you running?

I wouldn't think this would be related to additional instances starting up.  Dedicated instances, by default, have a minimum of 1 instance running.  If there are multiple requests at the same time, it will spin up another instance, which may just take slightly longer.  But, the maximum time a client will wait to get a service should be set to 60 seconds by default.

You could check the Statistics in ArcGIS Server Manager > Logs > Statistics.  For example, you can review if there are any timeouts, and also the average/max response times.  I usually compare the avg response times to the Service Maximum Running Instances.  If there are large avg response times, this is a good indication you need to increase the max instances for the service(s).

[CameronLacelle]

Hi @Jake thanks for your reply,

We are on 11.3. Unsure when we will move to 11.4, that's beyond my decision-making.

I wouldn't think so either. We only recently switched our layers for this application from shared to dedicated instance to improve speed (which has worked nicely) but now running into these odd issues that I cannot figure out a pattern. Checked our logs and there are no messages, and all statistics look fine. However, I noticed on the Services tab of our Server Manager that many of the services that are used in this particular Experience Builder have 2 of the instances running but 0 in use?

This Data is inaccessible error has also resurfaced again in the last 20 minutes or so as it was when I originally posted this question.

[CameronLacelle]

[JakeSkinner]

@CameronLacelle when you are viewing the exp application, are there any errors reported in the Network tab of the web browser's Develop Tools (ctrl+shift+I is a shortcut to open this) for the services?  You can filter the rest services by searching for /rest/services:

[CameronLacelle]

No errors reported, just did a couple refreshes to see if anything came up. Right now the Query widget isn't showing any of those errors from before (but I am sure they will show up again). I will try to catch them in the dev tools logs when they occur next.

I did however see some errors pop up in the console. Seems these are related to a particular layer which is odd, I'll have to investigate because I've not seen any errors or warnings (aside from big integer fields or coordinate system warnings when sharing from Pro). See below:

[CameronLacelle]

 t

[CameronLacelle]

@JakeSkinner Saw this error this morning in dev tools and those layers had the same issue in the query widget that this original post was for, and the layers would not draw. But when I refresh the page again it's fixed.

[JakeSkinner]

The error message "net::ERR_INSUFFICIENT_RESOURCES" in the context of Experience Builder applications typically indicates that the browser is facing resource limitations while trying to load or run the application. This error can occur due to various reasons, such as:

1. Memory Usage: The browser may be running out of memory to handle the resources required by the Experience Builder application.

2. Too Many Open Connections: The browser may have reached the limit on the number of open connections needed to load the application components.

3. Large Application Size: Experience Builder applications with a large number of widgets, complex layouts, or heavy media content can strain browser resources.

4. Network Issues: Problems with the network connection or server-side issues can also contribute to this error.

Is the problem reproducible on all client machines?