Tuesday, 28 November 2017

Unity and HTTP non-blocking long-term running tasks in Web API

If to continue discussing UNITY we can take a look at the corresponding challenging task ;)

So, we need release UI thread and return to the user message that "long running task started" and at the same time logic must be executing in background.

According to our approach described in the previous article we know that during each controller creation dependency resolver calls BeginScope() and created scope stores all references for instances that needed for resolving any type according to defined UNITY settings for types.

And it's important to write that stuff correctly.

Following code will raise exception "Entity framework DbContext already disposed".


[HttpPost]
[Route("MyAction")]
[AllowAnonymous]
public async Task ReleasingUIThreadOnLongRunningExecution()
{
     await handler.Execute();
     return Ok("My long running execution started");
}

The reason is that after the action executed the scope will be disposed and all instances in it will disposed too.

Here you can see right solution.

  • We get a thread from ThreadPool and assign work to it
  • We create new scope
  • Resolve our handler
  • Execute it
  • Dispose scope


        [HttpPost]
        [Route("MyAction")]
        [AllowAnonymous]
        public async Task ReleasingUIThreadOnLongRunningExecution()
        {
            System.Web.Hosting.HostingEnvironment.QueueBackgroundWorkItem(
             async ct =>
            {
                using (var scope
                      = GlobalConfiguration.Configuration
                              .DependencyResolver.BeginScope())
                {
                    var handler = scope.GetService(typeof(MyLogicHandler)) 
                       as MyLogicHandler;

                    if (handler != null)
                    {
                        await handler.Execute();
                    }
                }
            });

            return Ok("My long running execution started");
        }

Friday, 24 November 2017

"activity GUID" or "entire web request GUID" in Web.API + NLog logging activities

What if your legacy project uses your custom LOGGER class as a singleton and you want mark log messages with Request GUID to be able determine whole scope of logs for specific HTTP request?

Nowadays we using async/await and can't use Thread.ManagedThreadId in nlog messages cause threads can be different according to threads switching.

In case of singleton LOGGER task looks impossible, but there is a new feature in NLOG which solve this. All you need is to use tracing correlation id

protected void Application_BeginRequest(object sender, EventArgs e)
{
    Trace.CorrelationManager.ActivityId = Guid.NewGuid();
}

How it works?

Here there is some disassembled code

namespace System.Diagnostics {
    public class CorrelationManager {
        private const string transactionSlotName 
           = "System.Diagnostics.Trace.CorrelationManagerSlot";
        private const string activityIdSlotName 
           = "E2ETrace.ActivityID";
        
        internal CorrelationManager() { }
 
        public Guid ActivityId {
            get {
                Object id = CallContext.LogicalGetData(activityIdSlotName);
                if (id != null)
                    return (Guid) id;
                else
                    return Guid.Empty;
            }
            set {
                CallContext.LogicalSetData(activityIdSlotName, value);
            }
        }
     .....
   }
}


namespace System.Runtime.Remoting.Messaging{    
    [System.Security.SecurityCritical]  // auto-generated_required
    [Serializable]
    [System.Runtime.InteropServices.ComVisible(true)]
    public sealed class CallContext
    {
        private CallContext()
        {
        }

        ....
        
        public static void LogicalSetData(String name, Object data)
        {
            ExecutionContext ec 
              = Thread.CurrentThread.GetMutableExecutionContext();
            ec.IllogicalCallContext.FreeNamedDataSlot(name);
            ec.LogicalCallContext.SetData(name, data);
        }
   
        .....
    }
}


And finally we have

    [ClassInterface(ClassInterfaceType.None)]
    [ComDefaultInterface(typeof(_Thread))]
    [System.Runtime.InteropServices.ComVisible(true)]
    public sealed class Thread : CriticalFinalizerObject, _Thread
    {
        ......

        [SecurityCritical]
        [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
        internal ExecutionContext GetMutableExecutionContext()
        {
            Contract.Assert(Thread.CurrentThread == this);
#if DEBUG
            Contract.Assert(!m_ForbidExecutionContextMutation);
#endif
            if (m_ExecutionContext == null)
            {
                m_ExecutionContext = new ExecutionContext();
            }
            else if (!ExecutionContextBelongsToCurrentScope)
            {
                ExecutionContext copy = 
                    m_ExecutionContext.CreateMutableCopy();
                m_ExecutionContext = copy;
            }
 
            ExecutionContextBelongsToCurrentScope = true;
            return m_ExecutionContext;
        }
         
        ...... 
    }


Here we can see mutable ExecutionContext concept. The same way it works for principles (IPrinciple interface which is stored in thread). So, we can see that approach works in async/await environment.

internal static IPrincipal Principal
{
    [System.Security.SecurityCritical]  // auto-generated
    get
    {
         return Thread.CurrentThread.GetExecutionContextReader()
               .LogicalCallContext.Principal;
    }
 
    [System.Security.SecurityCritical]  // auto-generated
    set
    {
         Thread.CurrentThread.GetMutableExecutionContext()
               .LogicalCallContext.Principal = value;
    }
}

Thursday, 23 November 2017

TIP! VS 2017 ctrl + click wrong behavior.

Lately, ctrl + click in VS 2017 with resharper worked incorrectly.

That behavior can be fixed with tools -> options -> text editor -> disable 'enable mouse click to perform Go to Definition'

or you can check corresponding solution on StackOverflow

Sunday, 19 November 2017

Unity & Web.API. What you should know.

Nowadays we know SOLID principles well. We know the importance of DIP/DI. But what if you think that all products from Microsoft are the best and you want use them and in case of dependency injection you want to use Unity (originally part of Enterprise Library). So, how to use it correctly within a WEB application (WEB API or MVC). The question is easy, but there are some concerns :)

Different lifetime mananagers

For Transient instances, we use TransientLifetimeManager. In that case Unity creates and returns a new instance for every call for Resolve(). This lifetime scope can be used for any object if it's needed. For example, for object encapsulating system resources like connections, synchronization primitives (should be implemented disposed pattern). But in that case there is some important thing we need to take into consideration dependency injection containers follows the rule that for transient object there is no calling dispose method, so you should do that by yourself.

For Singleton instances, we use ContainerControlledLifetimeManager. Single object for all containers. Dispose method will be called on calling container's dispose methods

For Per Request instances, we use HierarchicalLifetimeManager. Inherits ContainerControlledLifetimeManager and works like ContainerControlledLifetimeManager, but in case of HierarchicalLifetimeManager child containers resolve it's own instance of an object.
Note!!! It's mandatory that it must be used for such object like EF DbContext, NHibernate Context. Can be used for many objects from the BLL and DLL (services, managers, commands, queries, repositories, etc.) if they are not needed to be transient or singleton

For Per Tread instances, we use PerThreadLifetimeManager. It resolves instances per thread. Note!!! For threads in thread pool instances are cached, so for objects as DatabaseContext (EF, NHibernate) we can't use this lifetime manager and should use HierarchicalLifetimeManager.

How to use (example)


public class UnityContainerBuilder
{
    public static IUnityContainer Build<TLifetimeManager>()
      where TLifetimeManager : LifetimeManager, new()
    {
        var container = new UnityContainer();

        container
         .RegisterType<IEmailSender, EmailSender>(new TLifetimeManager())
         .RegisterType<IMyEfDbContext, MyEfDbContext>(new TLifetimeManager())
         
     }
}


public class StartUpContext
{
    public StartUpContext(IAppBuilder owinAppBuilder, 
        HttpConfiguration globalConfiguration)
    {
        this.OwinAppBuilder = owinAppBuilder;
        this.GlobalConfiguration = globalConfiguration;
    }
    public IAppBuilder OwinAppBuilder { get; private set; }
    public HttpConfiguration GlobalConfiguration { get; private set; }
    public IUnityContainer UnityContainer { get; set; }
}


public static class StartUpContextExtensions
{
    public static StartUpContext SetupDI(this StartUpContext context)
    {
        var container 
            = UnityContainerBuilder.Build<HierarchicalLifetimeManager>();
        context.GlobalConfiguration.DependencyResolver 
            = new Unity.WebApi.UnityDependencyResolver(container);
        context.UnityContainer = container;
        return context;
    }
}


    new StartUpContext(owinAppBuilder, GlobalConfiguration.Configuration)
        .SetupDI();

Here we see 2 important things

1) For basic behavior we use HierarchicalLifetimeManager
2) Inside dependency resolver there is invocation of container.CreateChildContainer()

UnityDependencyResolver code looks like:


public class UnityDependencyResolver : UnityDependencyScope, 
    IDependencyResolver, 
    IDependencyScope, 
    IDisposable
  {
    public UnityDependencyResolver(IUnityContainer container)
      : base(container)
    {
    }

    public IDependencyScope BeginScope()
    {
      return (IDependencyScope) 
        new UnityDependencyScope(this.Container.CreateChildContainer());
    }
  }



How it works

Dependency resolver resolve all dependencies for controller (all objects we pass in controller as parameters if we use constructor injection). Corresponding objects are being resolved using corresponding lifetime managers described in settings. And it works as expected, our dependencies have per request lifetime scope.

Useful TIP

Let's assume that we need to have some validations according to data in db before we process our controller action. We can make a child class from DelegatingHandler and add some validation logic inside. But how should we create an EF DB context to make queries, there are 2 possible ways:

1) Resolve MyDbContext instance
2) Create MyDbContext by calling a constructor

We need to know that first approach works not in all cases. In that case, before resolve context, we need to create a child container each time we do resolve otherwise it will resolve instance from parent container which will be a singleton. That will cause issues on retrieving data from DB (Not closed DbReader for example).

Links

I want to mention here some links connected with the topic.

Friday, 17 November 2017

interlocked vs lock. specific case.

The article is about of tricky usage of INTERLOCKED!! Lets consider following scenario...

  • We use any service or several services for running/triggering scheduled tasks (for example VisualCron) and we have a Web API which starts some logic invocation which is aimed to do some long-running background work.
  • There is no matter where API is being hosted, it can be hosted within Windows Service or Web Application.
  • We need to be sure that only one command is running at any specific time.
  • Also, we need understand that we can consider a more advanced scenario where Web API can be have multiple instances in other words it can be organized in Web Farm.

So, How can we handle this.

The most straightforward solution is to use lock() statement, in that case all Web API calls will be added to queue right in place of lock statement. Of course, for that particular case is it's not a good idea because of 2 things:

  • we will use additional resource in term of web server. There is a limit of I/O threads. It is not so worth thing if we use async/await statements, but nevertheless, if the API process is pretty loaded it can reduce bandwidth much more
  • we can wait response for some time and even it can fall on server by server timeout.

There is an option to skip that queue and use Interlocked in C#. Consider the following example..


   
    [AllowAnonymous]
    public class TaskController
    {
        private readonly MyTaskCommand _myTaskCommand;
        private static long _myTaskRunsCount = 0;

        [HttpPost]
        [Route("api/Task/RunMyTask")]
        public async Task RunMyTask()
        {
            try
            {
                var prevValue = Interlocked.Read(ref _myTaskRunsCount);
                Interlocked.CompareExchange(ref _myTaskRunsCount, 1, 0);
                var newValue = Interlocked.Read(ref _myTaskRunsCount);

                if (prevValue != newValue)
                {
                    var commandResult = await _myTaskCommand.Execute();

                    if (commandResult.Success)
                        return Ok(commandResult.Result);
                    else
                        return InternalServerError(
                          commandResult.GetException());
                }
                else
                {
                    return Ok($@"Finished without any process. 
One instance is currently running.");
                }
            }
            finally
            {
                Interlocked.CompareExchange(ref _myTaskRunsCount, 0, 1);
            }
        }
}

This example sets flag to Int64 static variable. The flag determines that the command is being run by any application thread. If another thread tries to set it and fails we have a message that "the work is already being done by another thread" in output, otherwise it executes the command. One important thing here is that on any exception we set our flag into initial state, so future threads can run command correctly.

Of course in terms of WEB Farm, this approach will work only within the level of any single WEB Server instance. At the same time we need to admit that collision can take place in very specific case of WEB Farm, viz., calls to WEB API can be routed to different WEB Server instances at any specific time on concurrent WEB API calls from different sources (by source in that case we consider any Service that calls API or any work station that calls API through browser). That behavior of balancing incoming calls is base on how load balancer is tunned.

Possible solutions:

  • Create a level of security for calling this specific URL (can be done in different ways). The main idea is to give access to that action only for particular work instance of task scheduling tool (task scheduling tool can be a SAAS solution or solution written by yourself
  • Tune balancer that way that it will route all calling to API action on a specific web server instance
Note that solution to store duplicating flag (storing 2 separate flags for Web Farm level and instance level) in any distributed cache or in any database can cause collisions too.
Hope you enjoyed!