Fighting the machine

In an effort to understand the basics behind CCR and see if I could play with the technology I created a console application with the following goals in mind:

Be able to queue up a “logger” type of request where a worker thread could take care of handling the processing of those requests.

In reality, I’m not doing much more than simply passing a string to a static class that uses CCR and its multithreading system to dump the output to the console. Nevertheless, the process is quite interesting and could be applied to a multitude of scenarios.

Observe the following Console/Program.cs file:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using Microsoft.Ccr.Core;

   6:  using System.Threading;

   7:   

   8:  namespace ConsoleApplication1

   9:  {

  10:      class Program

  11:      {

  12:          static void Main(string[] args)

  13:          {

  14:              for (int i = 0; i < 10; i++)

  15:                  ConsoleLogger.Log(i.ToString());

  16:   

  17:              Console.WriteLine("Done queuing");

  18:   

  19:              ConsoleLogger.StopLogger();

  20:          }

  21:      }

  22:  }

No black magic here, the code is very readable. We create a loop (line 14) which takes care of requesting to our ConsoleLogger class to log 0-10 (line 15) and finally output “Done queuing” (line 17). In a real world we would expect 0-10 to be spit out and then see “Done queuing” but this is not what happens in this case, “Done queuing” appears first only to then see 0-10 each on its own line. Such is the magic of multithreading.

Let’s observe the source code for the Class/ConsoleLogger.cs

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using Microsoft.Ccr.Core;

   6:  using System.Threading;

   7:   

   8:  namespace ConsoleApplication1

   9:  {

  10:      public static class ConsoleLogger

  11:      {

  12:          //Create Dispatcher

  13:          private static readonly Dispatcher _logDispatcher = new Dispatcher(1,

  14:              ThreadPriority.Normal, false, "LogPool");

  15:   

  16:          //Create Dispatch Queue

  17:          private static DispatcherQueue _logDispatcherQueue;

  18:   

  19:          //Message Port

  20:          private static readonly Port<string> _logPort = new Port<string>();

  21:   

  22:          //Fields

  23:          private static bool _ready;

  24:   

  25:          private static void Init()

  26:          {

  27:              _logDispatcherQueue = new DispatcherQueue("LogDispatcherQueue",

  28:                  _logDispatcher);

  29:              Arbiter.Activate(_logDispatcherQueue, Arbiter.Receive(true, _logPort,

  30:                  WriteMessage));

  31:   

  32:              _ready = true;

  33:          }

  34:   

  35:          private static void WriteMessage(string messageString)

  36:          {

  37:              Console.WriteLine(messageString);

  38:          }

  39:   

  40:          public static void Log(string messageString)

  41:          {

  42:              if (!_ready)

  43:                  Init();

  44:              _logPort.Post(messageString);

  45:          }

  46:   

  47:          //Any thread tasks still running?

  48:          private static bool PendingJobs

  49:          {

  50:              get

  51:              {

  52:                  return (_logDispatcher.PendingTaskCount > 0 ||

  53:                  _logPort.ItemCount > 0) ? true : false;

  54:              }

  55:          }

  56:   

  57:          //Since we are not using background threading we need to add this method to

  58:          //dispose the DQ for application end

  59:          public static void StopLogger()

  60:          {

  61:              while (PendingJobs) { Thread.Sleep(100); }

  62:              _ready = false;

  63:              _logDispatcherQueue.Dispose();

  64:          }

  65:      }

  66:   

  67:  }

Note the declaration of (line 13) the dispatcher that will be used to dispatch requests to the CCR engine. Also observe the declaration of the dispatcher queue (line 17) and the message port (line 20).

Line 25 lists the Init code of our class that will set up the whole CCR settings so that the class uses multithreading internally to display our messages.

Line 35 demonstrates the actual method that performs the work, notice that the parameter accepted by this method is the exact same parameter as the one set up for the port on line 20. Therefore, you can assume that when you call the port the underlying engine will pass on this request to this method and simply pass the parameter along.

Line 40 shows the method that is used to actually insert some data in the port (queue) which will then be processed by the engine to be relayed to the worker method (line 35).

Line 48 shows an internal function that will allow us to stop the logger which will check if all the processing has completed for our class. We don’t want to exit the ConsoleApplication before all the work has been done. It also handles calling the Init method if the CCR engine has not be yet set up in this class.

Finally, line 59 defines the final method that is used to wait for all processing to be completed. We will check every second (pausing the thread for proper threading etiquette) and recheck until the CCR engine no longer has any messages to process and finally dispose of the Dispatcher Queue.

The code is not flawless but it properly illustrates the use of the CCR engine and its most basic capacities.

For more information on CCR and DSS check out the Microsoft page dedicated to this new and exciting technology.

Almost every time that you search for this error you will find a fix similar to the following:

<bindings>
  <Binding>
    <binding name="myBindingName">
      <security mode="None" />
      <readerQuotas
        maxDepth="32"
        maxStringContentLength="8196"
        maxArrayLength="16384"
        maxBytesPerRead="4096"
        maxNameTableCharCount="16384"
        />
    </binding>
  </Binding>
</bindings>

Where [Binding] in the xml structure above is the type of binding that you are using: wshttp, netmsmq, etc

What most of these posts will not explicitly tell you is that these settings should not only be changed on the CLIENT app but also in the HOST as well.

By default, when you create a WCF Service Host you don’t have to create the bindings as it will properly function with the defaults. The trick here that I found is to simply create a custom binding on the host side, properly set the maxStringContentLength to a value that will allow your host to process messages and the problem will be solved. Don’t forget to set the client bindings to sufficient values as well.

Personally, I think that this error is questionable but I can think of some DOS reasons why the setting should remain. I guess it’s something that you need to consider especially if you plan on receiving some huge data calls from the open public.

Many times, I read tutorials on the internet where people (with great intentions) will share code on how to use new technology to make your life as a developer easier.

The good intention is there, and it reminds me a bit of being back in programming school where they would show you code and basically say: this is how you say “hello world”

The problem with this approach is while it teaches the student how to have a good understand of how to do certain things it does not necessarily show you WHY you should do one thing over another.

I have this problem in my head, a problem with the Unity Application Block in the Enterprise Library.

There are plenty of great tutorials on how to use Unity but I have yet to see one that explains good patterns on WHEN and WHY you should use it. When is it appropriate? What is an example of a real life situation where it could solve a problem. It’s almost like everyone explains how to drive a car but no one actually says that you could go in the taxi or delivery business. Once I know how to drive, I’ll ask myself: ok – great – now what? What do I do with this and when do I use it. Sometimes, it will be obvious and sometimes it won’t be. And it will be obvious to varying degrees based on some individuals as well. Other folks, while they need – won’t get it.

I’m going to mix a few different things here so that we can look at a real-life situation that Unity can help you with.

Before I start, please give this site a visit: http://www.pnpguidance.net/Category/Unity.aspx – I would not be able to explain anything about Unity without David Hayden’s excellent help.

O’Reilly published an excellent book called “Head First Design Patterns” (see link in references), if you don’t know what I mean by my next couple of terms – this is a great book to check out to learn their details.

Let’s not talk about Unity for a few paragraphs and talk about the Strategy Pattern. The basics of the strategy pattern is that you should delegate class behavior to a more specialized class that implements this behavior.

If you can’t pick up on the key advantage of this, it means that you can actually make classes/objects that don’t implement a fixed behavior and actually set this behavior at runtime.

When you design a class that implements that Strategy Pattern, you should actually create properties to store these behavior objects so that your class can invoke the methods/properties of those classes in it’s own methods/properties.

So instead of having the following:

public abstract class RobotTerminator
    {
        public abstract void FindTarget();
    }

    public class RobotTerminatorSarah : RobotTerminator
    {
        public override void FindTarget()
        {
            // find Sarah
        }
    }

    public class RobotTerminatorJohn : RobotTerminator
    {
        public override void FindTarget()
        {
            // find John
        }
    }

You could instead have the following:

public interface ITargetFinder
    {
        void FindTarget();
    }

    public abstract class RobotTerminator
    {
        private ITargetFinder _targetAcquisition;

        public RobotTerminator(ITargetFinder targetAcquisition)
        {
            this._targetAcquisition = targetAcquisition;
        }

        public void FindTarget()
        {
            this._targetAcquisition.FindTarget();
        }
    }

The principal advantage is that I don’t need to recompile all of my robots before I send them back in time with new targets and missions all the time. While  I will agree that the example below is over-simplified, it illustrates the point well. You don’t want to have to open up the Drone’s heads all the time to give them new mission parameters, especially not upload/recompile their Operating System (imagine having to stitch their heads all the time). In the old way, I would have to inherit the base abstract class into a new one and write code there. This makes for very inefficient machines (no wonder they rarely get their targets in the movies, too much custom programming and not enough testing).

With the new method, I can send custom behavior “on the fly” during runtime and have the O/S simply execute that behavior instead.

Ok, I think that we get the point of the Strategy Pattern and why it’s useful, now let’s raise the bar once again.

Enter the Unity framework, let’s take a look at the following code:

public interface ITargetFinder
    {
        void FindTarget();
    }

    public abstract class RobotTerminator
    {
        private ITargetFinder _targetAcquisition;

        public RobotTerminator(ITargetFinder targetAcquisition)
        {
            this._targetAcquisition = targetAcquisition;
        }

        public void FindTarget()
        {
            this._targetAcquisition.FindTarget();
        }
    }

Our new code is much better, but there is still some level of strictness around it. Wouldn’t be great if we could simply alter the behavior of our machine not only at runtime but also through configuration? Right now, we have to pass an ITargetFinder interface (so we have to build a real object that implements this interface and send it over as a parameter). But we would have to write at least some code so that we could configure behavior at runtime for our machine. We don’t have to turn it off but we still have some degree of code to write in order to tell the system to alter the behavior.

Take a look at the following:

public interface ITargetFinder
    {
        void FindTarget();
    }

    public static class TargetFinderFactory
    {
        public static ITargetFinder GetTarget()
        {
            // get target through configuration
            return null;
        }
    }

    public abstract class RobotTerminator
    {
        private ITargetFinder _targetAcquisition;

        public ITargetFinder targetAcquisition
        {
            get { return this._targetAcquisition; }
            set { this._targetAcquisition = value; }
        }

        public RobotTerminator()
            : this(TargetFinderFactory.GetTarget())
        { }

        public RobotTerminator(ITargetFinder targetFinder)
        {
            this._targetAcquisition = targetFinder;
        }

        public void FindTarget()
        {
            this._targetAcquisition.FindTarget();
        }

This is a bit more interesting. We now have a factory that will crank out targets like muffins, when our Robot comes online it will automatically get an assignment through the factory. The behavior can also be changed during runtime by simply changing the target finder of the object. We can even go as far as specifying a target immediately or having the default read the configuration file. Much better indeed.

This is much better, but Unity can make it even better, let’s take a look at it:

public interface ITargetFinder
    {
        void FindTarget();
    }

    public abstract class RobotTerminator
    {
        private ITargetFinder _targetAcquisition;

        [Dependency]
        public ITargetFinder targetAcquisition
        {
            get { return this._targetAcquisition; }
            set { this._targetAcquisition = value; }
        }

        public void FindTarget()
        {
            this._targetAcquisition.FindTarget();
        }
    }

Where are our constructors? Why are they gone? And where is our target factory? Our machines are going to be standing idle if they have no targets to find.

And what is that [Dependency] attribute?

[Dependency] is an attribute that tells Unity that the property is a Dependency and needs Unity to initialize/assign it for us. For reference purposes, check out the following code:

IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers["targetOne"].Configure(container);

            RobotTerminator newRobot = container.Resolve<RobotTerminator>();

What does it do? Well, the first section basically tells Unity to load a configuration file that will explain to it which types to load depending on the configuration file. The last line of code essentially instantiates our class into an object and tells Unity to look for any Dependencies (that is what the [Dependency] attribute is for) and will essentially invoke the Setter method of the property and pass it a concrete object.

We have greatly remove some code from our RobotTerminator class and consequently also removed responsibilities. Which is turn is a good practice because it makes the class simpler to understand. We moved the responsibility of finding targets to Unity and depending if we choose configuration files or not (which is our decision, the designer/programmer) Unity will in the end use the settings that we create and Hand out objects when necessary to the objects that will use them. The great thing is that we have done all of this while making our code much easier to maintain and potentially remove quite a bit of issues as well. With the option of moving out the decision of passing which objects (removed our factory) we have also further decoupled our system and now have a degree of coupling that is as far as can be. Loose coupling is good, it basically means that you have less shackles to maintain – shackles, as you may imagine are as bad in real life as in code.

Unity can also help you not only with Properties (our example was specific to the Strategy Pattern and Unity) but can also help you create Object factories that can return objects that are controlled (or orchestrated, if I can use the term) through configuration files.

Do you remember program output? How come computers can send output to files, printers or screens evenly? Well Unity can help you achieve this level of flexibility without going insane trying to figure out the plumbing to implement all of this.

Resources:

What you will need:

Any Video Converter

Zune Sync Software (included with Zune)

The trick is so simple, I was dying of laughter when I figured it out:

First off, download “Any Video Converter” from the link above.

Second, once installed, fire up the “Any Video Converter” software, go to EDIT –> OPTIONS and set the OUTPUT folder (on top) to one of the folders that the Zune software monitors for video files.

Third, set the format in “Any Video Converter” to either WMV or MP4 – make sure that you set the proper resolution (320x240) frame rate (auto) and audio bitrate (128+).

Fourth, open up YouTube, go to a list of videos and simply drag and drop the URL into “Any Video Converter”.

Finally, click “CONVERT” and watch the software download the YouTube videos, convert them and drop them into the Zune-monitored folder for videos. The Zune sync software will then pick up those videos and sync them to your Zune – if you are in MP4 or WMV mode it may not even have to do any conversion (depending on your settings).

Congratulations, you now have YouTube videos to go.

Unfortunately, if like you you think that some sort of RSS feed would be perfect – well – you are going to have to continue to wait. Even if most computers today can play many file formats it seems like the Zune Sync software isn’t quite there yet.

I love podcasts, I especially love audio novels told by authors. I have my favorite authors (oddly, I can cite more authors on the web than I can actually cite authors that I read in the past) but I won’t list them here. The purpose of this post is not to try to sell who I think are the best.

What I would like to say this morning is that, unfortunately, nothing new came out this morning. Sometimes, life gets in the way of podcast authors (they do this for free, therefore, after the day job, eating, family and walking the dog – it comes last in the list) and I didn’t get any new content.

Which brings me to a point: Those guys invest a lot of effort and time to provide free content, I love what they do and I love what they deliver.

Now if there was only a way that I could support a few of these guys, perhaps clicking on their ad links?

Yes, that is a house air vent as a front scoop

BugTracker.NET is an excellent piece of software which can be found here.

The description on the BugTracker.NET site is:

BugTracker.NET is a free, open-source, web-based bug tracker or customer support issue tracker written using ASP.NET, C#, and Microsoft SQL Server (or its free cousin, SQL Server Express). It is in daily use by thousands of development and customer support teams around the world.

For those that are looking for a flexible open source helpdesk system, I highly recommend it.

Our need here is that we have several customer web applications running in our hosting infrastructure and we started to receive reports of errors with either incomplete descriptions or without any description at all.

The best solution found here is to use a component from ASP.NET called HealthMonitoring.

The principle is simple, publish events and tracking from the application to a destination. The destination can be just about anything: File, SQL Table, E-Mail, etc. Since this is built on top of the provider model – it is very easy to customize and extend.

Now to the point of this post, we have created a BugTracker WebEvent Provider for ASP.NET (2.0 or above) that can be configured to log events to BugTracker itself.

If you use the following configuration in the <system.web/> section of your ASP.NET app:

<healthMonitoring>
  <providers>
    <add name="BugTrackerWebEventProvider"
type="BugTrackerWebEventProvider.BugTrackerWebEventProvider" bufferMode="Notification" buffer="true" Username="username" Password="password" URL="http://url_to_bugtracker/insert_bug.aspx?"  ProjectID="bugtracker project id"/>
  </providers>
  <rules>
    <add name="LogAllEvents" eventName="All Errors" provider="BugTrackerWebEventProvider"/>
  </rules>
</healthMonitoring>

You will be effectively logging “Errors” as new requests/bugs to BugTracker.NET – it is important to understand however that while this is very nice to fill up the database you must be ready to deal with the load and use BugTracker effectively to link and deal with the issues that are created. Our systems have several thousands of users, you can imagine how a client can panic if 50 users all hit a section that triggers a semi-handled exception that happens to be logged in the system regardless.

I have included a demo application below to demonstrate how to set up the provide within the web.config so that you can easily make it fit within your development/production projects.

Personally, I would use this provider mostly in a “client UAT/QA” phase or in production – I don’t recommend it in development.

And here is the same provider, in release build