Là, tu ne me montres qu'un scénario où un lance qu'UNE seule requête à chaque fois, jamais plusieurs en même temps. On est d'accord.
Et tu ne réponds pas à la question :
Citation:
Envoyé par joel.drigo
Version imprimable
Là, tu ne me montres qu'un scénario où un lance qu'UNE seule requête à chaque fois, jamais plusieurs en même temps. On est d'accord.
Et tu ne réponds pas à la question :
Citation:
Envoyé par joel.drigo
Si j'ai dit qu'il peu en avoir plusieurs en même temps:Citation:
Envoyé par joel.drigo
17:00:10 une autre requête
17:00:10 une autre requête
c'est la même seconde
Ok, ça aurait été plus clair si tu l'avais explicité avec des mots. Mais soit. Bon, le format du fichier n'est super pratique non plus, mais admettons.
Mais ça ne répond toujours pas à la question que j'ai posée.
Citation:
Envoyé par joel.drigo
Bah, des que toutes les requêtes ont finis de s’exécuter en même temps à 17:30:00, et que la ou les prochaines doivent s'exécuter à 17:30:03, il faut attendre 3 secondes pour qu'elles se lance
Non, mais une requête ça prend du temps pour s'exécuter.
Si on lance une requête à 17:00:00 et quelle dure 10 secondes, elle se termine à 17:00:10, et que je suis censé en lancer une à 17:00:01, je la lance quand même immédiatement, même si celle qui a été lancée à 17:00:00 est encore en train de tourner ?
Donc, premièrement on lit le fichier et on le convertit en liste de listes de requêtes associées à une heure de démarrage. On a donc n lot de requêtes qu'on va programmer pour que chacun se lance aux heures prévues. Ce serait plus pratique si on avait des temps relatifs (compatibles avec un ScheduledExecutorService), mais on peut les calculer automatiquement, par différence avec la première. On obtient donc une liste de tâches, qu'on peut scheduler pour qu'elles s'exécutent qu'une seule fois, au bout d'un délai. Une tâche à en entrée une liste de requêtes. Ce qui permet de déterminer un nombre de threads (un par requête). Bien sûr, selon la configuration, on pourrait avoir un nombre considérable de threads, mais c'est comme ça (il faut soit changer la config, soit s'en contenter). On peut utiliser un CachedThreadPool, ce qui permettra de recycler des threads, sans pour autant bloquer des requêtes si tous les threads sont en cours de requête, et sans avoir à se soucier de combien de threads il faut.
Si on était sûr (d'où ma question) qu'aucune requête ne peut être lancée alors que des requêtes précédemment lancées sont encore encore en cours, ce serait plus simple : après avoir lu le fichier en entier, on peut connaitre le nombre maximum de requêtes à exécuter en même temps, donc le nombre de threads maximum qu'il faut, et donc la taille du pool du schedulerService. Il suffit alors de parcourir les lignes du fichiers et de schéduler les requêtes correspondantes avec le délai correspondant (on a besoin que d'un ScheduledExecutorService et c'est tout).
Ouais, ben moi à l'arrache vu les contraintes, je me casserais pas la tête.
Je ferais un Thread maitre qui lit le fichier CSV et se synchronize sur le timing
A chaque temps de déclenchement, je lancerais 1 ou plusieurs thread avec chacun directement les paramètres de la requête qu'il dois exécuter.
Ainsi: pas besoin de synchro entre threads, chacun ayant ses tâches bien à lui
Le thread gérant le temps n'a pas grand chose comme travail a faire et peu s'ensortir avec des sleeps ou un timer bien calibrés.
La solution propre: utiliser un scheduler genre quartz auquel tu file toutes les tâches à effectuer et tu calibre son nombre de thread pour qu'il y aie en aie en suffisance. Moins de dev à faire, plus de chose à apprendre.
Oui c'est ça, merci. et comment faire pour dire qu'une autre requête peut s"exécuter même si celle d'avant n'est pas terminé?Citation:
Envoyé par joel.drigo
Bah, justement, en les exécutant chacune par un thread différent. C'est l'inverse qui plus compliqué surtout quand les requêtes doivent être lancée à une heure particulièreCitation:
Envoyé par vLemaistre