migrate from 7.1.11 to 7.6.1: loading-spinner doesn't stop spinning

Hi there, after searching one day for a solution I’ve to ask the experts …

I’m currently migrating an old and large Vaadin-Ap that already had some Migration-Steps (to V-6, V-7.1) in it’s live. The most things are already working w/o the loading-spinner.

After loading I find the following state:

<body class="v-generated-body v-ff v-ff20 v-ff200 v-gecko v-win" scroll="auto">
<div id="xxxui-94427748" class="v-app xxx xxxapplication">
<div class="v-ui v-scrollable" tabindex="1" style="width: 100%; height: 100%;">
<div class="v-loading-indicator third v-loading-indicator-wait" style="position: absolute; display: block;"></div>
<div id="vaadinStartseite" class="v-verticallayout v-layout v-vertical v-widget light v-verticallayout-light app-header v-verticallayout-app-header v-has-width v-has-height" style="position: absolute; width: 100%; height: 100%;">
</div>
</div>
<script src="./VAADIN/vaadinBootstrap.js?v=7.6.1" type="text/javascript">
<script type="text/javascript">
<iframe id="com.yyy.xxx.ui.DefaultWidgetSet" src="javascript:""" style="position: absolute; width: 0px; height: 0px; border: medium none; left: -1000px; top: -1000px;" tabindex="-1">
<div id="xxxui-94427748-overlays" class="v-app xxx xxxapplication v-overlay-container" aria-live="assertive" aria-label="This content is announced automatically and does not need to be navigated into." aria-relevant="additions">

so it looks like I’ve “simply to remove” the “v-loading-indicator-DIV” (if I do that inside the firebug it works but then the loadingindicator is gone forever …). Unfortunately if I leave it spinning it blocks my UI forever.

So: What shoud I do?

Note: The same code worked with V-7.1.11.

Thanks for help, Volker

… too less information? …
seems to have to do with LoadingIndicatorConfiguration - but how to remove the state “is Loading”?

… if I manually set the following I get the behavior I’d expected. But I had to do that several times. So there seems to be something broken with updating this div …

[code]

[/code]to [code]
[/code]

Finally i found it. I was still using a deprecated class ProgressIndicator where ProgressIndicator.setPollingInterval() was called. Using UI.getCurrent().setPollingInterval() solved the problem.

I am having the same problem after upgrading to 7.6.+, i.e. the spinner does NOT stop, but I don’t want to use setPollInterval() as I want to avoid any excessive server traffic. It was OK in pre-7.6 versions.

Me again: Enabling Polling has a side effect: If you click on a scrollbar move it and hold the bar clicked you get in fact disconnected from the scrollbar if the poll has taken place. I do now work around the workaround using the following snippet that enables polling for a couple of seconds and disables it afterwards:

[code]
public class Loader implements Runnable {

public static void load() {
UI.getCurrent().setPollInterval(500);
new Thread(new Loader()).start();
}

@Override
public void run() {
try {
Thread.sleep(5 * 1000);
} catch (InterruptedException ignore) {
}

UI.getCurrent().access(new Runnable() {
  @Override
  public void run() {
    UI.getCurrent().setPollInterval(-1);
  }
});

}
}
[/code]and place a
Loader.load()
everywhere I get the spinning spinner.
There is a pattern for getting the spinner: I get it often in cases where I close a window that was opened in front of a long-loading background.

Better solutions welcome! But it seems that there’s not much interest … :frowning:

got the same problem with the interrupting scrollbar. but i don’t want to use the workaround because it seems too hacky to me. maybe an expert got another soulution for that?

my workaround above fails if there are concurrent threads that enable/disable polling in parallel.

for now I use

[code]
[…]

public static final int defaultPollingIntervall = 20 * 1000;
public static final int shortPollingInterval = 500;
private static List<Date> pollRequests = Collections.synchronizedList(new ArrayList<>());

[…]

public static void load() {
Date now = new Date();
UI.getCurrent().setPollInterval(shortPollingInterval);

// store actual request to deal with concurrent requests
synchronized(pollRequests) {
  pollRequests.add(now);
}

// wait $defaultPollingInterval/2 and check, if we want to reset the polling (i.e. if there's no other active
// polling request)
new Thread(new Runnable() {
  @Override
  public void run() {
    try {
      Thread.sleep(defaultPollingIntervall / 4);
    } catch (InterruptedException ignore) {
      // ignore
    }
    UI.getCurrent().access(new Runnable() {
      @Override
      public void run() {
        synchronized(pollRequests) {
          pollRequests.remove(now);
        }

        // remove entries that are older then $defaultPollingInterval (or better: replace the list of polling
        // requests with the ones that are newer then $now - $defaultPollingInterval)
        Calendar cal = Calendar.getInstance();
        cal.setTime(now);
        cal.add(Calendar.MILLISECOND, - defaultPollingIntervall);
        synchronized(pollRequests) {
          pollRequests = pollRequests.stream().filter(p -> p.after(cal.getTime())).collect(Collectors.toList());

          // if there's no further polling request left: reset polling to default
          if (pollRequests.size() == 0) {
            UI.getCurrent().setPollInterval(defaultPollingIntervall);

// } else {
// System.err.println("open requests: " + pollRequests);
}
}
}
});
}
}).start();
}
[/code]this works acceptable but is still ugly.

Hey Vaadin - is there no better solution?

It might be related to this which was fixed in 7.6.5:

https://dev.vaadin.com/ticket/19684

I was having similiar issues before updating

I’m currently on 7.6.4 - so I’ll give it a try … but tomorrow.

Thx. Upgrading to 7.6.6 fixed the “endless-loading-spinner” problem. This makes polling unnessesary again and I’m happy.

But! If I use polling it still breaks the scrolling as described above. Fortunately I don’t need it anymore.