Quartznet: Prise en charge asynchrone/en attente

Merci pour la demande, nous pouvons étudier les possibilités avec la version 3.0.

Je vais deuxièmement ceci - ce serait formidable que Quartz prenne en charge async/wait.

Avons-nous une idée d'un calendrier pour la version 3.0 ?

J'ai commencé le travail de révision async/wait et c'est toute une entreprise. Je ne donnerai pas d'échéancier pour ne pas vous décevoir, mais je vous tiendrai au courant. Il y aura certainement des versions alpha et bêta à tester.

J'ai apporté des modifications massives aux API et aux composants internes pour mieux prendre en charge async/wait avec commit https://github.com/quartznet/quartznet/commit/f78cf38e3f3ed6b76f044b9b0aa78e66dc6c5b62 . Cela devrait offrir une meilleure efficacité interne lorsqu'il s'agit de faire fonctionner l'infrastructure Quartz.

Les emplois réels restent problématiques. Si nous voulons que les travaux prennent en charge les tâches asynchrones, cela signifierait également abandonner l'utilisation actuelle du pool de threads. Les threads de travail ne peuvent pas être ressaisis correctement lorsque l'attente est en cours d'utilisation - cela briserait les garanties d'avoir autant de travaux en cours d'exécution qu'il y a de threads de pool de threads en cours d'exécution.

Prendre en charge async/wait au niveau du travail signifierait s'appuyer sur le pool de threads .NET et une plus grande séparation du flux d'exécution. J'hésite un peu à faire ce changement...

Pouvez-vous suggérer un modèle alternatif pour me permettre d'invoquer des opérations en attente dans les travaux, si ce travail ne va pas être entrepris?

Pour parler spécifiquement de la rupture de la promesse de ne pas avoir plus de travaux qu'il n'y a de threads dans le pool de threads : ne pas rompre cette promesse n'est-il pas l'un des arguments pour faire ce travail en premier lieu ? Lorsqu'il y a beaucoup d'E/S en cours, nous ne voulons pas bloquer les threads en mode utilisateur en attendant l'achèvement des E/S car cela signifie que nous avons beaucoup de planification préemptive des threads pour interroger l'achèvement et l'épuisement des E/S. limites de thread malgré le fait qu'il n'y a aucun travail CPU utile sur eux. Donc, si nous voulons maximiser l'utilisation du processeur et des E/S, pourquoi ne pas autoriser plus de tâches que le nombre maximal de pools de threads, si cela signifie que nous pouvons laisser bon nombre de ces tâches en attente de congestion des E/S et ne pas essayer de thread.

@mleyb Je n'ai pas encore abandonné tout espoir, je continue de jouer avec des alternatives de mise en œuvre ...

@Jawvig Le mélange du pool de threads Quartz et du pool de threads .NET CLR a des conséquences qui peuvent être difficiles à communiquer.

Nous pourrions effectivement autoriser le démarrage de milliers de travaux en même temps lorsque nous avons une taille de pool de threads de 10. Tous les travaux démarrent et démarrent des opérations asynchrones, ainsi le thread de travail est renvoyé et de nouveaux travaux peuvent démarrer.

Nous pourrions avoir besoin d'un pool de threads spécial (basé sur TaskScheduler) pour le travail basé sur asynchrone qui se déclenchera du travail, mais cela devient alors intéressant. Cela m'amène à penser que ce pool de threads spécial ne devrait pas permettre la configuration de la taille car "cela dépend".

Je dirais que cela pourrait être bien jusqu'au moment où l'épuisement du pool de threads CLR se produit, disons qu'il s'agit d'une application ASP.NET qui a des demandes en file d'attente. Quartz a pu contourner l'épuisement en disposant de son propre pool de threads et en utilisant des tâches de synchronisation.

Donc je voulais juste soulever ces points qui pourraient être problématiques et c'est super que cette discussion ait lieu. Je veux entendre avec impatience toutes les opinions sur les avantages et les inconvénients sur la question.

Quelques pistes de réflexion :

• devrions-nous avoir l'interface IAsyncJob, retirer IInteruptableJob et faire en sorte que IJobExcutionContext contienne CancellationToken qui peut être utilisé à la fois pour les tâches asynchrones et synchronisées ?
• devrions-nous autoriser uniquement IAsyncJobs à s'exécuter sur un planificateur dont le pool de threads CLR est configuré comme seul pool de threads ?

Re : retrait IInterruptableJob : même si nous parlons d'une version majeure, je pense que nous devrions conserver IInterruptableJob pour la rétrocompatibilité. Je ne peux pas penser aux circonstances dans lesquelles annuler via un CancellationToken et aussi appeler Interrupt serait un problème. Quartz est légèrement gonflé, mais nous pourrions modifier le document de code pour indiquer que IInterruptableJob pourrait être supprimé dans les futures versions et que l'utilisation de CancellationToken dans IJobExecutionContext est préférable.

Re : interface IAsyncJob : je pense que c'est la bonne chose à faire.

Re : Exécuter IAsyncJob s sur un planificateur avec des pools de threads hybrides : j'ai l'impression que ce serait une mauvaise idée. Lorsque le CLR est utilisé pour fournir un ThreadPool réglé sur lequel TPL peut effectuer ses opérations, il semblerait erroné de saper les hypothèses sur lesquelles il a été construit en ayant un ensemble de threads supplémentaires assis dans le même processus dont il n'a aucune visibilité. . Donc, pour être clair, je serais en faveur d'insister pour autoriser uniquement l'exécution de IAsyncJob sur un planificateur où le pool de threads CLR est configuré comme le seul pool de threads.

J'ai fait la première itération avec le concept maintenant, l'exemple 16 a du code pour introduire le IAsyncJob :

https://github.com/quartznet/quartznet/tree/quartznet-3/src/Quartz.Examples/example16

IJobAsync ne serait-il pas la convention de dénomination appropriée qui serait conforme aux autres noms de modèles asynchrones ?

Le 26 juillet 2015, à 6h23, Marko Lahma [email protected] a écrit :

J'ai fait la première itération avec le concept maintenant, l'exemple 16 a du code pour introduire le IAsyncJob :

https://github.com/quartznet/quartznet/tree/quartznet-3/src/Quartz.Examples/example16

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je crois que le modèle commun avec async _methods_ est de postfixer les noms de méthodes avec Async (ce que Quartz ne fait pas actuellement). Je dirais donc qu'avec un nom de classe comme AsyncJob, le message sur l'intention est meilleur.

@lahma

ASP.NET app that has requests queuing up. Quartz has been able to circumvent exhaustion by having its own thread pool and using sync jobs.

Si je ne me trompe pas, vous parlez de "contre-pression". J'ai rencontré ce problème de tâche asynchrone mise en file d'attente par un producteur de messages de longueur très rapide et pratiquement infini, qui a mis en file d'attente tant de messages en une minute que le processus manque de mémoire.

J'ai utilisé des extensions réactives à ce moment-là, et le remplacer par le flux de données de Tpl a parfaitement résolu le problème. Que diriez-vous d'utiliser ActionBlock :
https://msdn.microsoft.com/en-us/library/hh194684%28v=vs.110%29.aspx

var executor = new ActionBlock<IJobAsync>(async job => await job.ExecuteAsync(), 
    new ExecutionDataflowBlockOptions{
         MaxDegreeOfParallelism = maxTasksLimit,
         BoundedCapacity = 1
    });

 // scheduler
SchduleJob(job) {
     await executor.SendAsync(job)

1. Nous pouvons limiter l'exécution simultanée de tâches.
2. La capacité de la mémoire tampon de l'exécuteur est limitée, donc si la limite est atteinte, l'expéditeur "attendra".

@vchekan merci ! J'ai besoin d'étudier cela un peu plus.

ActionBlock est assez pratique. Je l'utilise pour implémenter la limitation par rapport à une API tierce.

Pour tirer parti du commentaire de Vadim, nous aurions probablement besoin de faire plus que await executor.SendAsync(job) afin de mettre en œuvre des stratégies de ratés, etc. Nous pourrions Task.Wait(TimeSpan) et traiter cela comme un raté si le délai expire.

Quoi qu'il en soit, à part cela, je voulais commenter les noms des méthodes API dans l'exemple que vous avez mis en place, Marko. Comme vous l'avez noté, la plupart des méthodes asynchrones que l'on rencontre sont suffixées "Async", alors que celles de votre exemple ne l'étaient pas. De plus, de nombreuses méthodes seront devenues asynchrones sans avoir changé de nom, par exemple IScheduler.Start , IScheduler.Interrupt . Je pense que cela pourrait avoir trop de conséquences imprévues sur le code existant lors de la mise à niveau. Étant donné qu'il s'agit de méthodes void , le code client se compile toujours avec lui et navigue à travers la création de tâches sans attendre leur achèvement.

Puis-je suggérer de conserver les méthodes existantes et d'ajouter de nouvelles méthodes qui se terminent par "Async" ? Les méthodes existantes peuvent être implémentées en tant que méthodes synchrones qui appellent les méthodes Async et .Wait() sur leurs tâches. J'ai le sentiment que cela fournira un chemin de mise à niveau beaucoup plus facile pour les personnes sans effets secondaires involontaires.

Toutes mes excuses si je manque quelque chose d'évident à propos de l'intention, ici !

@Jawvig Je suis toujours un peu sur la clôture de l'utilisation du postfix Async. Je ne vois pas l'intérêt d'avoir à la fois des versions synchronisées et asynchrones des méthodes, car async est désormais préféré. Avoir une API publique uniquement asynchrone soulève alors la question de savoir s'il est logique d'avoir un suffixe Async. Casser la compilation est bien sûr agréable pour que le consommateur de l'API sache à quoi se préparer.

J'ai envoyé un ping au projet MassTransit à ce sujet (ils subissent le même changement) et j'ai eu la discussion ici https://github.com/MassTransit/MassTransit/issues/314 .

Il existe un test séparé pour détecter qu'il n'y a pas de méthodes void asynchrones (qui sont les tueurs).

@lahma Je n'aime pas vraiment cingler, mais y a-t-il des plans ou des estimations quand (ou si) cela va être fait et relâché dans la nature ?

d'accord - j'aimerais vraiment commencer à l'utiliser

:+1: pour quelques infos :)

Vous pouvez suivre la progression de la branche quartznet-3 https://github.com/quartznet/quartznet/tree/quartznet-3 , il y a maintenant des versions nocturnes mais l'API a déjà de nombreux changements pour prendre en charge le modèle.

Désolé d'être un parasite, mais je me demande simplement si vous avez un calendrier pour savoir quand Quartz 3 sera prêt. Mon projet repose sur l'achèvement de cette fonctionnalité pour le moment. Il semble que vous ne puissiez pas exécuter une requête HttpClient dans un travail Quartz pour le moment si vous avez besoin d'un comportement synchrone et que vous avez un intervalle inférieur au temps d'aller-retour de la requête Http. Quartz n'"attendra" pas la valeur de retour et vos requêtes commenceront à se chevaucher. Je suppose que ce nouveau type de travail asynchrone résoudrait ce problème ? J'utilise mono et je pense que HttpClient est la seule option et qu'il n'a que des requêtes asynchrones.

Les emplois Asyn eux-mêmes ne sont peut-être pas la solution miracle. Vous pouvez forcer le résultat synchrone pour HttpClient en utilisant client.GetAsync(_address).Result qui évalue la requête. Est-ce que ça marche pour toi? Vous avez également mentionné le chevauchement des tâches, qui peut être géré avec [DisallowConcurrentExecution] si cela aide.

Et oui, j'ai esquivé la question initiale, car je ne veux pas faire de promesses difficiles à tenir.

J'apprécie votre réponse rapide (et honnête). Pouvez-vous me donner un trimestre où vous espérez actuellement sortir ? Comme Q3 2016, Q4 2016, Q1 2017 ?

J'ai trouvé une option similaire à celle que vous avez fournie dans les 2 minutes suivant la publication (cela se produit toujours ?). Je l'ai déjà bien fonctionné, donc pas de soucis là-bas.

Je devrais profiter de l'occasion pour exprimer mon amour pour Quartz. Je l'ai utilisé pour construire un microframework pour faciliter la configuration, l'écriture et le déploiement de microservices et Quartz en est le cœur. J'ai eu la chance de tomber dessus avant de réécrire quelque chose qui était à moitié aussi bon. Merci à tous les contributeurs de l'avoir mis à disposition.

Je pense que nous pouvons commencer à donner de la qualité alpha dans les deux prochaines semaines. Les bases sont solides (calculs de déclenchement, gestion des données du magasin d'emplois - ils n'ont pas eu de changements) mais à mesure que le travail évolue autour de l'asynchronisme/attente et des pools de threads et de l'API leur stabilité ne peut être garanti. La communication à distance sera également abandonnée et devra être réécrite au-dessus de l'API HTTP/Web afin que le contrôle à distance du planificateur ne fasse pas partie des premières suppressions.

Une mise à jour pour ceci ?

La construction alpha sans gestion à distance devrait être réalisable très bientôt sur le flux nuget.org.

Alpha 1 a atterri sur NuGet, veuillez consulter l' annonce . Il reste encore beaucoup à faire, mais il devrait maintenant être plus facile de botter les pneus.

Je ferme ce sujet pour l'instant, merci pour votre patience !

Des scènes incroyables ! Merci - j'ai hâte d'essayer ça