Для успешной работы сервлету необходим сокет(клиент) - один для всех сессии. В связи этим вопрос - 
на какие подводные камни можно натолкнуться при реализации сокета в сервлете в связи с многопоточностью?
Где лучше создавать, удалять, хранить?

Предпологается создавать сокет в методе init() сервлета, а грохать в destroy()
Хранить socket и данные, прочитаные из сокета, которые необходимо вернуть в браузер предпологаю в ServletContext

 

Я не не очень понал вопроса.Зачем это всё ? Распиши подробней.   

vasko, просто это не получиться.

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

т.е. 

самый ужастный путь - запрещать апп  серверу создавать более одного сервлета, это возможно на уровне конфигурации вэб приложения, но это это смерть всех идей прозводительности заложенных в апп сервер

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

предполагать что  клиентов-сокетов у тебя может быть не один, и разбираться с этим  а это не факт что просто 
 

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

Сервлету необходимо взаимодействовать с другим модулем. Для связи между ними выбрал сокеты. В сервлете клиентский сокет, в модуле серверный сокет. 

В сервлете, в методе GET и POST если параметр "needAnswere != 0" необходимо отправить данные по сокету, иначе если для данного HttpServletRequest мы уже получили данные по сокету, мы запихиваем данные в HttpServletResponse.

Вопрос собственно в том, не будет ли накладок при работе с сокетом.  Безопасно ли сохранять сокет в ServletContext? 
Я это делаю что бы обезопасить себя от разных инстансов сервлета + MultiThread

Или можно в классе сервлета объявить сокет, в инит его инициализировать и безопасно пользоваться в GET и POST (в synchronized блоке)? 

еще раз: лобовой путь - все работу с сокетом запихнуть в спецальный статичный класс (ну или сингтон). ну и методы этого класса собственно работающее с сокетом засинхронизировать.

и в самом сервлетет просто этими методами пользоваться.

Lamer George, про SingleThreadServlet просто не знаю. не сталкивался  - пойду читать. 

Пардон, похоже, я облажался.

http://www.unix.org.ua/orelly/java-ent/servlet/ch03_04.htm



Судя по этой картинке, всё как раз наоборот   

Это сообщение отредактировал(а) Lamer George - 18.5.2006, 14:26

очень правильная картинка.  
но в реально жизни все может быть еще хуже. (зависит от того как сделан апп сервер)

можно просто сказать апп серверу чтобы Servlet Pool содержал только один ServletInstance. Но тогда ноятно теряеться весь паралеллизм. если предположить что сервлет делает очень СPU зависимую работу и процессор только один, то это не страшно (даже наоборот в таком случае это будет очень правильное решение, для того и лазейка оставлена)
но в реальной то жизни сервлы делают не очень-то СPU Зависимую работу там в основном память и работа с источниками данных. да и современный сервер даже простой это много процесорно-много ядерное что-то... так что такие игры с конфигурацией они не рекомендуються настоятельно.  

Это сообщение отредактировал(а) ALKS - 18.5.2006, 14:40

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

По поводу разных инстансов - по этому поводу имеются вопросы:

Будет ли для разных инстансов вызываться свой инит или он вызовется сто пудово один раз для всех инстансов?

У разных инстансов одного и того же сервлета один ServletContext или нет?

Если я в одном инстансе в ServletContext сохраню сокет, а в другом инстансе достану - будет ли он валиден? Или лучше (для быстродействия) статиком его сделать? 

сервлет контекст. т.е. контекст конкретного сервлета. т.е. он будет разный у каждого сервлета.... наверное.... не уверен  

а вот при создание нового инстанса сервлета и помещении его в Servlet Pool будет однократно вызван инит. ну т.е. инит это как конструктор. вот в этом я уверен  

Добавлено:

вот из описания к Interface ServletContext:
There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.)

 

Это сообщение отредактировал(а) ALKS - 18.5.2006, 15:41

Рискну выразить мнение, что инстанс сервлета - всегда один. 
SingleThreadModel - давно и окончательно признано неприемлемым.
Привязывать сокет к сервлету на мой взгляд просто неудобно. Сокет может закрыться, значит нужен монитор, который восстановит соединение. Доступ к сокету очевидно должен быть синхронизированным, возможно очередь нужна. 
 

это кем когда и почему оно непреемлемо? и JRun4 100% так работает.

и зачем тогда <load-on-startup> элемент в элементе <servlet> в web.xml? если он всегда один? 

Применение SingleThreadModel  - устаревшая концепция (именно имплементация этого интерфейса и является сигналом контейнеру создавать пул инстансов). Потому что два инстанса сервлета ничем не лучше, чем один.

Сервлет не должен хранить в себе состояние пользователя. Оно хранится в сессии, которая создается для каждого пользователя. Методы сервлета  (doGet..) должны содержать только локальные переменные, тогда сервлет будет потокобезопасным. И в этом случае обрабатывать одновременно несколько потоков пользователей без разницы, одним инстансом или несколькими. При таком подходе нет причин иметь больше одного инстанса.  

Это я своими словами, а линк не могу пока найти.  
  

Это сообщение отредактировал(а) COVD - 18.5.2006, 16:50

Сокет мне для работы необходим, так как нужен обмен данными с другим приложением (кому интересно, то обсуждение было в "Асинхронный ответ" http://forum.vingrad.ru/index.php?showtopic=94893 )

Судя из сказанного, сокет необходимо будет делать сингтоном или статиком.

А как в сервелтах работают с БД? Я просто в java с ними не работал, но ведь наверняка там тоже есть соединение с БД.... Как их шарят между инстансами в GET, POST? Или народ не беспокоит количество одновременно открытых соединений с БД?

По поводу только локальных переменных. А как же быть например с HttpSession?
ведь что произойдет без синхронизации в примере:
от клиента практически одновременно пошли два запроса GET с парам. 1 и 2 к сервлету А и на сервере
обработались двумя инстансам сервлета А:
метод GET 

Я думаю без синхронизации такой код не валиден...... 

Два запроса - это два разных потока. 

Все  в этом коде будет выполняться независимо, в разных разделах памяти. Это справедливо, если в используете в вычислениях только входные параметры (httpServletRequest) и локальные переменные (session  должна быть описана как локальная, т.е. Session session = ..., но она и по сути локальная, нет нужды ее описывать как глобальную)

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

Это сообщение отредактировал(а) COVD - 18.5.2006, 18:01

что такое пул соединений?  

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

Это сообщение отредактировал(а) COVD - 18.5.2006, 18:27

вы меня с SingleThreadModel о котором я и не слышал ни чего до этого топа запутали совсем 

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

апп сервер следит за количество потоков-реквестов и если их количество начинает сильно расти это значит что ваш единственый инстанс-сервлет "захлебываеться". вот в этом случае он и может создать еще один сервлетик в надежде что это поможет распределить загрузку. в большенстве случаев - поможет 

Но все это конечно теории и нюансы имплементации конкретного апп сервера, но вы как разработчик должны предполагать что ваше вэб приложение вполне может работать на апп сервере который плодит сервлеты 

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

Неверная логика. Метод - он всегда один (не зависит от количества инстансев), потому что это описание, что надо сделать, набор инструкций. Метод doGet будет одновременно исполняться разными потоками, и у каждого потока будет свой участок памяти, где создаются локальные переменные метода.

Инстансы же нужны, чтобы хранить состояние, данные. Если вы в сервлете их не храните, то увеличение количества обьектов сервлета не имеет смысла, это только отожрет память, и ничего более.  

Думаю, что создатели серверов это учитывали, и обьекты сервлетов будут плодиться только, если сервер об этом явно попросить, например, имплементируя SingleThreadModel. Т.е. если вы намерены хранить данные именно в сервлете (а не в сессии) и поэтому хотите иметь на каждый поток свой обьект сервлета.
     

Это сообщение отредактировал(а) COVD - 18.5.2006, 21:03

Может в этом и есть корень проблемы
Есть же более готовые к употреблению технологии взаимодействия, чем сокеты: RMI, Corba, WS наконец. 

jimur, быстрее сокетов ничего нету.  

теоретически как разрешить проблему мне понятно, спасибо всем огромное, особенно ALKS'у....

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

буду копать в направление Web Service..... 

Не ерничай 
Выбор технологии определяется параметрами задачи и исполнителей.


А что за модуль (на чем написан)?
И какое взаимодействие (удаленное/нет)? 

COVD, а блокировки где, как ты думаеш, храняться? в методе или все-таки в инстансе объекта?  метод-то он всегда один - тут ты прав. но синхронизируеться он относительно инстанса, так что если мы имеем дело с многопоточным приложением, то... ну я уверен, ты понял что я хотел сказать   

jimur, суть задачи подробно разбирали в теме "Асинхронный ответ"
(http://forum.vingrad.ru/index.php?showtopic=94893) 

Если я правильно понял второй модуль запускаетсся как отдельный процесс, возможно на другой машине, в нем должне жить реализованный тобой адаптер.
Тогда решение примерно следующее:
Реализуешь адаптер (RMI Server), который регистрируется в rmiregistry. Твой сервлет использует RMI Client для отправки заданий на сервер и для получения результатов. Вроде ничего сложного. 

ок, спасибо jimur. это еще один из вариантов решения проблемы.... 
а случаем ссылок на статьи или книги по технологии RMI нету? 
можно ли RMI Server реализовать на java (не java-script а именно джава)? 

ссылка на туториал http://www.google.ru/search?q=rmi+tutorial
этого достаточно для реализации простого приложения
на jguru.com есть хороший раздел на эту тему
спецификацию тоже хорошо бы прочитать 



ммм...
java-script то здесь вообще каким боком? 

Эээ RMI (Remote method invocation ) это только Java. за пределами Java эта абревиатура не существует. в общем случае, вне языков программированя, такая техника называеться RPC (remote procedure call). RMI это по сути реализация RPC в Java.  

jimur, не зная теории можно и не такие вопросы задать

по поводу доков - неплохая инфа тут - 
RMI tutorial

Добавлено @ 12:15 
jimur, а в чем будет преимущество в использование RMI а не сокетов в моем случае? 

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

runtime - никаких, rmi будет немного медленнее, если на сокетах все нормально сделать
development - быстрее, т.к. не нужно решать кучу проблем, решенных разработчиками  RMI 

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

COVD,  Если методы сервлета синхронизирован(что на самом деле абсолютно ужастный код) это слишком простой пример. может быть что сами методы не синхронизированы, но есть синхронизированный блок кода внутри сервлета, но это тоже простой пример. а если зрить глубже, то ваш сервлет вызывает какой-то метод какого-то класса который синхронизирован и об этом не знает и не может знать не только апп сервер, но даже разработчки сервлета....

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

Заглянем в спецификацию:


Таким образом, согласно спецификации:
1. Есть один инстанс сервлета и все запросы идут через него параллельно. Следить за согласованностью доступа к разделяемым объектам - задача разработчика. Спецификация жестко  запрещает контейнеру создавать пул экземпляров сервлета (что вполне логично).
2. Если сервлет реализует интерфейс SingleThreadModel, то этим разработчик заявляет, что каждый экземпляр должен обрабатывать не более одного запроса одновременно. Как этого достичь - оставляется на усмотрение контейнера: либо выстраивать запросы в очередь, либо использовать пул экземпляров (что в данном случае разрешено).
3. Если методы service, doPost или doGet сервлета объявлены как синхронизованные, то контейнер обязан выстраивать все запросы в очередь и не может создавать пул экземпляров. 

Lerm, а ссылку?  

Пофантазирую. Lerm пишет о спецификации для контейнера, а ALKS все больше о апп сервере. Разные вещи?  

Это сообщение отредактировал(а) COVD - 22.5.2006, 21:06

На Servlet 2.3 Specification? ;)
http://javashoplm.sun.com/ECom/docs/Welcom...sactionId=noreg
А разделы я указал в цитате.



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

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