Asynchronous Interceptors

Are async interceptors in the pipeline for this library?

This would be such a good feature, as it would allow for async actions before the invocation is proceeded.

I would not mind contributing to this, as long as I could get some architecture advice.

[hammett]

Not sure what you mean?
We have adjusted some of our infrastructure to use async by inspecting the "awaitable" of a return type, and if detected, add a continuation. Not sure this needs to be directly supported by the interceptor, but I'm interested in your proposal.

[joelweiss]

Even if I try to hook up a continuation like suggested on StackOverflow it will still not work properly if I want to call in the continuation invocation.Proceed() because the interceptor index gets decremented here, so it will call the first inceptor again and again.

[hammett]

I dont think calling proceed in the continuation is a good idea anyways, you wont get a Task instance until you run the actual method.

Looking fwd to your proposal.

[kkozmic]

We've had this discussion some time ago. It breaks the abstraction

On Thu, 3 Mar 2016, 10:34 hamilton verissimo notifications@github.com
wrote:

I dont think calling proceed in the continuation is a good idea anyways,
you wont get a Task instance until you run the actual method.

Looking fwd to your proposal.

—
Reply to this email directly or view it on GitHub
#145 (comment).

sent from my phone
Krzysztof

[joelweiss]

@hammett You are correct, but you can make it work if you return TaksCompletionSource<>.Task and when you get the final task you can await it and then call taskCompletionSource.SetResult(task.Result).

My scenario is I have an IFooService and when I call fooService.GetData() the first interceptor is a CacheInterceptor that tries to fetch the data from the cache asynchronasly and if it's not in the cache, I want to call invocation.Proceed() to the HttpInterseptor and make an asynchronous http call to get the data.

I was thinking something like this might enable my scenario.

    interceptors[currentInterceptorIndex].Intercept(this);
#if DOTNET40
    if (ReturnValue != null)
    {
        var returnType = Method.ReturnType;
        if (returnType == typeof(Task) || (returnType.IsGenericType && returnType.GetGenericTypeDefinition() == typeof(Task<>)))
        {
            await(Task)ReturnValue;
        }
    }

@kkozmic probably refers to #107 and that's probably more what @mlfletcher1988 is talking about.

This is what would be nice to have as an end user of the library:

https://gist.github.com/mlfletcher1988/7139ef2b31f18868f470

This is what I have had to currently do, which does not provide the opportunity to call async actions before the invocation has been proceeded:

https://gist.github.com/mlfletcher1988/0944537f72cf840e4e1f

[hammett]

this looks as a very specialized use of the interceptors and TPL. I'm not sure it makes sense to add support for this at Castle.Core level, especially since TPL comes with its own pandora's box.

Not really, it would just be a really good feature to allow async calls to be made before the intercepted invocation is proceeded.

[hammett]

I'll leave this up to @jonorossi and @kkozmic then.

[kkozmic]

I see no compelling reason. IMO it's a clear case of cost far outweighing the benefit

With some architecture advice I would be happy to implement this as a proof of concept.

Is there developer documentation/guidelines for contributing to the project?

@ghost - Contributing guide here.

https://github.com/castleproject/Core/blob/master/CONTRIBUTING.md

[alex-training]

Hi everyone,

Is there any progress being made on this?