Paper UI loads things page slowly, need help to reproduce

Add-ons UIs
1

I’m seeing some odd behavior with Paper UI. I’m trying to determine if this issue is isolated just to me. Could someone who has over 100 things please try this and report back your experience? I’m seeing this on Chrome, Firefox, and Safari on a Mac. I haven’t tried it on another OS (yet).

  • Save the things configuration page URL as a bookmark, or copy it from the address bar. Like this
        http://your.host.name:8080/paperui/index.html#/configuration/things

  • Open up a new browser tab, and go to the bookmark, or paste the URL into the address bar.

  • The page loads immediately, EXCEPT for the 2nd line of each Thing (which I think is the label of the Thing Type). The Thing Type label loads one at a time. With over 100 things, it takes a minute or so before the entire page is populated.

  • I also can reproduce this behavior by doing a page refresh when on the things configuration page.

Here’s a GIF showing how it behaves on my system.
https://drive.google.com/open?id=11n6iqzYqu2kycaLi6aGL07XXz67ef69B

I’m on snapshot build 1423.

2

Are you running on OH 2.4.0 Snapshot Build # 1431 ?

I don’t have so many Things, buy I could create some dummies… don’t know if this will help

3

This is on 1423.

1 Like
4

I can spam some KNX and Astro Things etc to reach >100 but I will be able to do this tomorrow.

5

I have one system with about 30 things, and I don’t see the issue on that system.

6

Thanks!

7

My 1431 system with 32 Things works fine (refresh is immediate… it’s so fast that I don’t even see that it is performing 2 steps as in your gif) on PaperUI → Configuration → Things

8

Yeah, it’s weird, isn’t it? Normally it happens so fast you never see the 2nd line being inserted in the display.

9

i did clean the cache (or Shift+Refresh) and I do get a glimpse of the 2nd line refreshing but it’s fast

10

The other thing I noticed, if I do a page refresh while it’s loading the page, I get multiple of the dreaded An I/O error has occurred while writing a response message entity to the container output stream exception.

11

Also, in the browser dev tools, I see no network activity while it’s loading the page. So, whatever is happening is completely within the Paper UI browser app.

1 Like
12

Ok, I am wrong about this.

If I load the default Paper UI page (http://my.host.name:8080/paperui/index.html) (which goes to the inbox), it makes one request for the thing-types (http://my.host.name:8080/rest/thing-types).

If I navigate to the Configuration->Things page, it makes no request for the thing-types.

However, if I now refresh the Configuration->Things page (using the refresh button in the browser tool bar), it makes 107 requests for the thing-types. At about 1 MB each, it’s now downloading 0.1 GB (966KB x 107) of data, which takes about 100 seconds over my broadband IPSEC tunnel. If I was local, I’m sure it would be faster, but it’s still 0.1 GB of data for a single page refresh.

13

Slight correction…

I RDP’ed into a Windows box in the same location as the openHAB instance. Both openHAB and the Windows boxes are on the same network, and both have 1 GB wired connections. It still took almost 80 seconds to finish downloading all 107 of the thing-types requests. That’s odd. I’m not sure what’s bottlenecking the downloads. Maybe thread-constrained on the openHAB side?

14

No, it’s the browser’s max concurrent connections (6, I think) that’s the limiting factor. That also explains why I get 6 of the infamous An I/O error has occurred while writing a response message entity to the container output stream if I close the browser tab in the middle of loading the page.

@Dim I don’t think you need to try to reproduce this (unless you want to verify the number of thing-types downloads you see when reloading the page).

1 Like
15

FYI, I opened an issue here

2 Likes