Что-то  запутался.   

Надо в web приложении, основанном на Spring MVC создать "wait page" (страничка с "подождите, ваш запрос выполняется") с показом реального времени оставшегося до конца обработки задания.

Сгоряча наваял вариант с запуском отдельного потока, "стучащего" о ходе дела через атрибут сессии.

Потом вспомнил, что самостоятельные игрушки с потоками в web не есть здорово (по многим причинам, все это легко найти в google) и надо бы пользоваться возможностями, которые любезно предоставляют всякие там JBoss и прочие.

Что совсем не радует, т.к. конкретная реализация привязывает к серверу, кроме того совсем уж не ясно как быть с Tomcat, который кажется вообще такой возможности не предоставляет (т.е. потоки хоть обзапускайся, но и последствия сам расхлебывай). Для Tomcat пока наплевал на все и успешно использую ThreadPoolTaskExecutor 

Собственно вопрос, как можно грамотно реализовать wait page или, есть ли универсальный API для асинхронного запуска задач (Quartz, насколько я понимаю, для web не спасение, т.к. не может тесно взаимодействовать с любым контейнером сервлетов?)  ?

P.S. Ах, да, очень желательно без JavaScript !

carper, 

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




Совсем без него вы не обойдетесь.

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

Вот, по минимуму, что хотелось бы иметь.
По максимуму, мне потоки позволяют еще не держать пользователя в ожидании, а позволить ему размещать следующие данные из той же формы, не дожидаясь окончания обработки предыдущих.

В общем-то все вышеозначенное реализовано и отлично работает с использованием потоков.



Пока почти обошелся.
Беда в том, что приложение ориентировано в том числе и на клиентов на которых JavaScript не работает.

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



Это сообщение отредактировал(а) Vasay - 22.11.2010, 16:48

Оставил бы, но в будущем возможен переезд из-под Tomcat, боюсь что тут-то все мои вольности с потоками и повылезут. 



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

Но ведь можно сделать общение иным способом.

Приветствуется абсолютно любое решение проблемы под названием "пользователь должен видеть, что его запрос обрабатывается и знать сколько надо подождать" и вся эта фигня должна без танцев с бубнами подыматься под разными серверами.

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

На томкате не поедет тогда.


 Отдельно форма рефрешится или страница? 

Страница, для wait page это практически не замедляет работу и не надо связываться со фреймами, что хорошо.

Но без отдельного потока для длительного задания, не удается получить ход выполнения работы.
А когда пользователю тупо пишут "ждите неизвестно сколько", он начинает нервничать, метаться и делать глупости.    

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

можно заюзать hornetq

Верно. Вот пока наплевал на сервер, ввел свои потоки (разумеется как демоны) и получилось красиво ...

Но когда будешь деплоить безобидный проект/ик на какой-нибудь сервер, то получишь проблемы, особенно если хостер решит применить балансировку загрузки и т.п.

Ну сам-то еще ладно, а если развивать систему будет кто-то еще, то он  проблему под названием "работает, но иногда падает" будет решать пол года, проклиная того "криворукого индусского программиста".   

И не надо ля-ля про чтение документации, на 100% все плюшки все равно никто не вычитает, а под функциональные тесты такого рода радость обычно не подпадает.




Это совсем не обязательно завязано с применением тяжелых серверов и JMS.   

Например, у нас было вполне себе enterprise приложение, обслуживающее материальные потоки по поставкам сырья, включая корабельные перевозки, причем это было действительно интенсивно используемое приложение, решающее большой круг задач, без бумажных дублеров.
Так вот, оно крутилось на сервере под i386 и было написано на Clipper с самодельно реализованными пессимистическими и оптимистическими блокировками. И работало как часики. 
Не знаю насколько уж там была стройная архитектура, но на снежный ком оно не походило и вполне поддавалось развитию. Умерло только вместе с компанией. R.I.P.

С тех пор сильно поменялись технологии, но не бизнес.

Хм, задумался а как он интегрируется с Tomcat?
Мне ведь нужна не сама по себе JMS, а гарантия ее беспроблемного использования.

Вот тут http://wash-inside-out.blogspot.com/2010/0...ith-tomcat.html вроде как ясно следует, что придется лезть в настройки Tomcat.

А чего собственно я ожидал?
Для JAVA хостинга это не радует, но попробую, если не удастся решить проблему малой кровью.

Спасибо!