Надежность JAVA-приложения

← →
@!!ex © (2008-03-22 17:05) [0]

Конторе есть необходимость разработать ряд крос-платформенных серверов для расчетов.
Выбор стоит между С/C++(крос-платформенность на уровне исходного кода) и JAVA. Сразу оговорюсь, именно между ними,
другие языки не рассматриваются в силу целого ряда причин (не буду их приводить, к вопросу это не относится).
Сервера должны работать в режиме 24/7. Возникает вопрос, насколько надежно работает JAVA(точнее JVM).
Есть ли опыт такой работы (положительны/отрицательный).
Важно: я точно сказать не могу, не я решаю, но по опыту могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч $. Цена простоя сервера измеряеться в миллионах $ в сутки. Т.е. надежность приложения на уровне, "у меня повисла прога, я ее перегрузил и все" это равноценно полному отсутствию надежности. На С/С++ решения есть (базы данных, apache и т.д.). На JAVA я подобных решений не видел.
Задавал вопрос на Delphikingdom, все свелось к JAVA рулит, но лучше FPC, мои аргументы не услышали.
Задавал вопрос на sql.ru, все свелось к JAVA рулит, а я ничего не понимаю в программировании, конкретных примеров на JAVA не привели.
Возможно Вы поставите точку в выборе? :)

← →
Reindeer Moss Eater © (2008-03-22 17:15) [1]

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

Первый вариант.

← →
Поп Гапон (2008-03-22 17:16) [2]

>
> @!!ex © (22.03.08 17:05)

Java нужно уметь готвить, так как если не следовать рекомендациям(фичам) то тормоза будут жуткие.

Из недостатков
1. Нет определенного на уровне языка виртуального деструктора как в Delphi.
2. Мусорщик запускается только когда нехватка памяти(но можно вызвать самому). Так что может случится на машинах с 4-16 Гб памяти что закончатся GDI ресурсы или объекты ядра быстрее чем память.
3. если Java сервер под винду, то нельзя регулировать размер стека(он всегда мах 1 Мб), под *nix, Linux можно.
4. Все есть объект, так что работа со строками медленная, но есть стрингбилдеры, которые решают эту проблему.
5. Хоть сетевые сервисы работают довольно шустро, Гуи... вроде в Java6 наконец-то тормоза убрали. Но это более к преимуществам для вас, так как у вас сервера.

Преимущества:
1. Большая библиотека чего угодно, как на делфи компонент, но больше и кросплатформенно.
2. минимальные танцы с бубном при переносе на другую платформу аналогичную по мощности системы(совсем без них не выйдет).
3. Совмещение работы с программой как со скриптом(рефлекшены, обращение к методам и полям по имени и пр) так и компилируемым языком.
4. jit компиляция, тоесть оптимизация кода в онлайне на запускаемый процессор самим компилятором java байт-кода в нативный (часто подглючивает и генерирует тормозной код).

Вроде все.

← →
ferr (2008-03-22 17:19) [3]

java рулит так как jvm стабильна это одын, два это что код на жаве будет содержать меньшее количество ошибок, в силу специфики, так что она в общем-то рулИт. за fpc отрывать конечности, дрянь редкостная..

← →
DrPass © (2008-03-22 17:22) [4]

> Т.е. надежность приложения на уровне, "у меня повисла прога,
> я ее перегрузил и все" это равноценно полному отсутствию
> надежности. На С/С++ решения есть (базы данных, apache и
> т.д.). На JAVA я подобных решений не видел.

Java, в отличие от остальных платформ, даст тебе огромное преимущество - сервер приложений. Который будет рулить транзакциями, пулами соединений с СУБД, кешированием программных модулей, обеспечит кластеризацию и как следствие - отказоустойчивость и балансировку нагрузки между несколькими узлами.
Все это УЖЕ есть в J2EE. Бери (купи) и используй. Для С++ таких решений (по крайней мере, "массовых")ты не найдешь.
Другое дело, что проект действительно должен стоить этой сложной и мощной платформы.

← →
Игорь Шевченко © (2008-03-22 17:37) [5]

Я бы не стал выбирать Java для 24/7. Тому есть примеры - Оракловский сервер приложений, который достаточно надежный, но...

← →
@!!ex © (2008-03-22 18:01) [6]

2Reindeer Moss Eater:
Крос-платформенность нужна, т.к. у разных заказчиков разные платформы (Sun, HP, Win, Linux, IBM). Нужно снизить цену портирования и ошибки портирования.
2Поп Гапон:
1) проблема памяти это важно. Спасибо.
2) библиотке не нужна (чисто работа с БД+расчеты(в паралельных потоках)+прокача данных по сети (свой протокол на базе TCP ничего сверхестественного))
2ferr:
Если что-то случиться с JVM у заказчика, что мы будем делать? Sun не осуществляет поддержку JVM в режиме 24/7.
А то что они планируют(когда еще будет), будет стоить огромных денег.
2DrPass:
Нам не нужен сервер приложений (внутрений сервер расчетов, никто с ним работать не будет). Кластеризация нам не подходит по раду причин (например скорость: сервер ежесекундно должен через себя прокачивать около 3000 записей в один поток(2 потока 6000 и т.д.), у кластера сразу возникнет проблема синхронизации общих данных).
2Игорь: а конкретнее? Есть опыт? Можешь поделиться (без деталей)?

← →
Игорь Шевченко © (2008-03-22 18:15) [7]

А что конкретней, набираешь в гугле oracle application server bugs

← →
Simpson (2008-03-22 18:17) [8]

Поп Гапон (22.03.08 17:16) [2]
err (22.03.08 17:19) [3]
Игорь Шевченко © (22.03.08 17:37) [5]
Это у них Ахилессова пята такая, дело в том что Java сколько бы не говорили не занимается сбором мусора, этим должен озаботиться программист, то есть программер ДОЛЖЕН ЯВНО УКАЗЫВАТЬ, что надо удалить, сама Java фиг что удалит если есть ссылки на интерфейс. В запутанных(сложных) интерфейсах ссылки есть всегда, результат System.gc() их не удалит из пямяти.

но не будем голословными, поcмоторим что даст http://www.yourkit.com/ про работу вашего приклада?/*не реклама сам пользуюсь*/
Дык вот оно как оказывается, надо следить за обеъктами и удалять их, иначе срач в памяти и захлебываемся через Х часов.
Это про память, про мультипратформенность, все функции работы с OS(открытие файла например) реализованны через native функции, не секрет что работа в разных OS по разному происходит работа с файлом так что отличая есть и с этим придется бороться...

← →
Petr V. Abramov © (2008-03-22 18:18) [9]

> Игорь Шевченко © (22.03.08 18:15) [7]

тут специфика, этим людям нельзя доверять писать ничего, кроме dbms :).

← →
Игорь Шевченко © (2008-03-22 18:19) [10]

Petr V. Abramov © (22.03.08 18:18) [9]

Инсталлятор ихний на Java написанный вполне себе работает. Да и прочие тулзы. Но не в режиме 24/7.

← →
ferr (2008-03-22 18:22) [11]

> Это у них Ахилессова пята такая, дело в том что Java сколько
> бы не говорили не занимается сбором мусора, этим должен
> озаботиться программист, то есть программер ДОЛЖЕН ЯВНО
> УКАЗЫВАТЬ, что надо удалить, сама Java фиг что удалит если
> есть ссылки на интерфейс. В запутанных(сложных) интерфейсах
> ссылки есть всегда, результат System.gc() их не удалит из
> пямяти.

Вот Вы искренне считаете что умнее сановцев да? Ну я рад за Вас. Там всё открыто, правьте.

← →
Petr V. Abramov © (2008-03-22 18:25) [12]

> Игорь Шевченко © (22.03.08 18:19) [10]

иногда. чего стОит история с неработой 8-шного на P-IV без спецтанцев.
утилиты типа netca и dbca - да, за 10 лет отладили утилитки из 10 экранов, но по мне они не образец удобства.

← →
Simpson (2008-03-22 18:29) [13]

ferr (22.03.08 18:22) [11]
Дык нет не умнее, просто меня многое не устраивает, я не понимаю что делает в SDK переменная Virginity == девственность, почему никогда не удаляются из памяти сложные обьекты(перекрестные ссылки),почему в Swing реализация обработки событий происходит через 3 класса?

Почему???

Кстати, с памятью работу более менее решил, итак забываем напрочь что говорит SUN, любой обьект должен быть по заверщению уничтожен следующим образом:
object = null;
Иначе строки, объекты базы, да что угодно будет вечно торчать в памяти.

← →
Simpson (2008-03-22 18:35) [14]

ferr (22.03.08 18:22) [11]
Ответь хоть на один вопрос защитник, зачем это было зделано?

← →
Mystic © (2008-03-22 18:43) [15]

А какой у тебя опыт в Java, C++?

Я бы предпочел все-таки C++. Главным образом потому, что тут все в моих руках, я четко представляю, какие проблемы могут случится и как их решать (утечки памяти, AV, уязвимости, ...). В Java я бы не полез ввиду того, что (1) слишком аскетичный язык, на мой взгляд (2) нет достаточно опыта. Я не верю, что Java это панацея от всех бед. Проблемы обязательно будут (см. [2]), при этом зачастую характер проблем такой, что проявляться они могут далеко не сразу. А это очень неприятно для 24/7.

← →
Simpson (2008-03-22 19:36) [16]

@!!ex © (22.03.08 17:05)
Мое резюме(мой опыт 2 програмки 24/7(сервис, прога по закачке) зделано мною) надежность Java миф всю надежность придется тебе делать самому, иначе все упадет и не понятно почему.

← →
DVM © (2008-03-22 19:59) [17]

У меня почти все проекты из расчета 24/7, и между Java и С я выбрал бы С. Причины описаны в [15]

← →
31512 (2008-03-22 20:02) [18]

Мдяя. У нас Oracle падает аккуратненько раз в полгода. Первые 2 раза это вызвало панику с потерей данных. Потом научились. Остальные 6 раз уже просто небольшими беспокойствами отделались.

← →
Petr V. Abramov © (2008-03-22 20:15) [19]

> 31512 (22.03.08 20:02) [18]

причину падения высянить не пробовали?
:)

← →
Simpson (2008-03-22 20:18) [20]

Petr V. Abramov © (22.03.08 20:15) [19]
Не стандартно мыслиш, в java принято на падение перезапуск ставить))

← →
31512 (2008-03-22 20:20) [21]

> Petr V. Abramov © (22.03.08 20:15) [19]

Админ говорил, но у меня это со временем забылось. :-( В результате он лечит это за 15 минут. Всё зависит от того сколько будет дамп БД всасываться. Могу и ошибиться, но как раз там Жаба где-то дохнет.

← →
Simpson (2008-03-22 20:34) [22]

31512 (22.03.08 20:20) [21]
Жаба там дохнет от того что не вычищает после себя, все это накапливается и взрывается. Эта трабла еще с jdk 1.3 качует независимо от версий. Проверь на утечки и все станет на свои места.

← →
31512 (2008-03-22 20:45) [23]

> Simpson (22.03.08 20:34) [22]

Я вот теперь из принципа поинтерисуюсь у админа, чего он там накопал в качестве причины. :-))) Спасибо за наводочку. Признаться с Жабой я не имел дела и про такие проблемы с памятью слышу впервые. Хотя в одном из разговоров давным-давно эта тема затрагивалась. Говорили, что если объект А ссылается на объект Б, а Б на А, то сборщик мусора не может разрешить такую взаимную ссылку и объекты остаются в памяти до морковки на заговенье.

← →
Автор вопроса (2008-03-22 20:46) [24]

[с чужого компа]
Опыт есть: на JAVA писал аплеты (изучал ее) лет 8 назад. Все.
На С/С++ писал много, ряд сервисов в режиме 24/7 под разные платформы (крос-платформенный код). P.S. Это не так сложно, если ПО не взаимодействует с пользователем (различные сервера (демоны в *nix)).
Сейчас выступаю не как программист, а как архитектор новой системы. Я ее сам писать не буду, для этого есть программисты. Мне надо для себя понять, что лучше и почему. У них опыт работы как в JAVA так и в C/C++ есть но не фундаментальный. И они все как один за JAVA. Я их понимаю:
1) не надо изучать второй язык (JAVA у нас полюбому будет, как раз для клиентских приложений)
2) JAVA сейчас очень популярна. Они тем самым себе планку повышают, т.е. улучшают перспективы.
Но сам склоняюсь в сторону С/С++. Хотя бы по тому, что:
1) Есть ряд приложений, которые не работают толком на JAVA (HP IUM, Oracle application server), хотя компании-авторы могут себе позволить любых программистов. Вывод: не в программистах дело.
2) Отсутствие поддержки JVM, со стороны Sun и поставщиков железа (HP, IBM и т.д.). Если что-то произойдет с JVM у заказчика, что делать? К кому обращаться? Сколько времени уйдет на восстановление? На C/C++ проблема с компилятором может решаться очень долго, это наша внутренняя проблема. Заказчик о ней не узнает. Ему уйдет протестированный и рабочий код.
3) Ресурсоемкость JAVA. Был опыт: при простой замене парсера с perl на JAVA, требования к ресурсам возросли в 10(десять)!!! раз (CPU+память).

← →
31512 (2008-03-22 20:55) [25]

> Автор вопроса (22.03.08 20:46) [24]

> 2) JAVA сейчас очень популярна. Они тем самым себе планку
> повышают, т.е. улучшают перспективы.

Вот уж совсем не довод. Мало ли что сейчас популярно. Речь идёт о промышленной надёжности! Получается куда крестьяне туда и обезьяне?

← →
@!!ex © (2008-03-22 20:59) [26]

> [24] Автор вопроса (22.03.08 20:46)

Кстати, Автор вопроса - не я.
Просто с моего компа писали.

← →
deneb (2008-03-22 21:20) [27]

> 1) Есть ряд приложений, которые не работают толком на JAVA
> (HP IUM, Oracle application server), хотя компании-авторы
> могут себе позволить любых программистов. Вывод: не в программистах
> дело.

Дело в кошках (и рецепте приготовления).

> 2) Отсутствие поддержки JVM, со стороны Sun и поставщиков
> железа (HP, IBM и т.д.). Если что-то произойдет с JVM у
> заказчика, что делать? К кому обращаться? Сколько времени
> уйдет на восстановление? На C/C++ проблема с компилятором
> может решаться очень долго, это наша внутренняя проблема.
> Заказчик о ней не узнает. Ему уйдет протестированный и
> рабочий код.

Очень надуманная проблема (лисичка приходит в обоих случаях).

> 3) Ресурсоемкость JAVA. Был опыт: при простой замене парсера
> с perl на JAVA, требования к ресурсам возросли в 10(десять)!
> !! раз (CPU+память).

В IBM на это отвечают: "If you want to eat hippopotamus, you"ve got to pay the freight."

Стоит обратить внимание еще на некоторые аспекты - сроки и квалификация разработчиков.
Если этим будет заниматься уважаемый @!!ex, то стоит выбрать Java, так как язык весьма незамысловат и обладает исчерпывающей библиотекой (об application серверах тут так же говорили, возможность синхронизации между нодами кластера есть, посмотрите как это реализовано в quartz).
Если вы можете позволить себе пожертвовать сроками и качеством, то C++ - ваш выбор.

← →
Mystic © (2008-03-22 21:22) [28]

Тут надо еще помнить, что C++ язык острый как бритва, и при неумелом использовании может стать опасным. Ну и кроме того, если писать на C++ в функциональном стиле а-ля boost или а-ля Александреску, то с непривычки можно очень быстро утонуть в архитектуре. Далее, после долгих лет работы с managed языками придется восстанавливать (или приобретать) некоторые навыки программирования с нативным кодом (AV, memory leaks, низкоуровневая отладка, иногда даже ассемблер), потому как на Java быстро отвыкаешь об этом заботится.

Так что если бы я не принимал участия в разработке, то ориентировался на опыт программистов. Если у них большой опыт в Java и слабый опыт в C/C++, то я бы или искал новых людей или пришлось бы остановится на Java. Java хороша тем, что не требует большой скурпулезности в работе. Но при разработке 24/7 скурпулезности таки нужна, так что в этом случае я бы (1) тщательно изучил все возможные слабые места, возможности утечек (2) провел бы тесты по этим слабым местам [хотя на разных платформах Java может себя вести по разному] (3) на семинарах бы обсудил результаты (4) ввел стандарты кодирования с учетом результатов проверок (5) ввел бы обязательный code review.

← →
Ломброзо (не с работы) (2008-03-22 23:45) [29]

половина ветки - глупые измышления. во-первых, существут несколько реализаций jvm. чем дороже, тем устойчивей. во-вторых, проблема освобождения ресурсов давно решена, причем схожим образом и для java, и для с#. гуй в swing был, есть и будет тормозить, но к счастью, существуют swt и прочие легковесные оконные фреймворки. кроссплатформеность - вовсе не миф, и проект eclipse тому доказательство.

кроссплатформеность - вовсе не миф, и проект eclipse тому доказательство.

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

не, не миф....

> 31512 (22.03.08 20:20) [21]

> Всё зависит от того сколько будет дамп БД всасываться.

> Админ говорил,

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

> Ломброзо (не с работы) (22.03.08 23:45) [29]
> существут несколько реализаций jvm. чем дороже, тем устойчивей.

java - свободная, бесплатная, халявная технология, которая со временем приведет к торжеству свободного софта....

← →
Автор вопроса (2008-03-23 09:12) [33]

> Ломброзо (не с работы) (22.03.08 23:45) [29]
> половина ветки - глупые измышления. во-первых, существут
> несколько реализаций jvm. чем дороже, тем устойчивей

Дай ссылку на платную, крос-платформенную JVM, с поддержкой.
Я пока не видел платной JVM. На мой запрос, Sun официально ответил, что они пока такой поддержки не обеспечивают.

> Игорь Шевченко © (22.03.08 18:19) [10]
> Petr V. Abramov © (22.03.08 18:18) [9] Инсталлятор ихний
> на Java написанный вполне себе работает. Да и прочие тулзы.
> Но не в режиме 24/7.

Я согласен с Петром. Писать на Java они не умеют. Видел я их произведения...
На Java нужно уметь писать, как и на любом другом языке.
Хотя потенциально серверные приложения на Java более надёжны.

Важно: я точно сказать не могу, не я решаю, но по опыту могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч $.

Ну за такие-то бабки можно не лениться и отдельные релизы под все платформы наваять.

> Автор вопроса (23.03.08 09:12) [33]
>На мой запрос, Sun официально ответил, что они пока такой поддержки не обеспечивают.

Не знаю, не знаю, просто не совсем понимаю какой уровень поддержки требуется.

Я работаю в фирме, один из продуктов которой как раз и есть сервер на Java, работающий на многих платформах 24/7. Заказчики серьёзные - Boeing, NASA, Airbus, Toyota,...

> Игорь Шевченко © (24.03.08 10:34) [35]
> Alex Konshin © (24.03.08 10:32) [34] Отсюда вывод - не
> стоит применять Java для таких приложений (24/7) :)

Не согласен.
При том же уровне программиста на C/С++ приложение вообще работать не будет. На Java скорее всего будет, но медленно. А если нужно быстро и надёжно, то нужно и программистов соответствующих.
На Java просто сделать самовосстанавливающийся сервер. А на C/C++ почти любая ошибка фатальна. То есть, для 24/7 Java намного более предпочтительна с этой точки зрения.

А насчёт производительности... Ты посмотри с такой стороны: насколько надёжно ты сможешь реализовать многопоточность с сервере на C/C++ и, главное, проследить, что все твои программисты будут так же аккуратны?
А ведь в современных условиях сервер просто обязан работать во многопоточной среде. Иначе все теоретические возможности оптимизации в C/C++ с лихвой покроются легкостью распараллеливания на Java. Да и не такая она уж и медленная, нужно просто уметь писать. Ситуация с Java примерно такая же, как и с Delphi: легкость языка порождает наплыв дилетантов, и их творения и создают имидж тормознутости.

Alex Konshin © (24.03.08 11:00) [38]

Когда все упирается в квалификацию программиста, тем более, задающего вопрос на форуме - "а что бы мне такое выбрать для написания сервера 24/7", то ответ вообще очевиден.

> Игорь Шевченко © (24.03.08 11:10) [39]
> Alex Konshin © (24.03.08 11:00) [38] Когда все упирается
> в квалификацию программиста, тем более, задающего вопрос
> на форуме - "а что бы мне такое выбрать для написания сервера
> 24/7", то ответ вообще очевиден.

Для серверов ответ, на мой взгляд, действительно очевиден. Я правда не совсем уверен, что мы очевидим одно и то же.

А в конкретном случае нужно смотреть более детально на саму задачу. Очень маловероятно, что C/C++ будет предпочтителен, но всё же случаи разные бывают.

Кстати, опять-таки по работе в фирме... У нас практически все приложения многоплатформенные, но это не значит, что везде используется Java. Есть много продуктов, написанных C/C++. Так что я непонаслышке знаком с вопросом выбора инструмента. Я специализируюсь на Java, хотя и умею C/C++ (как и многое другое). Но я рекомендую Java вовсе не поэтому, а потому, что хорошо знаком с достоинствами и недостатками обоих подходов.

В качестве ещё одного довода приведу ещё один: отладку и тестирование. На Java это будет намного проще и дешевле хотя бы потому, что зависимость от платформы меньше. Просто представьте себе объёмы тестирования сразу на многих платформах. Не забывайте ещё о 32-bit и 64-bit (на C/C++ это будет ещё одна тема для развлечений). В случае Java можно уменьшить количество платформ без существенного ухудшения качества тестирования. Обычно это сводится к паре-тройке платформ типа Windows 2003/XP (32/64 bit) и какой-нибудь юних типа Linux x86 64-bit, AIX, HPUX или Sun Solaris. Естественно, перед релизом нужно будет всё-равно тестировать все платформы, но хоть не нужно это делать с каждым билдом.

Надежность JAVA-приложения Найти похожие ветки