Аналог Java

Ну, ладно. Тогда сравним яву с питоном. Это ближе к моему случаю. Выше был небольшой троллинг :)

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

> И писать такие штуки приятно и интересно

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

А какое тебе обслуживание нужно?

Я сторонник того, что в программировать нужно как завещал Жванецкий: «писАть нужно как и пИсать, когда уже терпеть не можешь». Да, есть жестокий реальный мир, с неадекватными манагерами, которые не понимают что сделать что-то по-быстрее можно только в ущерб качеству и он как надзиратель вообще не упал, но это уже совсем другая история, не имеющая отношения к истинным ценностям. Потому-то я и пишу на Java :)

Да много чего нужно, но здесь главное другое - у облаков относительно дешевая цена. Лично мне как техническому специалисту они совсем не нравятся :)

>у облаков относительно дешевая цена

а разве какой-нибудь дедик в хетцнере не дешевле облаков?

> Я уже их тут сотни раз выкладывал и в инете куча инфы.

О, расскажи мне.

а сколько он стоит? без виртуалки, полноценный. но честно говоря, я в этом вопросе не большой специалист :)

>а сколько он стоит? без виртуалки, полноценный.

155 зеленых в месяц с ндс. Это i7-980X (8 ядер) и 24 GB оперативки. Мне кажется облако с теми же показателями выйдет куда дороже.

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

да, звучит логично.

Ocaml же. Хотите - байт-код, хотите - native. Скорость ого-го, наравне с Си.

Пиковая нагрузка - аргумент. Насколько понимаю, у того же Google App Engine (GAE) хорошая масштабируемость, но писать для него сложно. Хотя с другой стороны, если правильно проектировать под «обычный» J2EE (в GAE используются сервлеты), то там тоже можем заиметь масштабируемость, кластеризуемость и все такое, избегая EJB и прочих «тяжелых» вещей.

А можно ссылку на тот хостинг?

>> Я уже их тут сотни раз выкладывал и в инете куча инфы.

О, расскажи мне.

Слился иксперт?

На скептиков лень тратить время. Действительно, если тебе надо, поищи на ЛОРе. Мне ты не нужен как явление.

Я там рядом создал тред о использовании памяти при использовании EJB. Но это не клиенте, который тоже должен быть в контейнере. Не думаю что современный EJB 3 настолько тяжелый на сервер-сайде. Хотя слова - пустота, надо тестировать

> На скептиков лень тратить время. Действительно, если тебе надо, поищи на ЛОРе. Мне ты не нужен как явление.

Прикольные аргументы. Слив засчитан.

Думаю твою настойчивость можно записать тебе в достоинства. Хоть и ЧСВ высокое, так как ты думаешь что хоть кому-то нужен. Но ладно, так и быть, потрачу 2 минуты сделав то, что должен был делать ты сам

http://www.linux.org.ru/jump-message.jsp?msgid=6291231&cid=6291949

http://www.linux.org.ru/jump-message.jsp?msgid=6318465&cid=6319958

Протестировал только что. Простой хеллоу-ворлд. Метод который получает строку, и возвращает строку. EJB 3.1, Glassfish, WiFi)))).

100000 вызовов - 208000 мс. Не сказал бы что супер, но абсолютно приемлемо. Память на серверсайде не выше 200 МБ. Ведь EJB еще делает очень много полезного. То же самое, но только в 100 потоков (100*1000 вызовов) - 42000 мс. И у меня узкое место на сети, так как она загружена полностью, а процессор на обоих машинах - до 50%

Я просто сравниваю с моей дипломной работой где используются сокеты, Reactor Pattern на Java NIO и Google Protobuf, а сообщения получаются меньше 50 байт. Там числа совсем другие ) Ведь нет ничего сверх простой сериализации и отправки по сети. Тут же есть приличное количество технологий связанный с безопасностью и транзакциями. Уже не говоря о том, что согласно некоторым бенчмаркам Google Protobuf быстрее сериализации Java в 1000 раз.

Что теперь делать и кто виноват? Как насчет JMS? Тоже все глухо?

JMS не тестил. А разве глухо? Я помоему продемонстрировал нормальную производительность

Ну, может быть, и не глухо :)

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

Меня сейчас особенно JMS интересует. Сервлеты - понятно. Проверены временем. Используются даже в Google App Engine. Вот, что в JavaEE с асинхронной обработкой сообщений?

Не хочется изобретать велосипед, хотя лично я обожаю это дело ;)

Ну а что именно вас в JMS интересует. Это по большому счету очередь, которая поддерживает транзакции, гарантирует доставку и персистентность сообщений, в ней не надо переживать о надежности, переполнениях. Тоесть технология которая берет все на себя в плане как хранить, передавать сообщения и бороться с восстановлением после сбоев. В очередь можно пихать сколько угодно сообщений и они будут оттуда исчезать по мере того как из будут успевать обрабатывать, что часто хорошо распределяет нагрузку на протяжении суток.

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

>А можно ссылку на тот хостинг?

я думал про него уже все знают ;)
http://www.hetzner.de/en/hosting/produkte_rootserver/eq10

Гарантированная доставка сообщений в JMS и интересует в случае внезапного скачка нагрузки.

В том же GAE все куда проще. Наплодил задач для очереди, а система взяла и поотрубила часть. Только что с этим делать?

Спасибо, закоммитил.