Expiration d'une requête Web Api?

Bâtiment sur la suggestion de Mendhak, il est possible de faire ce que vous voulez, mais pas exactement de la manière que vous voudriez faire, sans sauter à travers quelques cerceaux. Faire sans un filtre pourrait ressembler à quelque chose comme ceci:

public class ValuesController : ApiController
{
    public async Task<HttpResponseMessage> Get( )
    {
        var work    = this.ActualWork( 5000 );
        var timeout = this.Timeout( 2000 );

        var finishedTask = await Task.WhenAny( timeout, work );
        if( finishedTask == timeout )
        {
            return this.Request.CreateResponse( HttpStatusCode.RequestTimeout );
        }
        else
        {
            return this.Request.CreateResponse( HttpStatusCode.OK, work.Result );
        }
    }

    private async Task<string> ActualWork( int sleepTime )
    {
        await Task.Delay( sleepTime );
        return "work results";
    }

    private async Task Timeout( int timeoutValue )
    {
        await Task.Delay( timeoutValue );
    }
}

Ici, vous recevrez un délai d'attente, car le "travail" nous faisons prennent plus de temps que le délai d'attente.

À faire ce que vous voulez avec un attribut est possible, mais pas idéal. C'est la même idée de base, comme avant, mais le filtre peut être utilisé pour exécuter l'action par la réflexion. Je ne pense pas que je recommanderais cette voie, mais dans cet exemple artificiel, vous pouvez voir comment il pourrait être fait:

public class TimeoutFilter : ActionFilterAttribute
{
public int Timeout { get; set; }
public TimeoutFilter( )
{
this.Timeout = int.MaxValue;
}
public TimeoutFilter( int timeout )
{
this.Timeout = timeout;
}
public override async Task OnActionExecutingAsync( HttpActionContext actionContext, CancellationToken cancellationToken )
{
var     controller     = actionContext.ControllerContext.Controller;
var     controllerType = controller.GetType( );
var     action         = controllerType.GetMethod( actionContext.ActionDescriptor.ActionName );
var     tokenSource    = new CancellationTokenSource( );
var     timeout        = this.TimeoutTask( this.Timeout );
object result          = null;
var work = Task.Run( ( ) =>
{
result = action.Invoke( controller, actionContext.ActionArguments.Values.ToArray( ) );
}, tokenSource.Token );
var finishedTask = await Task.WhenAny( timeout, work );
if( finishedTask == timeout )
{
tokenSource.Cancel( );
actionContext.Response = actionContext.Request.CreateResponse( HttpStatusCode.RequestTimeout );
}
else
{
actionContext.Response = actionContext.Request.CreateResponse( HttpStatusCode.OK, result );
}
}
private async Task TimeoutTask( int timeoutValue )
{
await Task.Delay( timeoutValue );
}
}

Ce pourrait alors être utilisée comme ceci:

[TimeoutFilter( 10000 )]
public string Get( )
{
Thread.Sleep( 5000 );
return "Results";
}

Cela fonctionne pour les types simples (chaîne de caractères) qui nous donne: <z:anyType i:type="d1p1:string">Results</z:anyType> dans Firefox, mais comme vous pouvez le voir, la sérialisation n'est pas l'idéal. À l'aide de types personnalisés avec ce code exact sera un peu problématiques autant que la sérialisation va, mais avec peu de travail, cela pourrait être utile dans certains cas de figure. Que les paramètres de l'action se présentent sous la forme d'un dictionnaire au lieu d'un tableau pourrait également poser des problèmes en termes de paramètre de la commande. Évidemment le fait d'avoir un réel soutien pour ce serait mieux.

Autant que la vNext des choses, ils pourraient bien être la planification pour ajouter de la capacité à faire côté serveur délais d'attente pour les API Web depuis MVC et contrôleurs d'API sont en train d'être unifiée. S'ils le font, il ne sera probablement pas par le biais de la System.Web.Mvc.AsyncTimeoutAttribute de classe, car ils sont explicitement la suppression de dépendances sur System.Web.

À compter d'aujourd'hui, il ne semble pas que l'ajout d'un System.Web.Mvc entrée à la project.json fichier fonctionne, mais cela pourrait bien changer. Si elle le fait, alors que vous ne seriez pas en mesure d'utiliser le nouveau cloud optimisée cadre avec ce code, vous pourriez être en mesure d'utiliser le AsyncTimeout attribut sur le code qui est uniquement destiné à exécuter avec le plein .NET framework.

Pour ce que ça vaut, c'est ce que j'ai essayé d'ajouter à project.json. Peut-être une version spécifique aurait rendu plus heureux?

"frameworks": {
"net451": {
"dependencies": { 
"System.Web.Mvc": ""
}
}
}

Une référence à elle apparaît dans l'Explorateur de solutions de la liste des références, mais il le fait avec un point d'exclamation jaune indiquant un problème. L'application elle-même renvoie à 500 erreurs lors de cette référence reste.

Rendre votre vie plus facile, dans votre base de contrôleur ajoutez la méthode suivante:

    protected async Task<T> RunTask<T>(Task<T> action, int timeout) {
var timeoutTask = Task.Delay(timeout);
var firstTaskFinished = await Task.WhenAny(timeoutTask, action);
if (firstTaskFinished == timeoutTask) {
throw new Exception("Timeout");
}
return action.Result;
}

Maintenant la chaque contrôleur qui héritent de votre contrôleur de base peuvent accéder à la méthode RunTask. Maintenant, dans votre appel d'API le RunTask méthode juste comme ça:

    [HttpPost]
public async Task<ResponseModel> MyAPI(RequestModel request) {
try {
return await RunTask(Action(), Timeout);
} catch (Exception e) {
return null;
}
}
private async Task<ResponseModel> Action() {
return new ResponseModel();
}