Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > Использование потоков в web приложениях

Автор: carper 22.11.2010, 15:13

Что-то  запутался.    Надо в web приложении, основанном на Spring MVC создать "wait page" (страничка с "подождите, ваш запрос выполняется") с показом реального времени оставшегося до конца обработки задания. Сгоряча наваял вариант с запуском отдельного потока, "стучащего" о ходе дела через атрибут сессии. Потом вспомнил, что самостоятельные игрушки с потоками в web не есть здорово (по многим причинам, все это легко найти в google) и надо бы пользоваться возможностями, которые любезно предоставляют всякие там JBoss и прочие. Что совсем не радует, т.к. конкретная реализация привязывает к серверу, кроме того совсем уж не ясно как быть с Tomcat, который кажется вообще такой возможности не предоставляет (т.е. потоки хоть обзапускайся, но и последствия сам расхлебывай). Для Tomcat пока наплевал на все и успешно использую ThreadPoolTaskExecutor  Собственно вопрос, как можно грамотно реализовать wait page или, есть ли универсальный API для асинхронного запуска задач (Quartz, насколько я понимаю, для web не спасение, т.к. не может тесно взаимодействовать с любым контейнером сервлетов?)  ? P.S. Ах, да, очень желательно без JavaScript !

Автор: Vasay 22.11.2010, 16:09

carper,  А что за задача? Решений может быть много, в зависимости от того что конкретно вы хотите получить. Цитата  Ах, да, очень желательно без JavaScript ! Совсем без него вы не обойдетесь.

Автор: carper 22.11.2010, 16:20

Цитата(Vasay @  22.11.2010,  16:09 ) А что за задача? Вот workflow: - Есть форма, пользователь забивает пару значений и жмет submit. - Вместо этой формы появляется страничка с надписью: подождите выполнено N % - Периодически эта форма претерпевает рефреш (метатеги для браузеров не поддерживающих JavaScript и JavaScript для остальных), обращаясь за новым показателем оставшихся процентов. - Пользователю показывается страничка с той же формой и сообщением о happy end. Вот, по минимуму, что хотелось бы иметь. По максимуму, мне потоки позволяют еще не держать пользователя в ожидании, а позволить ему размещать следующие данные из той же формы, не дожидаясь окончания обработки предыдущих. В общем-то все вышеозначенное реализовано и отлично работает с использованием потоков. Цитата(Vasay @  22.11.2010,  16:09 ) Совсем без него вы не обойдетесь. Пока почти обошелся. Беда в том, что приложение ориентировано в том числе и на клиентов на которых JavaScript не работает.

Автор: Vasay 22.11.2010, 16:47

Цитата В общем-то все вышеозначенное реализовано и отлично работает с использованием потоков. ну и оставите потоки, если все отлично работает, или, как вариант - создайте демона вне сервера для обработки пользовательских данных.

Автор: carper 22.11.2010, 16:53

Цитата(Vasay @  22.11.2010,  16:47 ) ну и оставите потоки, если все отлично работает Оставил бы, но в будущем возможен переезд из-под Tomcat, боюсь что тут-то все мои вольности с потоками и повылезут.  Цитата(Vasay @  22.11.2010,  16:47 ) создайте демона вне сервера для обработки пользовательских данных. Это как? С учетом того, что обмен информацией о ходе выполнения приложения идет через атрибуты сессии.

Автор: Vasay 22.11.2010, 16:57

Цитата Это как? С учетом того, что обмен информацией о ходе выполнения приложения идет через атрибуты сессии. Но ведь можно сделать общение иным способом.

Автор: carper 22.11.2010, 17:11

Цитата(Vasay @  22.11.2010,  16:57 ) Но ведь можно сделать общение иным способом.  Приветствуется абсолютно любое решение проблемы под названием "пользователь должен видеть, что его запрос обрабатывается и знать сколько надо подождать" и вся эта фигня должна без танцев с бубнами подыматься под разными серверами.

Автор: vicod 24.11.2010, 20:55

может какую-то фантастическую схему с jms придумать?

Автор: garbuz 24.11.2010, 23:06

Цитата(vicod @  24.11.2010,  20:55 ) может какую-то фантастическую схему с jms придумать?   На томкате не поедет тогда. Цитата(carper @  22.11.2010,  16:20 ) Периодически эта форма претерпевает рефреш (метатеги для браузеров не поддерживающих JavaScript и JavaScript для остальных), обращаясь за новым показателем оставшихся процентов.  Отдельно форма рефрешится или страница?

Автор: carper 25.11.2010, 09:31

Цитата(garbuz @  24.11.2010,  23:06 ) Отдельно форма рефрешится или страница?  Страница, для wait page это практически не замедляет работу и не надо связываться со фреймами, что хорошо. Но без отдельного потока для длительного задания, не удается получить ход выполнения работы. А когда пользователю тупо пишут "ждите неизвестно сколько", он начинает нервничать, метаться и делать глупости.

Автор: kkorsakoff 25.11.2010, 12:30

Может скажу крамольную мысль, но я бы в данном случае использовал потоки. Дело в том, если у вас более менее серьезное enterprise приложение со стройной архитектурой, то да, лучше потоки не прикручивать. Но в данном случае у вас наверняка уже есть JMS либо какое-то другое асинхронное решение. А если это простой веб-сайт/админка, то используйте потоки и не парьтесь. Единственное, надо их делать как daemon thread. Совсем хорошо было бы повесить листенер на шатдаун веб-контекста и каким-то образом останавливать эти потоки. 99% процентов, что не вылезут ваши вольности нигде. Вся беда с запретом своих потоков, что они по сути не managed сервером. Ну и ладно, управляйте ими сами.

Автор: vicod 25.11.2010, 13:12

Цитата(garbuz @ 24.11.2010,  23:06) Цитата(vicod @  24.11.2010,  20:55 ) может какую-то фантастическую схему с jms придумать?   На томкате не поедет тогда. можно заюзать http://jboss.org/hornetq

Автор: carper 25.11.2010, 13:34

Цитата(kkorsakoff @  25.11.2010,  12:30 ) Вся беда с запретом своих потоков, что они по сути не managed сервером.  Верно. Вот пока наплевал на сервер, ввел свои потоки (разумеется как демоны) и получилось красиво ... Но когда будешь деплоить безобидный проект/ик на какой-нибудь сервер, то получишь проблемы, особенно если хостер решит применить балансировку загрузки и т.п. Ну сам-то еще ладно, а если развивать систему будет кто-то еще, то он  проблему под названием "работает, но иногда падает" будет решать пол года, проклиная того "криворукого индусского программиста".    И не надо ля-ля про чтение документации, на 100% все плюшки все равно никто не вычитает, а под функциональные тесты такого рода радость обычно не подпадает. Цитата(kkorsakoff @  25.11.2010,  12:30 ) если у вас более менее серьезное enterprise приложение со стройной архитектурой Это совсем не обязательно завязано с применением тяжелых серверов и JMS.    Например, у нас было вполне себе enterprise приложение, обслуживающее материальные потоки по поставкам сырья, включая корабельные перевозки, причем это было действительно интенсивно используемое приложение, решающее большой круг задач, без бумажных дублеров. Так вот, оно крутилось на сервере под i386 и было написано на Clipper с самодельно реализованными пессимистическими и оптимистическими блокировками. И работало как часики.  Не знаю насколько уж там была стройная архитектура, но на снежный ком оно не походило и вполне поддавалось развитию. Умерло только вместе с компанией. R.I.P. С тех пор сильно поменялись технологии, но не бизнес.

Автор: carper 25.11.2010, 13:53

Цитата(vicod @  25.11.2010,  13:12 ) можно заюзать hornetq  Хм, задумался а как он интегрируется с Tomcat? Мне ведь нужна не сама по себе JMS, а гарантия ее беспроблемного использования. Вот тут http://wash-inside-out.blogspot.com/2010/08/hornetq-jms-integration-with-tomcat.html вроде как ясно следует, что придется лезть в настройки Tomcat. А чего собственно я ожидал? Для JAVA хостинга это не радует, но попробую, если не удастся решить проблему малой кровью. Спасибо!

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)