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

Пробуй проверить сколько коннектов может создать.
На клиенте в js создаю массив и туда в цикле пихаю new WebSocket.
То есть открываешь страницу и она в js генерит коннекты к приложению.

1. коннекты создаются довольно медленно
2. затыкается стабильно на 191-ом коннекте и дальше будто ничего не происходит.
На сервере в javax.websocket.OnOpen после 191 подключения ничего не приходит, на клиенте в try catch ничего не падает.

Вопросы
1. куда копать, почему 190 и все?
2. как правильно проверить максимальное число подключений?
3. если число подключений ограничено, какая стратегия работы с websocket?
4. как защититься от генерации большого числа коннектов на открытом для общего доступа сайте?

Изначально вопрос возник отсюда.
Можно все делать на том же ajax и опрашивать сервер например 1 раз в сек, данные для ответа брать из кэша приложения (чтобы не лазить по каждому запросу в БД), но не уверен, что это нормальный подход и не знаю какую нагрузку можно держать при таком варианте.
Поэтому интересно посмотреть в сторону вебсокетов, чтобы не опрашивать сервер кучей сессий каждую секунду, а отправлять клиентам инфу по мере ее готовности на сервере.

Да. Ограничение похоже, что в браузерах. В фоксе не дает больше 190, в хроме - 260.
Ну допустим.
Вопрос гор. и вертик. масштабируемости все равно актуален.
65К подключений это немало, но и немного.
Информация обрывочная, целостной картины не собрать. Кто-то пишет про мультиплексоры, которые распределяют коннекты по разным портам что ли. Кто-то про балансировщики. Кто-то прикручивает до кучи брокеры. Но в итоге якобы догоняют количество коннектов до 1млн на одной машине.
А так да пока винда и гласфиш.

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

Возможно, я неправильно объяснил суть.
Буфер нужен для того, чтобы не лазить каждый раз в БД.
То есть безотностительно с WS работа или по HTTP.
То есть оперативная информация на клиент уходит только из буфера.
И обновление этой информации идет централизованно приложением и может идти в один поток в том числе, то есть не зависит от пользователей.
То есть:
1. идет некий процесс в приложении
2. данные из п.1 фиксируются в БД
3. по этим данным обновляется буфер
4. при обновлении буфера идет рассылка клиентам.
5. если подключается новый клиент, он не идет в БД, а забирает данные из буфера приложения

В целом от этого пока можно абстрагироваться, так как не касается сути вопроса по большому счету.

Что касается работы с WS-ми, да, точка входа одна:

Но как понимаю, здесь это для разработчика использующего javax.websocket она одна, но на входе есть Session - который и отражает собственно коннект по WS, и каждый клиент - это как минимум, один коннект.
Или я не прав? )