Dotmad.net

There are limits most application developers never encounter. One of them is the 2GB memory limit for applications running on a 32bit operating system.

But what happens if your application is a memory consumer (and most GIS applications are)?

You may find out your application tends to crash and burn once reaching a memory signature of a little over 1GB.

It’s a common knowledge for developers (I hope) that a useful way to measure application’s true memory consumption is using the Task manager’s “VM Size” column (as the “Mem Usage” column only indicates the size of the application’s Working Set). So why does the application crash when supposedly there is still plenty of free memory?

There are 2 possible answers:

1. Although a certain size of memory is allocated to the application, fragmentation to the memory may cause the application to actually consume more than that. This may also be related to the GC behavior in relation to 2nd generation objects, which I’ll discuss later.
2. The VM Size column does not represent the actual Virtual address space allocated to the application, which is limited to 2-3GB on a 32bit OS. In addition to the allocated memory the OS may have designated addition shared memory (shared with other applications, but still counts towards the 2GB limit). To view the actual size of memory allocated by the OS to the application, use the Perfmon.exe tool’s Virtual Size counter:

The .Net Garbage Collector and 2nd generation (gen2) collections

The GC algorithm divides the allocated objects to 3 generations (0-2), when generation 0 objects are retrieved most frequently and “live” for the shortest amount of time. Generation 1 objects are collected less frequently and generation 2 collections are truely a rare occasion.

But when does the GC collects generation 2 allocations (”full” collection)? What triggers such a collection?

Surprisingly I found very little information of this subject, but the information I did find, combined with experimentation led to the conclusion such collection occurs when the overall system is low on physical memory.

Now, let’s consider the implications for a 4GB computer running a 32bit OS. While the gen2 heap may inflate over time (especially considering large objects are also collected only in gen2 collections), the GC will never trigger as a single application can never consume the entire amount of memory on the computer (being limited to 2GB). However, this may lead to a memory leak and eventually crashing the application (once it’s virtual address space reaches 2GB).

The solution? Call the GC.Collect() method yourself to trigger a full collection.

I have recently been to an Israeli user group meeting in which iDesign’s Juval Lowy gave a lecture about the new Azure .Net Service Bus for web services written in WCF.

Basically a service bus is a router, similar to the one you use in your office network. Instead of needing to update the configuration for multiple clients each time a service they are connected to is moved to a new location or changes channel, all clients/services connect to a central hub. In this case the service bus is located online, somewhere on Microsoft servers.

Here is what the meeting’s page says about the lecture:

The .NET services bus is part of the new Microsoft Cloud Computing Windows Azure initiative, and arguably, it is the most accessible, ready to use, powerful, and needed piece. The service bus allows clients to connects to services across any machine, network, firewall, NAT, routers, load balancers, virtualization, IP and DNS as if they were part of the same local network, and doing all that without compromising on the programming model or security. The service bus also supports callbacks, event publishing, authentication and authorization and doing all that in a WCF-friendly manner. This session will present the service bus programming model, how to configure and administer service bus solutions, working with the dedicated relay bindings including the available communication modes, relying on authentication in the cloud for local services and the various authentication options, and how to provide for end-to-end security through the relay service. You will also see some advanced WCF programming techniques, original helper classes, productivity-enhancing utilities and tools, as well as discussion of design best practices and pitfalls.

Although Juval clearly know a lot on the subject, and apparently is currently doing a tour lecture on the subject (at least in Israel and Belgium), I have to say the talk was not very interesting for experienced WCF developers. This is due to the fact the interface is almost identical to that of a simple WCF service, therefor I kept getting a feeling of “been there, done that“. It’s very easy to work the .NET service bus.

The .NET service bus supports both TCP/IP and HTTP based connections (highlight of the lecture: “to add WS support just add an ass“), and allows both connectivity through the cloud or P2P (after negotiation). There is a limited usage to SSL transport level security, something that alarms me a bit, as this is the best performance/security ratio option in WCF.

I do have to wonder regarding the usability of this platform. Many companies I know moved to SOA architecture, splitting central servers to many services. Such systems need a service bus residing inside the local network due to two reasons:

1. Local network is more secure. Although Mr. Lowy waved his hands and replied “message level security is NP complete” to a question on the subject, I doubt IT managers or security officers in large firms would accept that.
2. Local network is faster. Although a large downwards bandwidth is easily obtained, for a true 2 way communication you need a decent outgoing bandwidth (unlike ADSL lines, for example), and that’s not cheap.

There are local alternatives, both commercial (Microsoft Biztalk server) and open source (Udi Dahan’s NServiceBus).

I guess only time will tell if this new technology is successful.