Wpis z mikrobloga

Takie rozwiązanie to byłby raczej antypattern. W ustawieniach executor servicu ustawia się timeout wątku nie taska. Bo to właśnie wątkami zarządza, więc czemu na tym poziomie mielibyśmy ustawiać jakiś czas wykonywania taska. Mogę się mylić ale to raczej nie ta abstrakcja
  • Odpowiedz
@pjoter-syn: może niedoprecyzowanie albo użyłem mylnego nazewnictwa, ale w jednym wątku będzie jeden task.

Problem jest taki, że chciałbym mieć pule wątków wielkości X i wykonać Y wątków gdzie Y znacznie większe od X i tutaj zaczyna się problem. Bo wbudowane timeouty w Future / CompletionService w ogóle nie biorą pod uwagę faktu, że wątki mogą czekać w kolejce na wykonanie i timeout liczony jest od submita, a nie od faktycznego
  • Odpowiedz
@PortalZeSmiesznymiObrazkami: nie jestem pewny czy dobrze zrozumiałem, ale może lepiej w takim razie trzymać definicje tasków na jakiejś kolejce zamiast od razu tworzyć zbyt wiele wątków? wtedy mógłbyś ściągać z kolejki według capacity puli i odpalać wątek per definicja taska, dzięki czemu timeout ustawiony na poziomie wątku byłby ok, bo nie submitujesz od razu nadmiarowej ilości, tylko startujesz wyłącznie gdy jest na to miejsce w puli
  • Odpowiedz
@PortalZeSmiesznymiObrazkami: to zadziała, jeśli pula twoich wątków będzie bardzo specyficznie ustawiona.
https://docs.spring.io/spring-integration/api/org/springframework/integration/util/CallerBlocksPolicy.html
Z zerową kolejką (BlockingQueue) i tym Policy. CompletableFuture wtedy będziesz robił tak, że odpalasz taski (supplyAsync), a potem dajesz orTimeout(). Wtedy masz pewność, że task faktycznie zaczął się wykonywać, inaczej stałby zablokowany na statement z supplyAsync

To policy jest bardzo proste, więc nie musisz importować tej biblioteki, tylko copy-paste
  • Odpowiedz