Timeline for Launch threads continuously with predefined interval between threads
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2019 at 15:56 | vote | accept | Rouliboy | ||
| Nov 21, 2019 at 15:15 | answer | added | Theraot | timeline score: 2 | |
| Nov 21, 2019 at 14:06 | comment | added | Rouliboy |
Ok thanks, I understand way better, explanations are clear. But I do not think it matches with what I'm doing. Let me explain: on my REST client I have several endpoints (let say getToken and getData). Now I can have multiple users which request at the same time on of those endpoints. What I want is a way to add an intevral between each call. With your solution, it's more about fetching data every 100ms, but on my side I want to block the call for 100ms. But the users could not make any call for 1hour for example.
|
|
| Nov 21, 2019 at 13:59 | comment | added | Theraot | @Rouliboy alright, so, this is the difference between using Timer and using ScheduledThreadPoolExecutor: The timer executes ecverything in a single background thread. On the other hand ScheduledThreadPoolExecutor uses a thread pool, thus one or more threads. Now, ScheduledThreadPoolExecutor gives you two options: scheduleAtFixedRate which will execute at a given interval regardless of how long the execution takes, and scheduleWithFixedDelay which will execute with a given delay between executions. See scheduleAtFixedRate vs scheduleWithFixedDelay. | |
| Nov 21, 2019 at 13:50 | comment | added | Rouliboy | @Theraot thanks for explanations. Actually we do not care about response time. If Response takes 5s for each call, we can still make call every 100 ms.But even with your explanantions I do not see how to have this "shared" interval of 100ms between each call? | |
| Nov 21, 2019 at 13:47 | comment | added | Theraot | Also, please note I am saying request. I am not talking about waiting for a response. If you can make the requests asynchronously (that means, you can request and get the response later, without having the thread blocked waiting), then you are likely to be able to make the requests fast. | |
| Nov 21, 2019 at 13:46 | comment | added | Theraot | @Rouliboy overlap means that it will awake a thread to make a request even if there are other threads that haven't ended. That is, if you have an interval of 100ms without overlap, they will queue up when it takes too long to make the request. On the other hand, an interval of 100ms with overlap can have multiple threads requesting at the same time when they take longer than 100ms to make the request. If you do not want overlap (i.e. you want them to queue up), then Timer will work. Now, are requests slow enough that overlap matters? Using Timer, there would be no queue, if requests are fast. | |
| Nov 21, 2019 at 13:31 | comment | added | Rouliboy | @Caleth : multiple threads call call the REST client. | |
| Nov 21, 2019 at 13:31 | comment | added | Rouliboy | @Theraot : Some threads in my app will call 3-rd party API through a singleton REST client. I want that no matter which thread calls this client, an overlap of 100ms between calls. I do not think that timer will do the Job or I misunderstood something. | |
| Nov 21, 2019 at 13:10 | comment | added | Caleth | You only need threading in handling the responses, if at all. Making the requests can be centralised. | |
| Nov 21, 2019 at 12:06 | comment | added | Theraot | You want the execution to overlap, right? So ScheduledThreadPoolExecutor won't work for you. If that is the case... why? Surely you can make the request asynchronously fast enough so that overlapping is not a problem. Then even Timer would work. | |
| Nov 21, 2019 at 11:32 | history | asked | Rouliboy | CC BY-SA 4.0 |