framework.js & styles.css delivery from 3rd party & caching

Is there a way to delivery the framework.js and other static files used by a webapp from a different place?

Currently it’s taking a long time to load and download each static file like framework.js, styles.css etc. (about 1s each). The server is fine, 8 cores etc, SSD, etc.

The problem is that the load time is not even affected by number of simultaneous connections. I’ve tested it with a stress test service and having 50 concurrent connections with 20 requests/second has the same delivery time as with a single connection/request.

If I could at least make these cached by the client but looks like they get downloaded new each time etc…

Thanks for any suggestions/help in advance.

What version of the IDE are you using?


First of all, remember that over time, as we add new features and fix bugs, those framework files do change. Additionally, they are compiled specifically for your project, depending on which controls you have placed on your WebPages, and are baked right into the binary. Serving them from another location isn’t really feasible right now.

That said, we’ve made some major improvements in this area in Xojo. The latest release (2013r4.1) should do exactly what you are asking for, that is, allowing the browser to cache the framework files.

Uhmm, that sounds ok then. For the moment I will work on getting the project out and later I will work on upgrading it to 2013r4.1

I had a problem with sessions and.or handleSpecialURL spawning many threads and the threads wouldn’t go away even after hours etc, do you know anything about it? I had to actually make a pointer to each new thread spawn by handleSpecialURL in a dictionary and then kill them in the end of the event otherwise I would get hundreds of threads that would be sitting there, doing nothing…

sorry for moving to a different direction but I think you are the best person to ask this… :slight_smile:

I can’t think of anything off the top of my head that we changed that would affect this, but it sounds like your threads are not completing for some reason (the Run event is not finishing).

You were/are right. I’ve implemented a logging/cleaning tool for the threads and I found the bug. Thanks for your attention/time. :slight_smile:

I’ve finally figured out why the threads kept accumulating. My webapp handles calls from mobile (iOS/Objective-C) through the App.HandleSpecialURL. It works fine and with no problems at all except that some of these calls keep the thread created by App.HandleSpecialURL alive & sleeping. After about 30 minutes the number of threads can be anywhere from 15, 20, 40 depending on how many calls the mobile executes etc.

This behavior is present because I’m using “[NSURLConnection sendSynchronousRequest…” which keeps the connection alive either too long or indefinitely and then, even with the mobile off, the thread started in App.HandleSpecialURL doesn’t die and stays in sleep state.

For now I have a dictionary where I store a reference to each thread created by App.HandleSpecialURL and marked as True/False (True marked right in the beginning and False in the end of App.HandleSpecialURL) then a cleaning method runs through the dictionary killing threads that are sleeping for too long and were marked as false by App.HandleSpecialURL.

This has a “problem” though since it raises an exception for each killed thread but overall I didn’t see any other issues related to this clean up method.

Question: Does xojo (any version) has a keep alive timeout of some sort for App.HandleSpecialURL?