AppServer – Updates

February 18, 2015

It’s been a while… too busy at work.

Application Sync

When the application server starts, it connects to the hub and downloads all of the applications that it needs. This process was convoluted in the interest of efficiency. It downloaded each file only one time, and then distributed it to each application that needs it. This is all managed by a feature called the Application Host Feature (which, really, one of a few components that comprise the heart of the software.)

Unfortunately, there was a problem with the sync. It only runs when the feature is started. If you change the application, then the application won’t sync until the feature is restarted. Of course, I knew that, and planned to rectify it. But, the rectification was too ugly, so I ended up rewriting it.

The sync is now two steps: Configuration and applications.

Configuration – it downloads the configuration for all of it’s apps. It removes any started apps that no longer belong, and updates the configuration with any new applications.

Applications – when the application starts, it is synced. It downloads a list of files, determines if there are any changes, then updates/adds/deletes as needed. If the application is started, it only stops it when necessary.

This is less efficient, but more functional. It may end up downloading the same file multiple times. A quick change can eliminate that: just check the rest of the directory structure and see if the file is already there. If so, grab it a local copy. (All of the file operations are based on NAME and HASH, so you won’t get the wrong version of the file.)

Visual Studio 2015 / NuGet / Cors

I started using Visual Studio 2015… It’s been a bit troublesome with both locking files and GIT, but pushing through. I love a lot of the c# changes.

NUGET either doesn’t work the way I like, or I just need to get used to it. After attempting to update the nuget packages, CORS seemed to stop working. The javascript calls kept receiving INTERNAL SERVER ERROR 500, which wasn’t happening in the server. It kept reporting that the ORIGIN header wasn’t coming back, which I confirmed in FIDDLER.

I spent some time chasing my tail, and never found the cause of the problem. The fix was to go through every nuget package, one at a time, and make sure it was up to date individually. Working through the list is really slow… it shows a few, then hangs for a while as it loads the next few. Then, each time you update a package, you have to start at the top and work through the list again. I wasn’t able to track down the specific error, but I believe it was due to out of sync web api DLLs.

Next

Context Logging

The next thing I want to work on is context logging. As things do work, they publish messages. “starting application”, “syncing”, “downloading files”, etc. It’s a hierarchy of activities. It works very well, but it clutters the code. I’m trying to find a more elegant way to do it, but have been unsuccessful so far. I will at least review it again, and maybe just have to settle.

Process Isolation

I’ve been talking about this for a while, but still haven’t started on it yet. Rather than putting each application in it’s own appdomain, I want the option of having them run as their own process.

Server Syncing

Currently, applications sync as they start. They will always have the latest version. (You can also publish a message telling it to resync any time you want.)

But, the server itself does not. It gets deployed, and that’s it. DEVDASH, which was one of the projects that lead to this one, would update itself and it’s applications. I need to get that functionality in here. Then, if a core assembly gets updated, all servers will download it and restart.