netcreateorg / netcreate-2018

Please report bugs, problems, ideas in the project Issues page: https://github.com/netcreateorg/netcreate-2018/issues
Other
11 stars 2 forks source link

EnterApp() Lifecycle Error #132

Closed benloh closed 3 years ago

benloh commented 4 years ago

Joshua reports:

Packaged builds: It turns out the packaged builds don’t work 100% and this causes problems for some students. If you go to this one I am hosting: http://www.joshuadanish.com/nc/Prok/#/ … what happens for me is that sometimes it loads just fine, and sometimes a blank white screen (what one student is indicating he sees on both versions). My console output is attached. If I load and it works, I find that if I hit reload I then get the error after a reload or two. But it’s quite consistent. I am assuming some sort of race condition and maybe on a students’ slower computer it happens more often, though when I tried adding network lag and latency via chrome it didn’t make it any more frequent. So … no clue.

image

benloh commented 4 years ago

Ben suggests:

  1. Packaged builds -- This one is weird. And there might be multiple things going on. re http://www.joshuadanish.com/nc/Prok/#/ -- Yep I can see the problem. But there's a couple of weird things. i). It loads really slowly. This is a DO server?
    ii). The "SourceMap" warnings are due to my turning off sourcemaps in brunch in order to save about 1MB of data. You ought to be able to ignore those warnings. iii). I think I had forgotten to tell you to run npm ci on the pull request. I added a few new packages for cloning and compression. This server is definitely not running compression. iv). What kind of web server is handling this? Apache? I'll see if I can reproduce this problem. In the meantime, if you don't mind leaving that server up it'd be helpful.
benloh commented 4 years ago

Kalani responds:

No, this is running from Joshua’s personal web site. I’ve got one at https://dighist.indiana.edu/netcreate/#/ that’s running on IU’s servers, which the students will hit. Bandwidth concerns have us not running on DO, so hopefully IU’s servers are faster?

Yes, it’s Apache on the joshuadanish server. Pretty sure the Indiana.edu server is also Apache.

benloh commented 4 years ago

Joshua responds:

I just ran nom ci and re-packaged and put that on my server under http://www.joshuadanish.com/nc/Prok3/#/ (note the 3)

I am not sure I see a difference.

benloh commented 4 years ago

Joshua responds:

Newest version is now running at: http://142.93.63.36/graph/H213FA2020Prokopios/#/ (the other URL is live for students so this is safer).

I can’t tell if it is faster or not?

This does not appear to have the same problem - we only see it in standalone mode, though the student who it impacted said they saw something similar in the main app (that’s why we packaged). However, we have no error console from them and little else so … are not sure what gives.

netcreateorg commented 4 years ago

If you want to compare to a smaller network, here is one also on DO that loads much faster: http://134.209.73.52/graph/CHAT/#/

benloh commented 4 years ago

@jdanish The new http://142.93.63.36/graph/H213FA2020Prokopios/#/ does work for me. And it clearly has compression on. If you go to devtools and look at the Network panel, netc-lib.js is only 1.2MB. Uncompressed it's 5.6 - 6.4MB.

If you need it to run standalone, you might try again with a standalone build.

http://www.joshuadanish.com/nc/Prok3/#/ is clearly not compressed -- netc-lib is 5.6MB

benloh commented 4 years ago

That said, there probably is a lifecycle sequence error that we need to deal with. Sri notes:

From what I can tell from the error, it's being thrown by client-lifecycle on line 152 of my current build. I should pull your most recent.

it is happening specifically during LOADASSETS, so I would check all LOADASSETS hooks. If this is running in STANDALONE mode then maybe that'a a factor.

It looks like only one place hooks it in nc-logic.js

window localStorage may not have been set

Originally when I wrote this code, I think I assumed that standalone mode would just preserve data.

If you are running a standalone fresh, maybe window.localStorage doesn't exist.

if you run the app once in network mode then local storage is already initialized, so that's why its intermittent

netcreateorg commented 4 years ago

@benloh I just tried again and when I run it locally, the size is 1.2 or so, and then when I run package the version in the public folder is 5-6 MB again. Is it possible that when packaging it is not compressing? I am pretty sure I am doing all of the steps correctly ...

benloh commented 4 years ago

@jdanish Ah right. Compression is being done by the Node Express server as it serves the files. However, the Express server only serves the files with npm run dev or npm run classroom.

If you're running standalone/packaged mode, then Apache is doing your serving. If you want compression there, you'll need to configure your apache server to gzip the files.

Sorry 'bout that. I never use standalone and forgot how it worked.

Do you really need to run this standalone? Is there something else about the nature of the graph/class that requires it?

netcreateorg commented 4 years ago

Well, we have been using it in two cases:

  1. In the past, students who couldn't use the network for some reason including spotty internet used the standalone version to be able to see it without editing.
  2. That's what we put on the website after the class is done for demos.

Obviously, 2 is less important. But 1 was the reason we were messing around with it this time.

benloh commented 4 years ago

Got it.

We'll address the error.

How urgent is this? When do you need it?

In the meantime, you might look into gzip on Apache.

benloh commented 4 years ago

@jdanish This should now be fixed with 6a6a2f7b633cf7ca1a6999dc0d1216c34424fdfa. Just pull the latest commits on net-debug.

benloh commented 4 years ago

The issue was that in standalone mode, the template (p2) was sometimes being loaded before the database itself was loaded (p1). Wrapping the whole call in an asynch allows us to manage the load order. See nc-logic.js lines 180 - 198.

jdanish commented 4 years ago

Confirmed this works for me / us. Now to see if it works for the student! Fingers crossed (though that'd be a different issue if it doesn't).