А никто не сталкивался?

Поставил deb'ку опенфайра, настроил, подключил к AD, добавил админа из AD, вошел, все заработало. Потом перезапустил сервис, захожу на 9090 порт, показывается окно логина - но при вводе логина и пароля - говорит неверные. Логин и пасс 100% точные, пробовал множество адшных юзеров, всех отсылает, логи пустые, только в ворнинге сыпет ошибки входа.

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

Debian SID, ява от sun-*

>малая нагрузка на систему и низкое потребление памяти;

Да ипанись, жаба и низкое потребление памяти не совместимо. Гуано - в топку.

> чем он лучше ejabberd?

Тем что на менее малоизвестных технологиях.

В смысле, вы готовы когда ejabberd будет тихонько слать вас лесом, плюя в лог огромной простыней эрланговских термов, запускать старый добрый erl -sname fuckme -remsh ejabberd@example и громко ругаться на эрланге, втыкая в гугль (если не повезет — в исходники), и параллельно вкуривая документацию по OTP (включая ту же Mnesia)? Если да — OpenFire вам не нужен. Если нет — как-то более наоборот.

> джава один из лучших ЯП на данный момент, не надо на неё гнать

Я гнал на яву? Я пытаюсь до вас донести, что она здесь не в тему. Писать Серверные приложения на яве - все равно что собирать авиадвигатели из конструктора «лего».

>Писать Серверные приложения на яве - все равно что собирать авиадвигатели из конструктора «лего».

LOL! мальчик, ты про j2ee что-нибудь слышал? :)

в irc ещё в 90х годах на 10000 юзеров на сервер и 200000 юзеров на сеть и то жрало меньше. где прогресс?

А кто сказал, что прогресс должен уменьшать накладные расходы?

>малая нагрузка на систему и низкое потребление памяти;

ололо :DDD

а вапще гуд штушка, пользую

а что ж на яве тогда писать?

> И это говорит человек, который сидит на самом жавовом сервере, на ЛОРЕ!

Во-первых, я на нем не сильно-то и сижу, мне на этом форуме фана хватает.

Во-вторых, я ЛОРу не хозяин, не я его админю, так что не мои проблемы.

какое-то время был у меня этот openfire. всё бы ничего но под маской удобства у него были жёсткие неудобства с установкой самописных сертификатов.

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

и админка у openfire сделана не так угловато, хотя это субъективно.

Да вам, батенька, в корреторы, или так не интересно?

> LOL! мальчик, ты про j2ee что-нибудь слышал? :)

Да я в последнее только о ней от явистов и слышу. Вы услышали звон, да не знаете где он. Создание приложений на яве стоит на порядок дешевле, чем на языках низкого уровня. Заказчикам софта дешевле закупить/арендовать кучу мощных железок чем оплачивать разработку на том же С++. Но это касается случаев с «одноразовым» ПО. Жаббер-сервер - куда более популярная вещь, и ее целесообразно писать на Сях.

ждем ебилда =(

целиком с этим мальчиком солидарен.
серверные приложения должны быть на руби! :D

> а что ж на яве тогда писать?

Ну существует масса задач, где не требуется высокопроизводительный код, либо ПО нужно на один раз и не хочется убиваться написанием его на С/С++, та же упомянутая здесь j2ee...

Я повторюсь, но жаббер-сервер тоже может попасть в эту категорию, если он используется внутри небольшой корпоративной сети.

> ejabberd тянет за собой erlang, который овер 100Мб

Ровно столько же тянет openfire в виде openjdk6 (по-крайней мере в моем случае).

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

хех... ладно, попытаюсь объективно оценить ситуацию. у вас, скорее всего, был только опыт работы на сях, у меня наоборот — работал, в основном, только с джавой (институт не в счет). поэтому каждый смотрит на вещи со своей колокольни.

но думаю, что не погрешу сильно против истины, сказав, что рынок корпоративных приложений поделен, прежде всего, между платформами .net и j2ee. в рамках платформы .net используется, прежде всего, c# — про с++ в данном секторе вообще ничего слышал (хотя, может, оно там где-то и есть). джава (а вернее j2ee платформа) очень часто выбирается для написания приложений в банковском секторе (не только у нас, но и во всем мире). назвать такое ПО «одноразовым» как-то язык не поворачивается. писать на с++ сложные приложения для работы в многозвенной архитектуре действительно, как вы и сказали, будет очень дорого. настолько, что дешевле будет закупить «кучу мощных железок». это будет и просто нецелесообразно — во-первых, вы вряд ли уложитесь в срок, отведенный заказчиком (разработка на джаве будет в разы быстрее — думаю, тут никто спорить не будет), во-вторых, замучаетесь такие приложения потом отлаживать и ловить утечки памяти. языки высокого уровня для того и придумали, чтобы сконцетрировать усилия на решении задачи. а оптимизацией пусть занимается компилятор — к тому же, они справляются с этой задачей из года в год все лучше и лучше.

>Я там понимаю, исходные коды на дурацком эрланге править, чтобы SASL/EXTERNAL запилить, но уж для перевода-то не нужны какие-то специфические знания!

Собственно поэтому перевод и был выполнен PROMT'ом ;)

> А есть сорцы тестов/конфигов для tsunga?

Есть.

Всё правильно, только с утечками памяти Вы загнули. Я тоже думал, что с C# и яве это проще (столько об этом кричат), а в реальности нужно знать и уметь гораздо больше, чем в С++: как работает сборщик мусора (подробно!!!), поколения, что такое Dispose, Finalize и т.п. и т.д. Без этого просто на работу не примут, потому, что... без знания этого, по мнению работодателя, будет куча проблем с утечками памяти. ;) А что нам нужно знать в C++? new, delete, когда нужно, и всё. ;)

Хотя конечно возможностей в C# или яве на порядок: куча компонентов на все случаи жизни, чтобы не изобретать лишний раз велосипеды: хочешь десктоп, хочешь веб, хочешь мобильник, сервис, компоненты под различные задачи - всё, что угодно. В С++ нужны специализированные библиотеки и то почему-то в них нет наверное и 10-й части, того, что есть в технологиях .Net и Ява, хотя они моложе C++.

Можно получить? Хочется тоже эти тесты на своем сервере повторить.

p.s. Сам использую ejabberd

В корреторы, говрите?

> ejabberd/mnesia

Ну и чего ты хотел? Mnesia не предназначена для таких нагрузок, её оптимально использовать только на маленьких инсталлах.

Обновил. Всё работает.

малая нагрузка на систему и низкое потребление памяти

написан на java, не может оно потреблять мало памяти. so альтернативы jabberd пока нет

>А что нам нужно знать в C++? new, delete, когда нужно, и всё. ;)

Как вы правы. А еще можно писать нормальные классы, которые будут очищаться сами, при выполнении определенных методов или диструкторов. А еще есть talloc ;). И умные указатели. Да тысячи вещей, в конце концов, при использовании которых можно забыть о сотнях «delete» и «free». По поводу библиотек - тыщи либ на фортране, си и на плюсах как бы намекают нам. Использовать все это или писать свой собственный костыль - решать только вам.

>из года в год все лучше и лучше.

а, да, жаба из года в год всё меньше тормозит. ну, она, ясен-пень от рождения совсем не тормозит, но всё же еще по чуть-чуть каждый год нетормознеет... настолько, что гораздо быстрее запустить VirtualBox с WindozeXP, а в нем всякие Users and Computers, чем запускать Ааапчхи Directory Studio, не говоря уже о том, что последним с АД работать стрёмно (а иногда, даже для простейших задач, и вовсе невозможно), хотя это, есессно, не только его вина.
вот этот Directory Studio у меня только для Ъ-шности и остался, видом своей иконки мне ЧСВ греет. ну, покопаться в структуре AD можно, хотя сама идея делать инструмент на основе редактора (как ни крути), особой радости не доставляет. а работа идет через фенду в виртуалке и лапотный adtool. ибо тор-мо-зиит, а уж запускается как две виртуалки. да, на компе 2GB памяти и двухвёдерный проц.

> А, Вы из Белоруссии. Стало быть, в РБ нет санкций за задержку зарплаты? В РФ это уголовно наказуемо (ст. 145.1 УК). Те из трудящихся, кто не стонут о злых буржуях за бутылкой спиртного, а реально обращаются в прокуратуру, вполне себе отсуживают денежки.

Я думал, что вы молоды. Я ошибся, вы просто дурачок местный.

>Использовать все это или писать свой собственный костыль - решать только вам.

Это надо знать, искать, прикручивать, линковать: с Qt более или менее понятно, хотя она беднее .Net-a, с boost-ом тоже (хотя сложнее). А с нетом или явой фреймворк поставил и всё под рукой.

Openfire рулит GSSAPI и простой связкой с ldap изкаропки.
основной минус - глушняк в развитии. Даже баги фиксятся очень долго. А новых плюшек за последние годы не было вообще.

>> а что ж на яве тогда писать?

Ну существует масса задач, где не требуется высокопроизводительный код, либо ПО нужно на один раз и не хочется убиваться написанием его на С/С++, та же упомянутая здесь j2ee...

Я повторюсь, но жаббер-сервер тоже может попасть в эту категорию, если он используется внутри небольшой корпоративной сети.

Какие то теоретические высказывания.

С++ ничем не лучше для серверного ПО, чем Java - а именно что хуже.

1. Java это платформа - со всем необходимым, создано единобразно, системно и изначально полностью в парадигме ООП. С++ это лишь набор костылей наполовину тянущихся из СИ и всякого legacy ранних стандартов языка, наполовину замешанных на жуткой смеси из шаблонов. Часть функций std - бросают исключения, часть возвращает 0 при ошибке и т.д., т.е. нет системности. В С++ из коробки даже тредов нет (ну может исключая последний стандарт), а следовательно в стандартной библиотеке отсутствуют потокобезопасные контейнеры и обслуживающие функции, уже не говоря про сетевые возможности, я даже не говорю про асинхронный ввод/вывод. Всё надо дёргать из низкоуровнего СИ API (ессно плтформозависмого) - и никакого ООП, либо искать по интернетам приличные библиотеки. Есть ещё конечно Boost - но это именно следствие совершенно «пустой» стандартной библиотеки.

2. Производительность - в С++ ОЧЕНЬ медленные исключения (по этому в библиотеках и всяких фреймворках их никто и не использует). Выделение памяти в куче - в разы медленнее того же действа в JAVA. Тут конечно можно возразить, что C++ позволяет подменить менеджер памяти, но его надо сначала написать! JAVA VM и JIT компилятор проводит анализ ИСПОЛНЕНИЯ кода на основе статистических данных полученных за время выполнения программы и проводят оптимизации на лету (надо ли говорить что в С++ этого нет, хотя возможно будет в LLVM) - естественно это имеет прямое отношение к серверным приложениям которые работают месяцами/годами без перерывов.
3. JAVA приложение не умрет по SIGSEGV.

Таким образом JAVA как платформа и язык разработки - гораздо лучше подходит для разработки серверных приложений, чем C++. Даже mono лучше.

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

Спасибо за инфу, которую я как раз пытался до вас донести. Под «одноразовым» я имел в виду ПО, которое пишется под одного-двух-нескольких клиентов. В случае разработки ПО для более широких кругов использование низкоуровневых языков с горой окупается.

Иногда да, иногда нет.

> Java это платформа - со всем необходимым, создано единобразно, системно и изначально полностью в парадигме ООП.

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

В С++ из коробки даже тредов нет...

В С++ из коробки вообще много чего нет, для этого есть туева куча сторонних библиотек.

отсутствуют потокобезопасные контейнеры и обслуживающие функции

Проблемы? Напиши и используй. С другой стороны, потокобезопасность нужна далеко не всегда. Так зачем всюду таскать за собой эти тормоза с мютексами?

Всё надо дёргать из низкоуровнего СИ API

Может, я открою вам Америку, но Си и С++ и не претендуют на высокоуровневость современных языков.

Выделение памяти в куче - в разы медленнее того же действа в JAVA.

Выпрямьте руки или лучше не лезьте на низкий уровень. Кто память выделяет по 1-2 байта, тому руки вообще оторвать полагается.

компилятор проводит анализ ИСПОЛНЕНИЯ кода на основе статистических данных полученных за время выполнения программы и проводят оптимизации на лету

Как вы проведете оптимизацию «на лету» в бинарниках? Да и оптимизация во время выполнения - это вставка костылей во время полета. Оптимизацию проводят при разработке и компиляции. Статистические данные для этого не нужны, прогер сам знает, какие куски кода наиболее критичны для оптимизации.

JAVA приложение не умрет по SIGSEGV.

А бинарники, по-вашему вылетают? Придется опять открывать Америку:

SIGSEGV - принудительный перевод Program Counter в функцию-обработчик события «ошибка сегментации». Это делает непосредственно процессор. По умолчанию эта функция выводит название ошибки в stdout и завершает программу. Кто мешает вам ее заменить?

Таким образом JAVA как платформа и язык разработки - гораздо лучше подходит для разработки серверных приложений, чем C++. Даже mono лучше.

Поправочка: для быстрой и дешевой разработки. Что при этом пострадает, думаю, не стоит объяснять. А что, вы сравнивали криворукие решения на Си с пряморукими на яве? Давайте сопоставим качественные изделия. Тут ява в боольшом минусе, хотя бы потому, что крутится поверх виртуальной машины, написанной на Сях.

Безтолковый спор. ;)

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

Если не использовать ООП в C++ - то в чём тогда смысл использования C++ вместо С??? В перегружаемых функциях или шаблонах???

В С++ из коробки даже тредов нет...

В С++ из коробки вообще много чего нет, для этого есть туева куча сторонних библиотек.

отсутствуют потокобезопасные контейнеры и обслуживающие функции

Проблемы? Напиши и используй. С другой стороны, потокобезопасность нужна далеко не всегда. Так зачем всюду таскать за собой эти тормоза с мютексами?

Епт, разговор идйт в контексте разработки серверных приложений (квотинг ты удачно порезал). Покажи мне ЛЮБОЕ серверное сетевое приложение без тредов??? Как ты будешь обслуживать множество клиентов - форкать процесс на каждого клиента?

Выделение памяти в куче - в разы медленнее того же действа в JAVA.

Выпрямьте руки или лучше не лезьте на низкий уровень. Кто память выделяет по 1-2 байта, тому руки вообще оторвать полагается.

Без разницы сколько байт, каждый вызов new/delete - вызов системного аллокатора - минимум один системный вызов на каждую операцию.

Ты, как я понимаю, предлагаешь писать свой менеджер памяти - выделяя сразу большой пул памяти и раздавая по чуть-чуть оттуда. Но это сразу ломает кучу сторонних приложений, начиная от инструментов отладки и т.д.
Но смысл рисовать велосипеды когда уже есть готовое, отлаженное - бери и пользуйся. Когда можно сосредоточиться на бизнес логике, а не прикручивать костыли к убогому C++???

>SIGSEGV - принудительный перевод Program Counter в функцию-обработчик события «ошибка сегментации». Это делает непосредственно процессор. По умолчанию эта функция выводит название ошибки в stdout и завершает программу. Кто мешает вам ее заменить?

Мде у вас слабовато с мат. частью. Ошибка сегментации это реакция ОС - внешнее исключение, и в зависимости от настроек можно выбрать только 2 варианта - умереть и умереть с сбросом дампа памяти. А на некоторых платформах после ошибки сегментации - устройство принудительно перегружается. ВСЁ никаких stout'ов.

вариант который ты описываешь это а'ля watchdog внешнее приложение следящая за кодом возврата целевой программы. Никаких способов обработать эту ситуацию внутри сбойного приложения НЕ СУЩЕСТВУЕТ. А в Java это будет обычный null pointer exception, который можно посмотреть, покрутить и даже, в некоторых случаях продолжить работу.

Я всего лишь не слишком смешно пошутил, подыграв Вам, что-де я Ваш бухгалтер и Вы мне якобы должны денег. Вы могли продолжить шутку более остроумно или просто отмолчаться, но Вы почему-то впали в истерику и начали хамить. Поскольку в обыденной жизни такая реакция у нормальных людей обычно не наблюдается и даже для ЛОРа Ваше поведение слишком уж девиантно, мне интересен ход Вашего мышления. Что подтолкнуло Вас так себя вести?

>> компилятор проводит анализ ИСПОЛНЕНИЯ кода на основе статистических данных полученных за время выполнения программы и проводят оптимизации на лету

Как вы проведете оптимизацию «на лету» в бинарниках? Да и оптимизация во время выполнения - это вставка костылей во время полета. Оптимизацию проводят при разработке и компиляции. Статистические данные для этого не нужны, прогер сам знает, какие куски кода наиболее критичны для оптимизации.

Тут вообще мрак. В Java bytecod вполне пригоден к оптимизации. Некоторые оптимизации вообще возможны только на основе анализа исполнения приложения.

Читайте хоть литературу по теме.

http://ru.wikipedia.org/wiki/HotSpot

> Но смысл рисовать велосипеды когда уже есть готовое, отлаженное - бери и пользуйся. Когда можно сосредоточиться на бизнес логике, а не прикручивать костыли к убогому C++

Имеющиеся на сегодняшний день готовые решения не позволяют достигнуть сишной производительности. Вот где собака зарыта. Ускорение выделения/удаления памяти - это один из единичных преимуществ на фоне туевой кучи тормозов.

К тому же, кто мешает написать менеджер памяти для С++ один раз и пользоваться им где угодно?

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

Лови, Фома неверующий:

#include <stdio.h>
#include <signal.h>

void alternative()
{
    printf("***Альтернативное завершение***\n");
    exit(0);
}

void catchEx()
{
    printf("***перехват ошибки сегментирования***\n");
    alternative();
}

int main()
{
   signal (SIGSEGV, catchEx);

   int* k = 0;
   *k = 0;

   printf("***Успешное завершение***\n");
   return 0;
}

скомпиль, запусти, а потом уже рассказывай.

Странно, что опять всё скатилось в срач java vs. c
Openfire 3.7.0 так в итоге никто и не ставил? А если ставили, то как впечатления, что там новенького интересного?
Кстати, насчёт самоподписанных сертификатов - а что под ними подразумевается? Ведь всё же зависит от того, о каких корневых сертификатах знает сервер (выступая в s2s-взаимодействии в роли клиента), каким корневым сертификатам он доверяет. Условно говоря, если сервер не знает ничего о Verisign'е, то он будет считать некорректным цепочку доверия до Verisign'а, а сам корневой сертификат - злостным образом самоподписанным. Собственно, если импортировать в truststore для Openfire все возможные корневые сертификаты (в том числе и свои собственные, самоподписанные), то никаких проблем с s2s'ом не будет, тут корень проблемы по-моему в том, что во-первых Openfire по дефолту почти никому не доверяет, а во-вторых - политика отношения к сертификатам с невалидной с точки зрения OF цепочкой доверия хоть и задаётся в админ-морде (есть опция отношения к самополписанным сертификатам в s2s), но почему-то ни на что реально не влияет.

мы говорили про серверную часть. а всякие толстые клиенты на swing или swt действительно не особо шустрые.

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

Есть мнение, что у вас руки из задницы растут