Можа асноўны паток завершыцца ў RESTful вэб-сэрвісу, а працоўны плынь працягваецца?

У мяне ёсць RESTful вэб-сэрвіс Java, які будзе выклікацца прыкладна кожныя 10 секунд іншага працэсу. Калі ўмовы з'яўляюцца правільнымі, то вебсервис павінен выканаць патэнцыйна шырокі працэс ETL (скажам, 10 - 20 секунд). Тым не менш, мы хочам, каб вярнуцца да выклікаламу дадаткам адразу з указаннем карыснай нагрузкі быў паспяхова дастаўлены на вэб-сэрвіс.

Кароткі выклад патрабаванняў:

  • аўтэнтыфікацыі і Праверка ўваходных параметраў.
  • Калі праверка трывае няўдачу, якая вяртаецца памылка ў XML.
  • Пачніце нітка выканання працэсу ETL. Працэс будзе адбывацца толькі пры пэўных умовах.
  • Зварот xml з указаннем карыснай нагрузкі дастаўлены і праверка ўваходных дадзеных.

Я закадаваны гэта і, здаецца, для запуску правільна. Але гэта не здаецца правільным. Нітка я стварыў патэнцыйна працаваць даўжэй, чым асноўны паток вэб-службы.

Хто-небудзь хоча, каб паказаць мне на лепшы спосаб зрабіць гэта?

1

3 адказы

што менавіта правільны спосаб зрабіць гэта. што "не здаецца правільным» пра рашэнне?

маё адзінае прапанова была б, што вы не павінны проста запусціць тэмы воляй-няволяй. вы павінны мець нейкі агульны ExecutorService кіраўнік гэтым працэсам ETL патокаў. што дасць вам бачнасць у тое, што было распачата, і да гэтага часу працуе, а таксама магчымасць абмежаваць/кантраляваць колькасць фонавых працэсаў (і, магчыма, мець справу з любымі ізгоямі расстрэлаў).

Вы таксама можаце вырабіць свой родам «JobId» для запушчанага працэсу і вяртанне, што да абанента. то вы можаце дадаць выклік да вашага API, які кліент можа выкарыстоўваць для праверкі стану работы.

1
дададзена
Дзякуй за ідэі. Я ажыццявіў ExecutorService ў Одноточечный. Я таксама выкарыстоўваю інтэрфейс Callable <> у маім класе разьбы, так што я магу адсочваць вынікі разьбы, а затым увесці код для праверкі ўцякаюць патокаў.
дададзена аўтар BigRedBettaFish, крыніца

У якасці альтэрнатывы вы можаце падзяліць абавязкі, падачы заданні і выкананне задачы. У вас ёсць частка прадстаўлення ўніз ўжо - вашы вэб-службы атрымлівае запыт, правярае яго, але замест таго, спараджаючы паток, каб выканаць яго адразу ж вы можаце захаваць яго захоўваюцца на знешнім сховішча.

Тады ёсць простае планавае заданне (Quartz) працуе на хрон, каб падабраць новыя задачы і выконваць іх.

Плюсы такога падыходу мацней развязка і больш гнуткасці сістэмы (вэб-сэрвіс, будучы ўніз не ўплывае на выкананне задачы, і наадварот). Зэк з'яўляюцца больш рухомыя часткі (кампаненты) у сістэме.

У любым выпадку, бягучая ўстаноўка працуе, і вы на правільным шляху.

0
дададзена
<Р> ... Тым не менш, мы хочам, каб вярнуцца да выклікаламу дадаткам адразу   што паказвае на карысны груз быў паспяхова дастаўлены на вэб-сэрвіс ...

Падобна на тое, што вы хочаце вярнуць поспех/правал паведамленні непасрэдна пасля праверкі, а затым зноў, калі яны ўтрымліваюць адказ паспяховага запыту.

Хоць няма ніякіх тэхнічных прычын гэта не будзе працаваць, у тыповым RESTful абмену вэба-сэрвісе ёсць 00:59 HTTP выклік, каб запытаць суадносіны, у якім гэтая архітэктуры зломіць патэнцыйна вяртання два адказы на адзін запыт. Гэта, верагодна, заблытаць кліентаў, якія ня вас ці вашай кампаніі.

Я мог бы прапанаваць рэалізацыю дадатковай паслугі зваротнага выкліку, якая можа быць запытана асінхронна з білетам, які вяртаецца ў першым запыце службы. Гэта мае дадатковае перавага, не блакіруе службы 1, калі вы чакаеце, каб вярнуць вынік вашай здзелкі.

Запуск іншы паток для транзакцыі добра да таго часу, пакуль ваша нагрузка нізкая. Калі яна становіцца занадта высокай вашы запыты пачнуць тайм-аўт, калі вы не зможаце пачынаць тэмы

0
дададзена