2013-01-22 10 views
7

Chciałbym zapytać, jakie jest najlepsze podejście do uruchomienia długiego procesu z serwletu java. Mam aplikację internetową i kiedy klient wykonuje żądanie, uruchamia serwlet. Ten serwlet powinien pobrać pewne parametry z żądania, a następnie uruchamia proces. Ten proces może zająć dużo czasu, więc muszę go uruchomić osobno. Po zakończeniu tego procesu wysyłany jest e-mail z wynikami.Jakie jest najlepsze podejście do uruchomienia długiego procesu z serwletu java?

Z góry dziękuję.

Odpowiedz

5

Użyj puli wątków. Za każdym razem, gdy otrzymasz żądanie, utwórz zadanie i prześlij je do puli wątków. Zapewni to, że zbyt wiele żądań nie doprowadzi serwera do kolan, ponieważ masz kontrolę nad tym, ile wątków współbieżnych możesz mieć i ile zadań może czekać w kolejce oczekujących zadań w puli wątków.

Zobacz javadoc dla Executors i ThreadPoolExecutor.

1

widzę dwie możliwości, aby to zrobić:

  1. Tworzenie oddzielnego wątku dla każdego (podejścia puli wątków) zadań. Jest to możliwe, ale potencjalnie może powodować problem z wydajnością.
  2. Utwórz drugą aplikację. Na przykład możesz zapisać parametry do DB. Druga aplikacja będzie monitorować ten DB z pewnymi przerwami i coś z tym zrobić. Zamiast DB można użyć jakiegoś menedżera kolejek wiadomość jak WebSphere MQ

Drugie podejście ma tę zaletę: jeśli aplikacja nie jest w stanie przetworzyć żądania teraz z jakiegoś powodu, to aplikacja może powrócić do niego później

2

choć brzmi to trochę niebezpieczne, że wywołanie serwletu spawnuje proces (bez odpowiednich funkcji dławiących), możesz odrodzić proces używając Runtime.getRuntime().exec(). Znacznie lepiej byłoby użyć ProcessBuilder do przygotowania argumentów procesu i odrodzenia go.

2

Zwykle tego typu czynności są przekazywane do innego typu modułu aplikacji, takiego jak komponent bean sterowany komunikatami, który wydaje się być najczystszym i zgodnym ze standardami rozwiązaniem dla mnie. Chociaż większość serwerów nie będzie narzekała, jeśli utworzysz własne wątki (co jest zabronione przez standard, ale rzadko egzekwowane), ilość zarządzania potrzebna do utworzenia własnej kolejki zadań i wspólnego środowiska wykonawczego naprawdę nie jest tego warta.

Powiązane problemy