Сергей Тарасов:
>А как это можно избежать, если вдруг 50 пользователей захотят
>одновременно что-то сделать, при этом у каждого из них есть свои
>данные, ассоциированные с сессией, и критические секции? Создавать
>свой диспетчер, который будет 50 пользователей обслуживать пачками
>по 10 штук? А может еще и свои mutex'ы написать?
У пользователя своя критическая секция - уже смешно.
А если серьезно - тут много вариантов.
1. Что делает ОС, когда ей не хватает памяти под очередной malloc? Правильно - посылает куда подальше. Можно отказать в запросе.
2. Сервер - realtime система? Нет - клиент может подождать пока освободится поток, для его обсуживания. Клиент все равно ждет создания потока. Если не пытаться прыгнуть выше головы (обслуживать 1000 клентов на P200 с 16М) - все будет отлично работать.
3. Можно попробовать не изобретать колесо и воспользоваться существующими технологиями. Не в этом случае, конечно, но например, RMI и EJB позаботятся о создании потоков сами, а серверы EJB еще сами кластеризуются.

Было бы желание - программы на Жабе могут работать очень эффективно, но так же как любую другую технологию Жабу надо изучать.

Александр Киреев
>В любой книге, где обсуждается производительность _любых_ многопоточных систем написано, что создание не только потока, а даже самого простого mutex'a - довольно дорогая операция, которую можно избежать и нужно избегать как можно больше.
А как это можно избежать, если вдруг 50 пользователей захотят одновременно что-то сделать, при этом у каждого из них есть свои данные, ассоциированные с сессией, и критические секции? Создавать свой диспетчер, который будет 50 пользователей обслуживать пачками по 10 штук? А может еще и свои mutex'ы написать?

Для Александра Киреева:

Программу я Вам отправил.

Для Александра Киреева:
"...до 30 минут, конечно не доходило, но ждать 15 минут после File>Exit - такого ни одна Java-программа себе не позволит. "

Java-программа тут нипричем, памятью-то управляет Java-машина. Но речь шла об отрисовке.

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

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

Для уточнения деталей реализации можно обратиться к Lamer'у.

Казанцев Алексей:
>Я не прошу верить мне. Можете сами это все попробовать. Я не ставил
>себе цель растоптать Java. Мне это не нужно. Я высказываю свое
>отношение. Я констатирую факты. Но если не верите повторите мои
>действия и увидите сами.
Так пробую ж. Чуть ли не каждый день ;-) И процессор у меня 533-й. Поэтому и не верю. Он (жб) у меня несколько тысяч классов компилирует быстрее (по живому времени, а не по процессорному). И отрисовывается довольно резво. Можем провести эксперимент: вы мне форму по мылу, а я у себя попробую и поделюсь впечатлениями с посетителями Базарной Площади.

Казанцев Алексей:
>Слишком пылко Вы на Lamer'а набросились. Вы знаете о том, как он
>реализовал свой сервер? Если не знаете зачем кричать всякую ерунду.
>Он написал, что подключаются НЕСКОЛЬКО клиентов, а не несколько
>десятков/сотен, а Вы аж до 1000 размахнулись. Нехорошо это, на людей
>бросаться.
Бросаться словами тоже нехорошо. Многуважамый Lamer приводит примеры, которые для любого человека, хоть немного знакомого с Жабой, означают ничто иное, как нежелание разобраться и (возможно) проблемы с руками. Я могу написать программу на С++ (в Паскале я не очень), которая сдохнет через минуту работы, потому что будет забывать освобождать память - это тоже будет пример?

Насчет того, как написана программа - я обсуждаю то, что прочитал. Если написано "для каждого соединения создавался отдельный поток", я об этом и говорю. В любой книге, где обсуждается производительность _любых_ многопоточных систем написано, что создание не только потока, а даже самого простого mutex'a - довольно дорогая операция, которую можно избежать и нужно избегать как можно больше. Не буду обвинять Lamer'a в том, чего он не делал, но не удивлюсь если еще 30% времени его программа проводила на лишних synchronized инструкциях, которые тоже легко съедают ресурсы.

Для Александра Киреева:
Я не прошу верить мне. Можете сами это все попробовать. Я не ставил себе цель растоптать Java. Мне это не нужно. Я высказываю свое отношение. Я констатирую факты. Но если не верите повторите мои действия и увидите сами.

Простите за некоторую резкость.
Просто задолбали этими самыми криками.
Устал от этих миссионерских игр.
"Смотри какая у тебя религия плохая, а у меня хорошая"

>Также в Java напрочь отсутствует наши любимые по Delphi Access Violation.
Это смотря как писать... Когда я писал на TurboC++ меня мучала ошибка "Слишком много ошибок".

>Скорость - не проблема, как Вы могли бы подумать
Как раз об этом и думали...

>(не поленился - потестировал - скорость с приложением на Delphi одинаковая, иногда даже быстрее - это кстати и не удивительно - в какой то мере со своими RTTI любое Delphi приложение тоже не тянет на полностью скопилированное в машинный код, а в Java на это оптимизация предусмотрена).
И за что интересно M$ ругали, говоря "VB - не комилятор"? Ведь он такой шустрый интерпритатор и "...на это оптимизация предусмотрена..."! Имеет смысл почитать умные книжки на предмет того, что такое компилятор и что такое интерпритатор.

> писать программы на Java быстрее, удобнее
За несколько лет работы на чем-то складывается некий инструментарий, библиотечки, набор программ, которые надо поддерживать и развивать
> и прибыльнее
за которые платят деньги
>(многоплатформенность, мощные базовые библиотеки и реклама Sun делают свое дело)
Я не знаю как обстоят дела в тех местах, где живете Вы, но в столице суверенного Башкортостана городе Уфе о рекламе Sun не слышали (те с кем общаюсь я и их знакомые), базовые библиотеки не содержат то что нужно местным пользователям, а единой и непобедимой платформой является wintel 98/NT/2000 причем компы клиентских мест в среднем P100.

Под криками "Никс!", "Ява!", "C#", "VC+VB сладкая парочка" продолжает плыть Delphi и оставаться лучшей по всем категориям для местных разработчиков.

Казанцев Алексей:
>С памятью я поэкспериментировал. И что? Да ничего не изменилось.
В принципе, и не должно было, но в 31 минуту верится с трудом. Работаю с ЖБ4 с его выхода. Проекты - не маленькие: и файлов достаточно, и GUI есть. Да, видел минут пять откачивания, когда билдер зажрал 90М из 128, а еще и рядом другое приложение на Жабе висит. Но 31 минута чистого процессорного времени - это уже слишком. В это - "Не верю!"(с)Станиславский

>Изменил, я, приоритет Java-машины на High и в результате тормозить
>стала уже система ПОЛНОСТЬЮ.
С приоритетом я тоже пробовал - эффект обычно отрицательный (почему - не знаю, но факт: куда его не меняй - только медленее станет).

Казанцев Алексей (чуть раньше):
>...но ни одна, даже самая тормозная, скомпилированная программа не
>будет отрисовывать себя полчаса.
А вот и нет (радостно потирая руки ;-) ). Я недавно пробовал несколько програм, для рисования UML диаграм. Программы на жабе (да, такие коммерческие продукты тоже бывают: в основном был ObjectDomain), конечно были далеки от идеала (угораздило Сановцев этот MVC использовать), но втыки скомпоилированных продуктов (GDPro и PowerDesigner) повергли меня в ужас: до 30 минут, конечно не доходило, но ждать 15 минут после File>Exit - такого ни одна Java-программа себе не позволит. А памяти сколько пожирали - ObjectDomain просто карликом кажется... Вот вам и распределение памяти вручную.

Так что мне, все-таки, кажется, что "революция по имени Жаба" произошла, хотя и не в той мере, как об этом кричали.