HttpClient reuse and throughput

If you are creating HttpClient everytime you make an outbound http call from your application then with all due respect you are doing it wrong. There are multiple resources available across the internet that explain the fact that HttpClient instances should be reused throughout the lifetime of the application as it provides better throughput.

If you create an instance of httpclient for each outbound http call, as the number of parallel outbound increases, you will start to see issues like port exhaustion or connection error etc.

Sources: Link # 1 Link # 2

Best Practices?

1. Even though HttpClient should be reused, it is to be kept in mind that the responsibility is on you to ensure that your code does not cause trouble. For example - 

      a. You should maintain different HttpClients for each base URL. If you try to manipulate base urls for parallel calls, you are asking for trouble.

      b. Any Http headers that you intend to send as part of Http request, should be included and sent as part of HttpRequestMessage. We should avoid setting headers in HttpClient.DefaultHeaders and manipulating them for each call. Headers in HttpClient are .NET dictionary (not ConcurrentDictionary) and therefore it is not thread-safe :).

2. It is better to use any of the DI containers to create and maintain Singleton instance of HttpClient or a custom Factory.

3. Any other ServiceApiClients that use Http as underlying protocol should either ensure that HttpClient is resued or you need to ensure that you its implementation is such that you can reuse a single instance of that across calls. In fact, there are many out of the box Azure SDK Clients recommend that instances should be resued e.g. DocumentDbClient, ServiceBusClient, Azure Storage Client etc.

.NET Core Web App as Windows Service : Handling slow startup

.NET core is fast becoming the first choice of development framework as it brings the benefit of cross-platform compatibility. Of course, it is fast too.

If you make a .NET core web application, you would notice that the IWebHost presents us with 2 ways to host the web application 

1. Run
2. RunAsService

RunAsService is quite useful if you want to host your .NET core web application as a windows service instead of a standalone executable. RunAsService does not give us with much flexibility though. 

Enhancement

If you want to handle what happens before ASP.NET core starts or after it has started, you are better suited to inherit from "WebHostService" class and use that to host the asp.net web application.

It is described here.

With this, you will be able to hook your custom code in following places.

1. OnStarting
2. OnStarted
3. OnStopping
4. OnStopped

Enhancement 2

If your start up code is a bit slow, then you have further challenges. In classic windows service projects, you get an option to request additional start up time though code. However, you can not do that in .NET core's web host as those hook points are not available.

So what do you do?

Couple of options:

1. Move your slow start up logic to background thread using Tasks.
2. Use parallel tasks.
3. Use timer to call back into the logic to perform start up work after some time :).

If you can't inject, use Actions/Funcs

We all know that Dependency Injection is a good thing. It is aligned with SOLID principles and gives us far more control over object lifecycles.

But, what to do when dealing with static methods?

Consider this for an example.

public interface ILogger
{
    void Log(string message);
}

public interface IRepository
{
     void DoSomething();
}

public class Logger : ILogger
{
 ......
}

public class Repository : IRepository
{
     private ILogger logger;
     public Repository (ILogger logger)
    {
        this.logger = logger;
    }
    
    public void DoSomething()
   {
        TestClass c = new TestClass();
        c.ToGuid(); 
       ......
   }
}

public static class MyExtensions
{
      public static string ToGuid(this TestClass class)
      {
           // How do i get my logger here for logging??
      }
}


It is a frequent situation where you are writing extension methods or utility methods. In most cases you SHOULD not need any dependencies but for argument's sake assume we need it.

Well, we can make use of Action or Func to ensure that abstraction is maintained. So I can potentially change the code like:

public static class MyExtensions
{
      public static string ToGuid(this TestClass class, Action logAction)
      {
               if(logAction != null) { logAction("my message"); }
      }
}

public class Repository : IRepository
{
     private ILogger logger;
     public Repository (ILogger logger)
    {
        this.logger = logger;
    }
    
    public void DoSomething()
   {
        TestClass c = new TestClass();
        c.ToGuid(new Action(logger.Log); 
       ......
   }
}

Don't play with items stored in InMemory cache

How often do you use a form of in-memory store in your application? My guess is "a lot". There are multiple variations of the in-memory store that you can use - MemoryCache, Custom Dictionary, Http Cache, Application Cache etc. They all use process memory as the store for keeping the information (read objects). One great thing about in-memory cache is that it is FAST :). There are downsides though.

1. It adds to the total memory hogged by the process over its lifetime. Unless you have a good eviction strategy in place, the objects will just remain there forever. That may or may not be an issue depending on the context of the application.

2. General implementation of such cache is to keep objects as-is in its store. e.g.

Cache.Add("Key", obj);

Above code means that whosoever holds a reference to the object can still make a change to the object - what does that mean?

Say, 

1. Class 1 and Class 2 have reference to one object Obj1. 
2. Class 1 saved the object to cache. 
3. Class 2 made a change to the object in its implementation. 
4. Class 1 retrieves object from cache.

Class 1 will get the updated values and that can surprise the program logic :)

So what should we do?

Couple of options:

1. Serialize the object before storing in cache. e.g.

Cache.Add("Key", Serialize(obj));

2. Clone the object before storing in cache.

Hope this helps in catching strange issues if you use in-memory cache.

PS: Distributed cache stores do not have this issue as the objects are serialized before being transferred over to the cache store.

Task.Run vs Task.FromResult

So it is possible that you have an interface with multiple implementations and one of the implementations is IO bound and the other is not. So in order to support both implementations, you end up creating an interface method that looks like following:

Task GetRowsAsync(int[] idList);

Let us say one implementation tries to get result by querying a SQL Server database and the other one tries to get result by querying a in-memory database.

So your database implementation might be like:

public Task GetRowsAsync(int[] idList)
{
   ... some logic
    await ExecuteQueryAsync(....); // await an async operation
    return x;
}

What about an in-memory implementation? Should you use a code like #1 or #2?

public Task GetRowsAsync(int[] idList)

{

    return Task.FromResult(x);

}

public Task GetRowsAsync(int[] idList)

{

    return await Task.Run(() => { return x; });

}

Well, let us perform an experiment.

        static async Task GetNumber()

        {

            return await Task.Run(() => { return 1000; });

        }

        static async Task GetNumber1()

        {

            return await Task.FromResult(1000);

        }

        static void Main(string[] args)

        {

            Console.WriteLine("Started");

            while(Console.ReadLine() != "quit")

            {

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

                Console.WriteLine(GetNumber().Result);

            }

      }

Run the code by choosing GetNumber and GetNumber method. Watch the process statistics in process explorer.

GetNumber:

GetNumber1:

Learning: Task.Run does try to schedule work even though there is nothing to wait on :).

Action Filters : Do Not Keep State

One thing to remember : Do not keep state in Action Filters of any kind. There is no exception to this rule.

Point to note is that the action filter instance is created only once and then shared across the HTTP requests.

Let us build an example.

I will create 2 action filters.

public class TestFilter : IActionFilter
    {
        private int counter = 0;

        public void OnActionExecuted(ActionExecutedContext filterContext)
        {
            counter++;
            filterContext.HttpContext.Response.Headers.Add("Counter", counter.ToString());
        }

        public void OnActionExecuting(ActionExecutingContext filterContext)
        {
            
        }
    }

    public class TestFilter2 : ActionFilterAttribute
    {
        private int counter = 0;

        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            counter++;
            filterContext.HttpContext.Response.Headers.Add("Counter1", counter.ToString());
        }

        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {

        }

    }

Let us apply one of the filter as Global Filter and one filter specifically to an Action.

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
        {
            filters.Add(new TestFilter());

        }

[HttpGet]
        [TestFilter2]
        public ActionResult DoSomething()
        {
            return new JsonResult() { JsonRequestBehavior = JsonRequestBehavior.AllowGet, Data = "Test" };
        }

Now, if we run the application, check the http headers after a few refresh.

You would notice that the counter keeps increasing with each request.

Learning: Do not write an action filter that keeps state.

Generics and Reflection and Async :)

Sometimes, using Reflection based code can lead you into true wilderness. Especially when your classes and methods make use of generics. Throw in async/await pattern implementation too. You suddenly start to ask why are you writing code using reflection in the first place :).

I ran into a similar situation recently.

I had a generic method like following:

public class Test
{      public async Task < T[] > Method(arguments);
{
////....
}
}

Now let us say you have to invoke this method on-demand for any type defined in your object models. What are your options?

1. Write a huge switch case where each case belongs to a type and makes a call for each type. That works but requires a lot of maintenance. Whenever you add a new type, you have to add to that switch case.

2. Change signature of the method to start return JSON and deserialize it in the calling method.

3. Call this method through reflection :).

var method = typeof(Test).GetMethod("Method"); 

var methodReference = method?.MakeGenericMethod("type that needs to be used"); 

var response = methodReference.Invoke(instance of Test, arguments);

But wait, this is an async method. You will be getting a Task, not the actual result.

So what do we do?

Hmm... We can not cast it to Task because T is dynamic. What else can we do?

Change the method signature to return generic Array instead of T[].

public async Task < Array > Method(arguments);

and change the calling method to following:

var response = (await) ((Task < Array >)methodReference.Invoke(instance of Test, arguments);

Solved :).

finally block runs always :)

Sometimes the obvious things are easiest things to overlook. Consider the below scenario as an example. I need to ensure that only 1 caller can run a code block at any point in time and other callers should be rejected during that period. Does the below code work correctly then?

public class MyClass
{

private static bool canOthersProcess = true;
private static object obj = new object();

public void MyMethod
{
            try
            {
                // do something
                lock(obj)
                {
                    if (canOthersProcess)
                    {
                        canOthersProcess = false;
                    }
                    else
                   {
                        return;
                    }
               }

               // do something

            }
            catch(Exception)
            {

            }
            finally
            {
                canOthersProcess = true;

            }
}
}

The thing to remember about Finally block is that it always runs :)

Change this to following to make it work correctly.

 try
            {
                // do something
                lock(obj)
                {
                    if (canOthersProcess)
                    {
                        canOthersProcess = false;
                    }
                     else
                   {
                        return;
                    }
                 }

                       //do something
                       canOthersProcess  = true;

            }
            catch(Exception)
            {
                     canOthersProcess  = true;
            }

parameterize IN clause

Suppose you need to write a query that uses IN clause but you don't want to create a Stored Procedure. Using inline query is a possibility but not recommended. The only viable option is to use parameterized query. But it is a little tricky for IN clause.
Here is one work around you can apply.

            string sql = "SELECT * FROM dbo.TestTable A WHERE A.Name1 IN (__Keys__)";
            List values = new List() { "Name1", "Name2" };
            string parameterTemplate = "@name{0}";
            List parameters = new List();
            using (var conn = new SqlConnection(@"connString"))
            {
                using (var cmd = new SqlCommand())
                {
                    cmd.CommandType = System.Data.CommandType.Text;
                    int i = 0;
                    foreach(string val in values)
                    {
                        string paramName = string.Format(parameterTemplate, i);
                        parameters.Add(paramName);
                        cmd.Parameters.Add(new SqlParameter(paramName, values[i]));
                        i++;
                    }
                    sql = sql.Replace("__Keys__", string.Join(",", parameters));
                    cmd.CommandText = sql;
                    
                    cmd.Connection = conn;
                    conn.Open();
                    using (var reader = cmd.ExecuteReader())
                    {
                        while(reader.Read())
                        {
                            Console.WriteLine(string.Format("{0},{1},{2}", reader[0], reader[1], reader[2]));
                        }
                    }
                }
            }


Hope it helps.

Is Reflection that bad?

There is this generic notion that using reflection in code is bad. Main argument is that this kind of code is very slow. In fact, whenever you use Reflection in your code, you are bound to get a review comment to avoid reflection. However, there are scenarios where you need to use reflection - mainly to reduce the complexity of writing lot of repeated code.

Whenever I hear such things, my first reaction is - Have you measured how slow your code is? Performance is always relative and is always bound by a range. If your code responds within acceptable limits, there is no reason why you should rewrite code (painfully) just because it had reflection in it.

Let us take an example.

1. I have a base class and there are couple of class that inherit from it. Like following:

    public class A
    {
        public Guid Id { get; set; }
    }

    public class B : A
    {
    }

    public class C : A
    {

    }

2. Imagine I have a class that uses these like following:

    public interface IGenericInterface
    {
        object Get(string id) where T : A;
    }

    public class GenericInterfaceClass : IGenericInterface
    {
        public object Get(string id) where T : A
        {
            return default(T);
        }

    }

3. Let us make calls and measure.

GenericInterfaceClass genericInterfaceClass = new GenericInterfaceClass();
            int loopLength = 100000;
            Stopwatch sw = new Stopwatch();
            sw.Start();
            for (int i = 0; i < loopLength; i++)
            {
                var getGenericEntity = typeof(IGenericInterface).GetMethod("Get");
                Type t = null;
                if (i % 3 == 0)
                {
                    t = typeof(B);
                }
                else if (i % 3 == 1)
                {
                    t = typeof(A);
                }
                else if (i % 3 == 2)
                {
                    t = typeof(C);
                }

                var getGenericEntityReference = getGenericEntity.MakeGenericMethod(t);
                var originalEntity = getGenericEntityReference.Invoke(genericInterfaceClass, new object[] { default(Guid).ToString() });
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.ReadLine();

4. Above code runs the reflection code to invoke a method 100,000 times. Time taken : ~280 ms (in release mode).

5. That is not too slow actually.
6. If you are too much concerned with that, you can always optimize it further.

            var getGenericEntity1 = typeof(IGenericInterface).GetMethod("Get");
            ConcurrentDictionary dict = new ConcurrentDictionary();
            sw.Reset();
            sw.Start();
            for (int i = 0; i < loopLength; i++)
            {
                MethodInfo obj = null;
                if (i % 3 == 0)
                {
                    if(!dict.TryGetValue(typeof(B), out obj))
                    {
                        obj = getGenericEntity1.MakeGenericMethod(typeof(B));
                        dict.TryAdd(typeof(B), obj);
                    }
                }
                else if (i % 3 == 1)
                {
                    if (!dict.TryGetValue(typeof(A), out obj))
                    {
                        obj = getGenericEntity1.MakeGenericMethod(typeof(A));
                        dict.TryAdd(typeof(A), obj);
                    }
                }
                else if (i % 3 == 2)
                {
                    if (!dict.TryGetValue(typeof(C), out obj))
                    {
                        obj = getGenericEntity1.MakeGenericMethod(typeof(C));
                        dict.TryAdd(typeof(C), obj);
                    }
                }
                
                var originalEntity = obj.Invoke(genericInterfaceClass, new object[] { default(Guid).ToString() });
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);

            Console.ReadLine();
7. Time taken: ~100 ms (in release mode)
8. Remove the generics like following:

sw.Reset();
            sw.Start();
            for (int i = 0; i < loopLength; i++)
            {
                object originalEntity = null;
                if (i % 3 == 0)
                {
                    originalEntity = genericInterfaceClass.Get(default(Guid).ToString());
                }
                else if (i % 3 == 1)
                {
                    originalEntity = genericInterfaceClass.Get(default(Guid).ToString());
                }
                else if (i % 3 == 2)
                {
                    originalEntity = genericInterfaceClass.Get(default(Guid).ToString());
                }
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.ReadLine();

            return;
8. Time taken: ~15 ms (in release mode)

So, as you can see there are so many level of optimizations one can do depending on the kind of requirement you have. Specialized code will always run faster than generalized code. However, reflection itself is not that slow unless you are looking for extremely optimized code. 

Case of dependency resolvers :)

If you ever have a situation where you have to mix few of the Web based technologies in single solution, you would start to wonder why these different technologies have their own way of dealing with Dependency Injection and IoC containers.

For example:

MVC 5

Well, ASP.NET MVC5 has its own namespaces and DependencyResolver instances that can be updated. You can find examples here

ASP.NET Core

You need to use a different infrastructure ("Services") to inject and resolve the dependencies.

Web API

As per WebAPI documentation, you need to implement your own resolver by implementing IDependecyResolver interface available under System.Web.Http.Dependencies namespace. You can then replace the default resolver with your resolver by updating the instance of HttpConfiguration used by WebAPI.


SignalR

As per SignalR documentation, it is to be done through a static class called GlobalHost. It exposes the SignalR related DependencyResolver as a property and we can use that to register types so that SignalR related objects can be automagically be created.

public void Configuration(IAppBuilder app)
{
    GlobalHost.DependencyResolver.Register(
        typeof(ChatHub), 
        () => new ChatHub(new ChatMessageRepository()));
}

There is a interface IDependencyResolver too under its own dedicated namespace which can be used to write own resolver and assign the same to HubConfiguration class during start up. However, recommended way is to inherit from DefaultDependencyResolver and add custom logic - this is because DefaultDependencyResolver takes care of resolving SignalR related infrastructure.

wcf instance provider

Ever tried applying dependency injection container concepts in a WCF service? Well, you might say that not many people use WCF these days as majority of services are moving towards REST WebAPI. While that is true, it is also true that WCF gives us features and capabilities that a REST WebAPI has no support of. Anyhow, there is not much value to fight the urge to write a good WCF service with a decent DI logic.

All you have to do is to write an implementation of IInstanceProvider and apply a custom implementation of IServiceBehavior to the service.

IServiceBehavior:

public class CustomInstanceProviderBehaviorAttribute : Attribute, IServiceBehavior
    {
        public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection endpoints, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
            foreach (ChannelDispatcher cd in serviceHostBase.ChannelDispatchers)
            {
                foreach (EndpointDispatcher ed in cd.Endpoints)
                {
                    if (!ed.IsSystemEndpoint)
                    {
                        ed.DispatchRuntime.InstanceProvider = new DIInstanceProvider(DateTime.UtcNow.Ticks);
                    }
                }
            }
        }

        public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
        }

    }

IInstanceProvider

public class DIInstanceProvider : IInstanceProvider
    {
        private long ticks = 0L;

        public DIInstanceProvider(long ticksValue)
        {
            this.ticks = ticksValue;
        }

        public object GetInstance(InstanceContext instanceContext)
        {
            return new Service1(DateTime.UtcNow.Ticks);
        }

        public object GetInstance(InstanceContext instanceContext, Message message)
        {
            return new Service1(DateTime.UtcNow.Ticks);
        }

        public void ReleaseInstance(InstanceContext instanceContext, object instance)
        {
        }

    }

Service
    [CustomInstanceProviderBehavior]
    public class Service1 : IService1
    {
        private long ticks = 0L;

        public Service1(long ticks)
        {
            this.ticks = ticks;
        }

        public string GetData(int value)
        {
            return string.Format("You entered: {0} at {1}", value, this.ticks);

        }
     }

Point to note: Instance of IInstanceProvider is created only once when service starts and applies the service behavior. However the service instance is created by calling GetInstance method of IInstanceProvider.

Story Points : That elusive concept

I was recently involved in a meeting with a team that wanted to change story points of a User Story that they committed to deliver in the middle of the sprint. As much weird as it sounds, it did happen though and I was there. 

My first reaction was : Why?

Story points are a way of estimating the overall size of the User Story - Size includes effort, complexity and uncertainty. So if, during the implementation of the User Story, the team finds out that they estimated the size incorrectly (any of the 3 parts could have been wrongly estimated), teams should drop the User Story from current sprint and send it back to the backlog for further refinement. 
The reason is two folds:

1. Team is not good at estimating size.
2. User Story authors left too many things open to interpretation and team ignored those signs during story pint estimation

How can you try to address it?

1. Spend first 2-3 sprints in defining (or identifying) the User Stories that can be referred in later sprints. In the end, no estimation should be by gut feeling. There has to be verified baseline to work with. Most of the teams I have worked with forget to do this.

2. Prepare User Story structure in which scope of open ended specification is less. For Example: A Use story for a web page that has a grid needs to mention following - default sorting order, can user sort, default paging size, can user change page size, does grid have to refresh in place or are we ok to reload the page, Is the grid readonly or will user be able to update/delete/add a row, will grid hide columns if user resizes the page, will grid have its own scrollbar etc. In the end team needs to sets standards in terms of accepting a User Stories and things will follow.

Self hosting vs IIS hosting

Imagine that you have a requirement to have a web API that supports hosting in both IIS and a windows service (an example of self hosting).

If you use OWIN and ASP.NET then it is not very difficult. In fact if you build one application using OWIN, you can host it in multiple ways. We will try IIS-Express and Console App. Let us start.

1. Create a new Web Application. Choose Empty template.

2. Use nuget package "Microsoft.Owin.Host.SystemWeb" and "Microsoft.AspNet.WebApi.Owin".
3. Use "OWIN Startup" class.

4. Change Startup.cs.

public class Startup

    {

        public void Configuration(IAppBuilder app)

        {

            // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=316888

            var config = new HttpConfiguration();

            config.Routes.MapHttpRoute(

                "API Default", "api/{controller}/{id}",

                new { id = RouteParameter.Optional });

            app.UseWebApi(config);

        }

    }

5. Add a test controller e.g. ValuesController like following.

5. Test the url.

Now that web application is up, let us see how easily we can host the same application in an Console application and not duplicate the code.

1. Add a console application. Add reference of the web application in console application.

2. Add nuget package "Microsoft.AspNet.WebApi.OwinSelfHost".
3. Change Program.cs to following.

static void Main(string[] args)
        {
            using (var x = WebApp.Start(url: "http://locahost:9000/"))
            {
                Console.WriteLine("Started");
                Console.ReadLine();
            }

        }

4. Launch console app and access "http://localhost:9000/api/values".


Have fun.