Re: "throttled" ExecutorService?
Cédric Beust ♔ <[email protected]> Wed, 25 May 2011 10:18:09 -0700
| Newsgroups | gmane.comp.java.french.general |
|---|---|
| Message-ID | <[email protected]> |
La façon la plus simple à mon avis est de créer ta propre Queue qui
implémente tes contraintes et de la passer à un Executor standard. Pas
besoin de créer ton propre Executor.
Quelque chose comme ça:
public class ThrottledQueue<E> extends LinkedBlockingQueue<E> {
@Override
public boolean offer(E e) {
}
@Override
public boolean offer(E e, long timeout, TimeUnit unit)
throws InterruptedException {
}
@Override
public E take() throws InterruptedException {
}
}
Dans offer(), tu stockes l'information dont tu as besoin pour décider (par
exemple, l'heure actuelle) et ensuite, tu appelles super.offer().
Dans take(), tu fais tes vérifications:
- Différence de temps entre heure actuelle et la timestamp la plus
ancienne.
- Nombre de requêtes actuellement en cours d'exécution.
Si une de tes contraintes retourne false, tu bloques jusqu'à ce que ça
change, et à ce moment, tu retournes super.take().
--
Cédric
2011/5/25 <[email protected]>
> En fait je dois appeler un service web qui ne peut accepter plus de N
> requêtes par minute.
>
> Les appels à ce service sont faits via d’autres web services exposés aux
> clients de mon appli, et dont la fréquence d’appel est limitée par un autre
> moyen, et forcément à une fréquence différente, sinon ça serait trop
> simple ;-)
>
>
>
> Donc tant que mes clients ne solliciteront pas mon appli plus de N fois par
> minute, je veux faire transiter les appels sans délais à l’autre web service
> (en faisant un paquet de traitements métier au passage dans mon appli).
>
> Mais dès que la fréquence d’appel de mes clients dépasse N appels/minute
> alors je ne ralentis pas mes clients mais je mets les appels en attente et
> je limite la fréquence d’appel du service à N/minute.
>
>
>
> C’est pas difficile à implémenter mais s’il est possible de partir d’une
> base existante ça limiterait les risques de bugs dans ce composant.
>
>
>
> ScheduledThreadPoolExecutor pourrait en effet faire une bonne base de
> départ. En calculant le délai appliqué en fonction de la date du dernier
> appel y’a peut-être moyen de faire ça simplement.
>
>
>
> *De :* David Brassely [mailto:[email protected]]
> *Envoyé :* mercredi 25 mai 2011 11:56
> *À :* GODARD Patrice NRS
> *Cc :* * liste Java
> *Objet :* Re: "throttled" ExecutorService?
>
>
>
> Bonjour,
>
>
>
> Qu'est ce que tu entends par "limiter le rythme" ?
>
> Sinon, le ScheduledThreadPoolExecutor
> <http://download.oracle.com/javase/1,5.0/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html>ne
> répond t'il pas à ton besoin ?
>
> 2011/5/25 <[email protected]>
>
> Bonjour,
>
> J’ai besoin d’une sorte d’ExecutorService qui puisse limiter le rythme
> auquel les tâches qui lui sont soumises sont exécutées.
>
> Il n’y aurait qu’un seul thread dans le pool.
>
>
>
> Est-ce que ce genre de chose existe déjà ?
>
> Ca m’éviterait de réinventer la roue.
>
> J’envisage une extension d’ExecutorService ou un truc du genre.
>
>
>
>
>
>
>
> ********************************************************************************
>
> IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
>
> et peuvent etre protegees par la loi.
>
> Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
>
> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message
>
> et tous les fichiers eventuellement attaches.
>
> Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
>
> Tout message electronique est susceptible d alteration.
>
> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
>
> De meme, il appartient au destinataire de s assurer de l absence de tout virus.
>
>
>
> IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
>
> intended only for the named recipient(s) above.
>
> If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
>
> Any unauthorized view, usage or disclosure ofthis message is prohibited.
>
> Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
>
> Additionally the recipient should ensure they are actually virus free.
>
> ********************************************************************************
>
>
>
>
> --
> Brassely David
> adresse e-mail : [email protected]
>
> ********************************************************************************
> IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
> et peuvent etre protegees par la loi.
> Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message
> et tous les fichiers eventuellement attaches.
> Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
> Tout message electronique est susceptible d alteration.
> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
> De meme, il appartient au destinataire de s assurer de l absence de tout virus.
>
> IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
> intended only for the named recipient(s) above.
> If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
> Any unauthorized view, usage or disclosure ofthis message is prohibited.
> Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
> Additionally the recipient should ensure they are actually virus free.
> ********************************************************************************
>
>