Another maintenance release for WebSync Server was released today - version 3.5.0.7. This is a very small update that resolves an issue with the idle disconnect SQL query (only affects the sticky SQL provider). Head on over to the Downloads page to pick up the latest copy.

Happy coding!

Another maintenance release is out, bringing WebSync up to version 3.5.0.6. Head over to the Downloads page to pick up the latest copy.

Just a couple fixes in this one. IE should no longer throw a c00c023f error under any circumstances. We had previously applied a fix for the error occurring on page unload, but there was one additional case where it seemed to crop up. This one should be done for good now, but if you do happen to see it, please contact us with details about the conditions under which it occurs.

We also added a fix in the server-side initialization to account for cases where the location of web.config is non-standard, non-existent, or inaccessible for any reason. This should help with integration into third-party servers as well as when using SharePoint or other software that affects standard reading of configuration files. The symptom of the problem was a string of object reference errors in the logs when connecting clients. If you were affected by this, you should upgrade to this version as soon as possible.

That's all for now. Happy coding!

(And merry Christmas!)

Hot on the heels of the last release, we have a quick bug fix release to bring everyone up to date. There were a number of changes in the last release, and one of them had an unexpected side effect that could cause messages to be inserted into the database but never removed. In order for this bug to affect you, you would have to be running a standalone (outside IIS) application that invoked static RequestHandler methods, but did not have an httpHandler reference to RequestHandler in the app/web.config file. Not the most common scenario, but common enough to warrant a quick fix. Head on over to the Downloads page to pick up the latest version.

Happy coding!

We're happy to announce that the next release of WebSync is out in the wild! Head on over to the Downloads page to pick up the latest copy.

This is another patch release with a few bug fixes and some very nice enhancements. In particular, the Sticky SQL provider can now officially guarantee message delivery in every possible scenario, including complete server failures in a load-balanced environment! You may notice there is a slight increase in the CPU load during an application pool recycle, but our tests showed that even a dual-core server was still capable of handling 20,000 concurrent clients.

If you were seeing foreign key exceptions in your server logs, then rest easy. Our updated algorithms for client migration and application pool recycling have been vastly improved to reduce these to an absolute minimum. In most cases, they should be gone entirely.

The request handler has been updated to better handle improperly formatted messages, either from a sudden socket disconnection or some web crawler sending bad data. Bad data now receives a simple JSON response with no exceptions in the logs.

Several bugs were squashed with this release. First of all, onUnhandledReceive is now firing as expected in thick client applications. Apologies to anyone who spent time debugging this one - an improvement in another area of message receipt unexpectedly caused a problem with this callback. Next up is the rare IAsyncResult exception for long-running clients. This one proved almost impossible to track down, especially since it happens so rarely, but thanks to some great feedback from you, we believe we have gotten rid of this one for good as well. Finally, if you were seeing any sort of named pipe or IPC exceptions on the server-side, they should be gone with this release.

As always, we welcome every bit of feedback from you all. Please let us know if something isn't up to your standards. We pride ourselves in making simple what is complex, so if you find something counter-intuitive in the API, we will do our best to address it for the next major release.

Happy coding!

WebSync 3.5.0.3 was released today! Head over to the Downloads page to pick up the latest copy, and check out the Change Log for details on what was fixed/updated.

Issues with the Azure Table provider not starting up when deployed to the cloud have been resolved. A recent change by Microsoft in the handling of DateTime values in Azure Table Storage was at fault, but a workaround has been implemented in our code.

If the request handler or a provider fails to load for any reason, queries to request.ashx should now return a description of the error in JSON format. This is in addition to the server logging already made available through log4net, but it should make debugging server-side issues simpler.

There was a bug introduced in version 3.5.0.0 that would cause problems when sending Japanese and other Asian character sets over the network using HttpWebRequestTransfer. The problem was related to .NET's auto-detection of single-byte vs multi-byte character encodings and our own calculation of request content lengths. This issue is fixed with this release.

New build release for WebSync Server is now available with a few changes, notably some additional SQL enhancements and a couple of bug fixes related to HttpWebRequest timeouts and automatic mutex naming restrictions (DirectoryNotFoundException).

Happy coding!

One of the best new features of WebSync 3.3 is the ability to bind data to clients.  By attaching client-specific details to the WebSync clients, developing a rich user experience is easier than ever.

Consider the case where a client receives a message published by another client.  Previously, the receiving client would be able to see the ID of the publishing client, but nothing more.  Now, if the publishing client binds a display name to itself before publishing, that display name is available to the receiving client with the message.

Publishing client:

fm.websync.client.init().connect().bind({
    record: { key: 'displayName', value: 'John Doe' }
}).publish({
    channel: '/test',
    data: {
        text: 'Good morning!'
    }
});

Receiving client:

fm.websync.client.init().connect().subscribe({
    channel: '/test',
    onReceive: function(args) {
        alert(args.publishingClient.boundRecords['displayName'] + ' says "' + args.data.text + '");
    }
});

For more information, check out http://docs.frozenmountain.com/#class=server-code-snippets-binding-data.

The same concept applies to the Subscribers extension.  Previously, only the client IDs of a channel's subscribers were available to other subscribed clients.  Now, any public bound data is also available, making it easy to build an informed user interface quickly and easily.  Just access the boundRecords property on each of the client objects passed into subscribe.onSuccess and subscribe.onSubscribersChange.

For more information, check out http://docs.frozenmountain.com/#class=server-extensions-the-subscribers-extension.

There has been a temporary power failure in the WebSync On-Demand data center.  Our hosting company is working at full capacity to bring power back online as soon as possible.  We regret any inconvenience this may cause and will keep you posted with updates.

Update (9:42pm PST)

Power is back online with generators, but the WebSync On-Demand cluster is not yet reachable.

Update (9:44pm PST)

A fire in the data center was the source of the outage, and a disrupted transfer switch resulted in a failure to switch over to full generator power.

Update (10:41pm PST)

The cluster is still down.  Power is restored, but there appear to be individual issues related to power surges.

Update (11:26pm PST)

Unfortunately, the cluster is still down due to hardware problems.  You can follow progress being made by iWeb (where we lease data center space).

http://blog.iweb.com/en/2010/11/incident-power-distribution-data-center-cl/5978.html

Update (11:45pm PST)

Service is partially restored to WebSync On-Demand.

Update (12:02pm PST)

WebSync On-Demand is giving all indications of running at full capacity.

It's here! On-Demand officially supports SSL.

Using On-Demand SSL is trivial. Just change the script tag to load over https:// (i.e. https://sync3.frozenmountain.com/client.js). As long as your page is SSL-secured, the client will automatically configure itself to encrypt all communications.

Happy coding!

With WebSync Server 3.0.2, we've introduced the targedScan web.config attribute and the WebSyncMethodContainer assembly-level attribute. Together, they can help to reduce memory consumption significantly. This is especially important for shared hosting environments, but is a good practice for any production system.

Before explaining what the new attributes do, let's first look at why memory consumption is an issue at all.

WebSync lets you decorate methods with attributes so they attach to specific server-side events (BeforePublish, AfterSubscribe, etc.). This ability is what makes WebSync so extensible and part of what makes it so easy to use. In order for WebSync to invoke the methods, though, it first has to find them. To do that, WebSync scans the currently loaded assemblies, looking at each type and checking for methods that are decorated with WebSyncEvent or WebSyncScriptModifier. This scan happens just one time, at first run, after which the decorated method information is cached and can be accessed later as needed.

So what's the problem?

Well, there's one small catch. Reflection is expensive, and the .NET framework architects made a design decision a long time ago that any reflective calls for metadata should be cached internally rather than allowing developers to implement caching solutions themselves. This means that whenever type or method information is accessed, the metadata is cached permanently in the application domain. The intention of the architects was to ensure that the reflective work was only every performed once, but for server environments with scarce resources, this is a problem.

As WebSync scans the assemblies/types/methods, .NET caches every piece of information. The internal .NET bloat can be noticeable, even upwards of 100MB memory consumption. We think you would agree, the memory could definitely be put to better use.

Enter the targetedScan and WebSyncMethodContainer attributes, which define where and how to scan.

If targetedScan is set to true in web.config (WebSync/server[targetedScan]), WebSync will ONLY analyze types that are explicitly specified by the WebSyncMethodContainer assembly-level attribute.

For example, if your WebSyncEvent methods are defined in a class called MyWebSyncEvents, simply place the following attribute in AssemblyInfo.cs (in your Properties folder):

[assembly: WebSyncMethodContainer(typeof(MyWebSyncEvents))]

Now, if targetedScan is set to true, WebSync will restrict its scan to just that type and its methods, ignoring all other types/methods and thereby preventing their metadata from being cached by .NET.

(Note: WebSyncMethodContainer can be defined multiple times per assembly, once for each type containing WebSync methods.)

We highly recommend that you use this approach, especially in production systems and reusable extension class libraries. There is no reason to have unnecessary memory consumption, especially when that memory could be used to increase concurrency :)