Skip to first unread message
Assigned to ewpa...@gmail.com by me

TFO

unread,
Sep 6, 2017, 10:25:55 PM9/6/17
to MIT App Inventor Forum
I have an appinventor project that initially loads but after half a minute or so it displays the "Loading.." notifier in the Appinventor menu and the notifier does not go away.

If I hurry and save the project locally as .aia it can not be loaded back and stops at "Transfering 55%"

I can sometimes build as .apk and even load using companion but it looks like any changes made in the code blocks are not saved.

Evan Patton

unread,
Sep 8, 2017, 4:08:36 AM9/8/17
to MIT App Inventor Forum
You may be experiencing timeouts due to many assets or screens. Can you tell us a little bit more about the size of your project?

Evan

Angus Chen

unread,
Sep 8, 2017, 3:21:00 PM9/8/17
to MIT App Inventor Forum
Hi Evan,

I have same problem, my project export to .aia in my computer is 175kb. 
How big or what limited on ai2 web?

Best regards,
Angus

Evan Patton

unread,
Sep 8, 2017, 4:26:21 PM9/8/17
to MIT App Inventor Forum
There's a hard limit at 10 MB per project to send it to the build server. This is enforced by the Google App Engine runtime--if we go over, it will kill the transfer. Another challenge is that a project with many files (screens + assets + extensions) will take a long time to load out of Google Cloud Storage. There is a hard limit of 1 minute runtime so if there are too many files then that can end up killing the transfer to the build server as well. If you are running into problems at ai2.appinventor.mit.edu you can try loading your projects into code.appinventor.mit.edu and try there. The latter server runs at Amazon rather than Google and so doesn't have the same restrictions.

Evan

elporti

unread,
Sep 8, 2017, 5:11:28 PM9/8/17
to MIT App Inventor Forum
It seems that something is happening. Yesterday I worked without problems with the same project and today (without changing anything) I cannot enther in none of the servers

regards

TFO

unread,
Sep 8, 2017, 9:42:41 PM9/8/17
to MIT App Inventor Forum
When saved locally as .aia it is 175kB. I am a bit curious why it starts loading when editing a block and why there is no error message or timeout. How do I find the transfered project size.

When saving a project it instatntly displays a date and time message in the menu. I suspect it is not a real confirmation the project has been successfully saved.

Would be nice with some kind of progress indicator to know load/save is 100% completed.

Evan Patton

unread,
Sep 8, 2017, 11:34:12 PM9/8/17
to MIT App Inventor Forum
TFO: Do you have the same problem with your AIA if you load it into the server at code.appinventor.mit.edu?

Also, the project should automatically save 5 seconds after a change, so it typically isn't necessary to use the Project > Save Project option. The save option only saves the files that have changed, not every file, so it may still be the case that saving is relatively fast because not everything is transferred from client to server.

Evan

TFO

unread,
Sep 9, 2017, 1:39:48 PM9/9/17
to MIT App Inventor Forum
Here is a clue:

I made an empty project with a test procedure

While monioring the network activity in Chrome browser developer console I duplicted the procedure and waited for each new successful POST to the server. (It takes a few seconds of user inactivity for the change to save)


After creating 16 procedure duplicates the 1.5 second POST XML to "http://code.appinventor.mit.edu/ode/projects" was about. 224kB and more duplicates makes the post hang for the entire timeout of 2 minutes.


So at this point I have a 224kB project saved to the server.


If I close the brower I can load the project again. Issuing a POST to the server by just moving a code block the update again fails with a timeout.


If I then start removing procedure duplicates there will be a series of pendning POST operations for each delete but not until I have only two copies left the POST operations execute directly.


It is like there is a read/write operation on a server database blocking.  Sometimes long pendning post operations returns all in a row like something was blocking them. 


This is about the maximum number of copies before project code blocks can no longer be saved.



 

TFO

unread,
Sep 9, 2017, 1:58:49 PM9/9/17
to MIT App Inventor Forum
Noticed a single procedure project with lot of items moved a few pixels in the editor sometimes saves and sometimes does not.


Chrome network activity when procedure draged in editor window 



TFO

unread,
Sep 10, 2017, 7:21:03 PM9/10/17
to mitappinv...@googlegroups.com
My "large projects" save only with Avast Web Shield off.

I have noticed if the Web Shield component of Avast Antivirus is turned off my Appinventor upload problems goes away.

When antivirus is turned off I can upload 1MB+ projects in seconds but when turned on uploads larger that 150kB suddenly blocks and upload is pendning until the 2 minute timeout.

If the blocking/non functional Web Shield is turned of while an upload is pending the upload is aborted. To cause a new codeblock update moved a block a few pixels and a new update will be posted and successfully saved to the Appinventor server.

Same with importing .aia project files. Just will not work with larger projects but ok without the Web Shield.

Update: 
The above problem occurs on a Lenovo 64-bit Win7 laptop. Same project opened on a HP 7600 Win-32 desktop, same network ,identical Avast version 17.6.2310 - works fine even with Avast Web Shield enabled.





Evan Patton

unread,
Sep 12, 2017, 7:30:06 PM9/12/17
to MIT App Inventor Forum
Hi TFO,

My guess then based on your report that your antivirus is scanning the uploaded files. If this takes more than a minute, then the server kills the connection. You may want to switch to using code.appinventor.mit.edu. While it won't change the slowness due to the virus scanning, it does not have the hard 1-minute timeout.

Evan

TFO

unread,
Sep 13, 2017, 1:36:32 PM9/13/17
to mitappinv...@googlegroups.com
Hi Evan,

The strange thing is, with virus scan enabled, the time to upload a 150kB project is < 2 seconds. As soon as it passes some size limit 200kB it hangs for the entire 2 minute timeout.

As the antivirus does not work any different with any URL exclusion I tried I asume as soon as it gets involved with the network stream it affects the upload. I can only hope for another future update of Avast where block sizes and buffers and stuff like that suddenly changes for the better. Wonder how it looks on the server side when upload is pendning?

Anyway it would be nice if Appinventor had a better status indicator to know pending changes have been sent to server. Like the Google Documents "All Changes Saved to Drive"-notice in the top menu.


A bit out of subject but would save a lot of bandwidth:

As blocks attached below each other makes deep nested XML it generates lot of space characters to be sent to the servers repeated for each tiny block update.


This simple procedure generates a deep <XML> using 3440 characters:


<xml>
 
<block type="procedures_defnoreturn" id="UxsMBQ];G=.ODteNE8D/" x="-773" y="-573">
   
<field name="NAME">p1</field>
   
<statement name="STACK">
     
<block type="controls_eval_but_ignore" id="Hwx%WF!-%evj#EfUf[`H">
       
<value name="VALUE">
         
<block type="logic_boolean" id="F8[A6;6DEb,`t$J$l)T8">
           
<field name="BOOL">TRUE</field>
         
</block>
       
</value>
       
<next>
         
<block type="controls_eval_but_ignore" id="lz}:8+3w];~Un0sYXX?X">
           
<value name="VALUE">
             
<block type="logic_boolean" id="~Mllwqb)x,.e/#$z4Sw~">
               
<field name="BOOL">TRUE</field>
             
</block>
           
</value>
           
<next>
             
<block type="controls_eval_but_ignore" id="+KPSzMdi#SthW~{\!Lx;?">
               
<value name="VALUE">
                 
<block type="logic_boolean" id="had{ZJJI`Vz?Y,rm#5[0">
                   
<field name="BOOL">TRUE</field>
                 
</block>
               
</value>
               
<next>
                 
<block type="controls_eval_but_ignore" id="KD~vzD+xn##ACk3`JAM7">
                   
<value name="VALUE">
                     
<block type="logic_boolean" id="pMyr0[TdZcXvZEG^oN[7">
                       
<field name="BOOL">TRUE</field>
                     
</block>
                   
</value>
                   
<next>
                     
<block type="controls_eval_but_ignore" id="mHpWE-Ff+poYDCP4oCrB">
                       
<value name="VALUE">
                         
<block type="logic_boolean" id="=HS0Bvj)b]GenJmEtrAF">
                           
<field name="BOOL">TRUE</field>
                         
</block>
                       
</value>
                       
<next>
                         
<block type="controls_eval_but_ignore" id="8_u$;D`h:?(_Yb`4=Yxy">
                           
<value name="VALUE">
                             
<block type="logic_boolean" id="wr!P1i`)c{y~5b=8=_bQ">
                               
<field name="BOOL">TRUE</field>
                             
</block>
                           
</value>
                           
<next>
                             
<block type="controls_eval_but_ignore" id=",Z9nNLI.MQM$![s_[\!xK">
                               
<value name="VALUE">
                                 
<block type="logic_boolean" id="u)bf7]@ABTsFnJ!Q_1+?">
                                   
<field name="BOOL">TRUE</field>
                                 
</block>
                               
</value>
                               
<next>
                                 
<block type="controls_eval_but_ignore" id="chD3WM0%u=^ASmhDVe@E">
                                   
<value name="VALUE">
                                     
<block type="logic_boolean" id="md%NzS9qPaN-wOaqT7?^">
                                       
<field name="BOOL">TRUE</field>
                                     
</block>
                                   
</value>
                                 
</block>
                               
</next>
                             
</block>
                           
</next>
                         
</block>
                       
</next>
                     
</block>
                   
</next>
                 
</block>
               
</next>
             
</block>
           
</next>
         
</block>
       
</next>
     
</block>
   
</statement>
 
</block>
 
<yacodeblocks ya-version="159" language-version="20"></yacodeblocks>
</xml>

Leaving the linebreaks and spaces out this uses only 54% compared to previous XML and would preserve a lot of bandwidth (and maybe even storage size?).

<xml><block type="procedures_defnoreturn" id="UxsMBQ];G=.ODteNE8D/" x="-773" y="-573"><field name="NAME">p1</field><statement name="STACK"><block type="controls_eval_but_ignore" id="Hwx%WF!-%evj#EfUf[`H"><value name="VALUE"><block type="logic_boolean" id="F8[A6;6DEb,`t$J$l)T8"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="lz}:8+3w];~Un0sYXX?X"><value name="VALUE"><block type="logic_boolean" id="~Mllwqb)x,.e/#$z4Sw~"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="+KPSzMdi#SthW~{\!Lx;?"><value name="VALUE"><block type="logic_boolean" id="had{ZJJI`Vz?Y,rm#5[0"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="KD~vzD+xn##ACk3`JAM7"><value name="VALUE"><block type="logic_boolean" id="pMyr0[TdZcXvZEG^oN[7"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="mHpWE-Ff+poYDCP4oCrB"><value name="VALUE"><block type="logic_boolean" id="=HS0Bvj)b]GenJmEtrAF"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="8_u$;D`h:?(_Yb`4=Yxy"><value name="VALUE"><block type="logic_boolean" id="wr!P1i`)c{y~5b=8=_bQ"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id=",Z9nNLI.MQM$![s_[\!xK"><value name="VALUE"><block type="logic_boolean" id="u)bf7]@ABTsFnJ!Q_1+?"><field name="BOOL">TRUE</field></block></value><next><block type="controls_eval_but_ignore" id="chD3WM0%u=^ASmhDVe@E"><value name="VALUE"><block type="logic_boolean" id="md%NzS9qPaN-wOaqT7?^"><field name="BOOL">TRUE</field></block></value></block></next></block></next></block></next></block></next></block></next></block></next></block></next></block></statement></block><yacodeblocks ya-version="159" language-version="20"></yacodeblocks></xml>


TFO

unread,
Sep 13, 2017, 4:36:14 PM9/13/17
to MIT App Inventor Forum
Finishing up with some packet analyzis of a 292kB code block project:

With Avast turned off the block upload TCP traffic consists of consecutive TCP packages starting with a first 881 byte packet containing only the HTTP header and data follows in the next packages of size 1518 bytes until transfer is completed.

POST /ode/projects HTTP/1.1
Connection: keep-alive
Content-Length: 291796
X-GWT-Permutation: 94451607BB03FFFDB75CEAD85043BCBF
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Content-Type: text/x-gwt-rpc; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4,nb;q=0.2,de;q=0.2
Cookie: G_ENABLED_IDPS=google; _ga=GA1.2.1634098852.1504264096; AppInventor=..


After all packages sent and acked in the TCP convertation the server responds.

TTP/1.1 200 OK
Date: Wed, 13 Sep 2017 14:03:52 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 22
Connection: keep-alive
Content-Disposition: attachment
Server: Jetty(9.2.12.M0)

//OK



With small size projects and Avast turned on. Avast now streams data out with all TCP packages of size 1518 bytes making the first package containing both the HTTP header and begining of codeblock XMLdata.

The interesting thing with Avast still turned on switching to a large project now when it hangs the first TCP packet is only size 881 bytes and then silence.  

After exactly 30 seconds of waiting for more the Appinventor server replies:

HTTP/1.1 500 Server Error
Date: Wed, 13 Sep 2017 14:00:27 GMT
Content-Type: text/plain
Content-Length: 57
Connection: keep-alive
Server: Jetty(9.2.12.M0)

The call failed on the server; see server log for details

It looks like Avast is only capable of handling the first TCP package on the input stream being the HTTP header, while parsing the rest of the TCP packages in larger chunks it fails to fill the output stream with more data and it becomes only 881 bytes long and then godbye.

The rest of the conversation may follow on the Avast user forum...  

Evan Patton

unread,
Sep 13, 2017, 8:47:29 PM9/13/17
to MIT App Inventor Forum
Hi TFO,

While I agree with you that the formatting of the XML file is unnecessary, in this particular instance it will not make a significant difference because of the fact that the AIA file is a ZIP file, and therefore the compression should take care of long runs of whitespace. If you update your AIA with the version with the whitespace stripped out, I would expect that you shouldn't see a significant size reduction (maybe, ~3% or so) compared to the project with the pretty-printed version.

Evan

Evan Patton

unread,
Sep 13, 2017, 8:49:49 PM9/13/17
to MIT App Inventor Forum
This isn't surprising to me. I expect that Google's servers terminate the TCP connection if they don't receive any data--there isn't any logic in our code to do that. Do you see similar problems when uploading ZIP files on the order of 300KB to other websites? What about if you upload an AIA file to another website, e.g. this forum?

Evan

TFO

unread,
Sep 13, 2017, 11:34:29 PM9/13/17
to MIT App Inventor Forum
I just noted there is 50% whitespace in the XML posted to appinventor servers on each update in code block editor. No compression and human readable indented XML.

Evan Patton

unread,
Sep 14, 2017, 3:34:23 PM9/14/17
to MIT App Inventor Forum
Most HTTP connections will be transparently gzipped. This is negotiated between the browser and server as part of the HTTP handshake. Are you seeing this on the wire (e.g., using a utility like Wireshark) or in the browser networking tab. The latter should be readable because the browser is presenting the actual content, not the gzipped version. If you are seeing this on the wire, then that indicates there's a problem with the browser and server negotiating whether to gzip and is a bug we need to fix.

Evan

TFO

unread,
Sep 14, 2017, 10:08:42 PM9/14/17
to MIT App Inventor Forum
The indented XML in the HTTP post is 300 kB in the Google Chrome developer console network view. If POST upload data is compressed it would be done by some HTTP library or anyway provided by the browser before sending it to the TCP socket.

In my TCP socket listener by Colasoft I still see human readable XML. Also the properties of the Windows 7 WiFi adapter jumps +300kB for every block update made.


The Colasoft TCP analyzer displays an upload TCP block fragment as:

  <block type="procedures_defnoreturn" id="UxsMBQ];G=.ODteNE8D/" collapsed="true" x="-2185" y="-770">
    <field name="NAME">p1</field>
    <statement name="STACK">
      <block type="controls_eval_but_ignore" id="Hwx%WF!-%evj#EfUf[`H">
        <value name="VALUE">
          <block type="logic_boolean" id="F8[A6;6DEb,`t$J$l)T8">
            <field name="BOOL">TRUE</field>
          </block>
        </value>
        <next>
          <block type="controls_eval_but_ignore" id="lz}:8+3w];~Un0sYXX?X">
            <value name="VALUE">
              <block type="logic_boolean" id="~Mllwqb)x,.e/#$z4Sw~">
                <field name="BOOL">TRUE</field>
              </block>
            </value>
            ...

No compression in upload I think.

Evan Patton

unread,
Sep 25, 2017, 4:23:38 AM9/25/17
to MIT App Inventor Forum
Thanks TFO. I have gone back and confirmed that it is an issue. We are tracking this as issue #939.

Evan
Reply all
Reply to author
Forward
0 new messages