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

Форум программистов > Java EE (J2EE) и Spring > Сокет в сервлете....

Автор: vasko 18.5.2006, 10:54

Для успешной работы сервлету необходим сокет(клиент) - один для всех сессии. В связи этим вопрос -  на какие подводные камни можно натолкнуться при реализации сокета в сервлете в связи с многопоточностью? Где лучше создавать, удалять, хранить? Предпологается создавать сокет в методе init() сервлета, а грохать в destroy() Хранить socket и данные, прочитаные из сокета, которые необходимо вернуть в браузер предпологаю в ServletContext Код ServletConfig config; Map  respMap; public void init(ServletConfig config) throws ServletException {         ....         // Можно ли хранить сокет в ServletContext. Или можно его просто сделать         // глобальным?         config.getServletContext().setAttribute("socket", new MySocket(this));         config.getServletContext().setAttribute("respMap", new HashMap()); } protected void doGet(HttpServletRequest req, HttpServletResponse res) {        if (!req.getAttribute("needAnswere")) {           // Не может ли здесь быть проблем с многопоточностью???           MySocket sock = (MySocket)config.getServletContext().getAttribute("socket");           synchronized (sock.getClass()) {              sock.writeReq(req); // метод асинхронный           }                   }       else {          HashMap respMap = (HashMap)getAttribute("respMap");           synchronized (respMap.getClass()) {                if ( respMap.containsKey(req.getParameter("key")) {                    // Подготавливаем ответ для клиента                }                else {            // Подготавливаем ответ что данные не готовы                }           }      } } public void readFromSocket(Object data) {       synchronized (respMap.getClass()) {           respMap.put((Response)data.getKey(), data);          } } public void run() {    MySocket sock = (MySocket)config.getServletContext().getAttribute("socket");    .....    while (!stop) {         // Read data from socket         readFromSocket(data);     } }

Автор: Tony 18.5.2006, 12:45

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

Автор: ALKS 18.5.2006, 13:25

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

Автор: batigoal 18.5.2006, 13:28

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

Автор: vasko 18.5.2006, 13:34

Сервлету необходимо взаимодействовать с другим модулем. Для связи между ними выбрал сокеты. В сервлете клиентский сокет, в модуле серверный сокет.  В сервлете, в методе GET и POST если параметр "needAnswere != 0" необходимо отправить данные по сокету, иначе если для данного HttpServletRequest мы уже получили данные по сокету, мы запихиваем данные в HttpServletResponse. Вопрос собственно в том, не будет ли накладок при работе с сокетом.  Безопасно ли сохранять сокет в ServletContext?  Я это делаю что бы обезопасить себя от разных инстансов сервлета + MultiThread Или можно в классе сервлета объявить сокет, в инит его инициализировать и безопасно пользоваться в GET и POST (в synchronized блоке)?

Автор: ALKS 18.5.2006, 14:12

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

Автор: batigoal 18.5.2006, 14:26

Цитата(Lamer George @  18.5.2006,  14:28 ) Вроде ведь есть путь указать сделать конкретный сервлет однопоточным (кажется, унаследовав его от SingleThreadServlet).   Пардон, похоже, я облажался. http://www.unix.org.ua/orelly/java-ent/servlet/ch03_04.htm Судя по этой картинке, всё как раз наоборот

Автор: ALKS 18.5.2006, 14:33

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

Автор: vasko 18.5.2006, 15:05

ALKS, сокет у меня асинхронный, поэтому при записи и чтение больших тормозов не будет.... По поводу разных инстансов - по этому поводу имеются вопросы: Будет ли для разных инстансов вызываться свой инит или он вызовется сто пудово один раз для всех инстансов? У разных инстансов одного и того же сервлета один ServletContext или нет? Если я в одном инстансе в ServletContext сохраню сокет, а в другом инстансе достану - будет ли он валиден? Или лучше (для быстродействия) статиком его сделать?

Автор: ALKS 18.5.2006, 15:28

сервлет контекст. т.е. контекст конкретного сервлета. т.е. он будет разный у каждого сервлета.... наверное.... не уверен   а вот при создание нового инстанса сервлета и помещении его в 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.)

Автор: COVD 18.5.2006, 16:04

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

Автор: ALKS 18.5.2006, 16:10

это кем когда и почему оно непреемлемо? и JRun4 100% так работает. и зачем тогда <load-on-startup> элемент в элементе <servlet> в web.xml? если он всегда один?

Автор: COVD 18.5.2006, 16:32

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

Автор: vasko 18.5.2006, 17:35

Сокет мне для работы необходим, так как нужен обмен данными с другим приложением (кому интересно, то обсуждение было в "Асинхронный ответ" http://forum.vingrad.ru/index.php?showtopic=94893 ) Судя из сказанного, сокет необходимо будет делать сингтоном или статиком. А как в сервелтах работают с БД? Я просто в java с ними не работал, но ведь наверняка там тоже есть соединение с БД.... Как их шарят между инстансами в GET, POST? Или народ не беспокоит количество одновременно открытых соединений с БД? По поводу только локальных переменных. А как же быть например с HttpSession? ведь что произойдет без синхронизации в примере: от клиента практически одновременно пошли два запроса GET с парам. 1 и 2 к сервлету А и на сервере обработались двумя инстансам сервлета А: метод GET  Код      session = httpServletRequest.getSession();      if (httpServletRequest.getParameter("Param").equals("1"))          session.setAttribute("Attr", "1");      else if (httpServletRequest.getParameter("Param").equals("2"))          session.setAttribute("Attr", "2"); Я думаю без синхронизации такой код не валиден......

Автор: COVD 18.5.2006, 17:56

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

Автор: vasko 18.5.2006, 18:03

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

Автор: COVD 18.5.2006, 18:24

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

Автор: ALKS 18.5.2006, 20:18

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

Автор: COVD 18.5.2006, 20:25

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

Автор: jimur 18.5.2006, 21:12

Цитата(vasko @  18.5.2006,  13:34 ) Сервлету необходимо взаимодействовать с другим модулем. Для связи между ними выбрал сокеты. Может в этом и есть корень проблемы Есть же более готовые к употреблению технологии взаимодействия, чем сокеты: RMI, Corba, WS наконец.

Автор: ALKS 19.5.2006, 08:14

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

Автор: vasko 19.5.2006, 09:13

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

Автор: jimur 19.5.2006, 09:52

Цитата(ALKS @  19.5.2006,  08:14 ) jimur, быстрее сокетов ничего нету. smile   Не ерничай  Выбор технологии определяется параметрами задачи и исполнителей. Цитата(vasko @  19.5.2006,  09:13 ) буду копать в направление Web Service.....   А что за модуль (на чем написан)? И какое взаимодействие (удаленное/нет)?

Автор: ALKS 19.5.2006, 10:40

Цитата(COVD @ 18.5.2006,  20:25) Цитата апп сервер следит за количество потоков-реквестов и если их количество начинает сильно расти это значит что ваш единственый инстанс-сервлет "захлебываеться". вот в этом случае он и может создать еще один сервлетик в надежде что это поможет распределить загрузку. в большенстве случаев - поможет  Неверная логика. Метод - он всегда один (не зависит от количества инстансев), потому что это описание, что надо сделать, набор инструкций. Метод doGet будет одновременно исполняться разными потоками, и у каждого потока будет свой участок памяти, где создаются локальные переменные метода. Инстансы же нужны, чтобы хранить состояние, данные. Если вы в сервлете их не храните, то увеличение количества обьектов сервлета не имеет смысла, это только отожрет память, и ничего более.   Думаю, что создатели серверов это учитывали, и обьекты сервлетов будут плодиться только, если сервер об этом явно попросить, например, имплементируя SingleThreadModel. Т.е. если вы намерены хранить данные именно в сервлете (а не в сессии) и поэтому хотите иметь на каждый поток свой обьект сервлета. COVD, а блокировки где, как ты думаеш, храняться? в методе или все-таки в инстансе объекта?  метод-то он всегда один - тут ты прав. но синхронизируеться он относительно инстанса, так что если мы имеем дело с многопоточным приложением, то... ну я уверен, ты понял что я хотел сказать

Автор: vasko 19.5.2006, 11:05

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

Автор: jimur 19.5.2006, 11:20

Цитата(vasko @  19.5.2006,  11:05 ) jimur, суть задачи подробно разбирали в теме "Асинхронный ответ" (http://forum.vingrad.ru/index.php?showtopic=94893)   Если я правильно понял второй модуль запускаетсся как отдельный процесс, возможно на другой машине, в нем должне жить реализованный тобой адаптер. Тогда решение примерно следующее: Реализуешь адаптер (RMI Server), который регистрируется в rmiregistry. Твой сервлет использует RMI Client для отправки заданий на сервер и для получения результатов. Вроде ничего сложного.

Автор: vasko 19.5.2006, 11:54

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

Автор: jimur 19.5.2006, 12:07

ссылка на туториал http://www.google.ru/search?q=rmi+tutorial этого достаточно для реализации простого приложения на jguru.com есть хороший раздел на эту тему спецификацию тоже хорошо бы прочитать  Цитата(vasko @  19.5.2006,  11:54 ) можно ли RMI Server реализовать на java (не java-script а именно джава)? ммм... java-script то здесь вообще каким боком?

Автор: ALKS 19.5.2006, 12:09

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

Автор: vasko 19.5.2006, 12:12

Цитата(jimur @  19.5.2006,  12:07 ) java-script то здесь вообще каким боком? jimur, не зная теории можно и не такие вопросы задать по поводу доков - неплохая инфа тут -  http://java.sun.com/docs/books/tutorial/rmi/index.html Добавлено @ 12:15  jimur, а в чем будет преимущество в использование RMI а не сокетов в моем случае?

Автор: ALKS 19.5.2006, 12:53

Цитата(vasko @ 19.5.2006,  12:12) Добавлено @ 12:15  jimur, а в чем будет преимущество в использование RMI а не сокетов в моем случае? если вы спросите меня - ни в чём. только медленнее будет, но не сильно

Автор: jimur 19.5.2006, 13:13

Цитата(ALKS @  19.5.2006,  12:53 ) Цитата(vasko @ 19.5.2006,  12:12) Добавлено @ 12:15  jimur, а в чем будет преимущество в использование RMI а не сокетов в моем случае? если вы спросите меня - ни в чём. только медленнее будет, но не сильно smile runtime - никаких, rmi будет немного медленнее, если на сокетах все нормально сделать development - быстрее, т.к. не нужно решать кучу проблем, решенных разработчиками  RMI

Автор: COVD 19.5.2006, 14:40

Цитата(COVD @ 18.5.2006,  20:25) Цитата апп сервер следит за количество потоков-реквестов и если их количество начинает сильно расти это значит что ваш единственый инстанс-сервлет "захлебываеться". вот в этом случае он и может создать еще один сервлетик в надежде что это поможет распределить загрузку. в большенстве случаев - поможет  Неверная логика. ..... ALKS, тут я погорячился. Если методы сервлета синхронизированы, то потоки будут выстраиваться в очередь к обьекту сервлета и добавление нового обьекта сервлета оправдано. Согласен, что такая фича должна быть предусмотрена в контейнере сервлетов.

Автор: ALKS 19.5.2006, 15:08

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

Автор: Lerm 22.5.2006, 19:28

Заглянем в спецификацию: Цитата SRV.2.2 Number of Instances The servlet declaration which is part of the deployment descriptor of the web application containing the servlet, as described in Chapter SRV.13, “Deployment Descriptor”, controls how the servlet container provides instances of the servlet. For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance. ... SRV.2.3.3.1 Multithreading Issues A servlet container may send concurrent requests through the service method of the servlet. To handle the requests the developer of the servlet must make adequate provisions for concurrent processing with multiple threads in the service method. An alternative for the developer is to implement the SingleThreadModel interface which requires the container to guarantee that there is only one request thread at a time in the service method. A servlet container may satisfy this requirement by serializing requests on a servlet, or by maintaining a pool of servlet instances. If the servlet is part of a web application that has been marked as distributable, the container may maintain a pool of servlet instances in each VM that the application is distributed across. For servlets not implementing the SingleThreadModel interface, if the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container cannot use the instance pool approach, but must serialize requests through it. It is strongly recommended that developers not synchronize the service method (or methods dispatched to it) in these circumstances because of detrimental effects on performance. Таким образом, согласно спецификации: 1. Есть один инстанс сервлета и все запросы идут через него параллельно. Следить за согласованностью доступа к разделяемым объектам - задача разработчика. Спецификация жестко  запрещает контейнеру создавать пул экземпляров сервлета (что вполне логично). 2. Если сервлет реализует интерфейс SingleThreadModel, то этим разработчик заявляет, что каждый экземпляр должен обрабатывать не более одного запроса одновременно. Как этого достичь - оставляется на усмотрение контейнера: либо выстраивать запросы в очередь, либо использовать пул экземпляров (что в данном случае разрешено). 3. Если методы service, doPost или doGet сервлета объявлены как синхронизованные, то контейнер обязан выстраивать все запросы в очередь и не может создавать пул экземпляров.

Автор: ALKS 22.5.2006, 20:04

Lerm, а ссылку?

Автор: COVD 22.5.2006, 20:55

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

Автор: Lerm 23.5.2006, 13:07

Цитата Lerm, а ссылку? На Servlet 2.3 Specification? ;) http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7840-servlet-2.3-spec-oth-JSpec&SiteId=JCP&TransactionId=noreg А разделы я указал в цитате. Цитата Пофантазирую. Lerm пишет о спецификации для контейнера, а ALKS все больше о апп сервере. Разные вещи? Не вижу разницы. Мы же говорим конкретно о сервлетах, а не о других типах серверных приложений - просто контейнер сервлетов является частью сервера приложений.  Другое дело, что разработчик контейнера может встроить в него некотороые нестандартные вещи, которые могут нарушать спецификацию - но они должны быть отключены по умолчанию (или контейнер не соответствует стандарту).

Автор: mayatnikov 9.9.2006, 20:09

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

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