Доброго времени суток всем!
при разработке некоего приложения (не бизнес), встала некотарая проблемма. а именно - обмен сообщениями между модулями (условное деление).
Обе стороны могут являться как генераторами сообщений, так и приемниками сообщений. последовательность сообщений важна.
Начал прорабатывать структуру для реализации и пока выстроилась следующая - есть некая очередь сообщений (возможно несколько).
Есть поставщики сообщений в очередь - собственно источники сообщений.
Есть соотв. слушатели, есть диспетчер. слушатели после соотв. регистраци начинают получать сообщения тех типов на которые они подписались при регистрации и соотв. их обрабатывать. Все-б хорошо. 

Но проблемма кроется в колл-ве сообщений. На сегодня оценка - до 200-500 сообщений в секунду. 
Очередь кольцевая (размер настраиваемый) и не обработанные но уже устаревшие сообщения не имеют ценности и будут удалены из очереди диспетчером и уничтожены. так что проблеммы размера очереди не актуальны.
Что заставило написать вопрос - если я начну с такой скоростъю создавать экземпляры классов сообщений и помещать их в очередь, откуда соотв. они будут распространяться слушателями и соотв. убираться из очереди при нужном критерии (завершение обработки сообщения, устаревания, или его передача на исполнение) - то у меня возникает подозрение что:

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

п.п 2 меня как раз более всего и интересует и волнует.
Есть идея заранее распределить память под очередь и экземплары класса сосбщения и использовать оные только в рамках уже созданных (нет создания новых и освобождения ). Но сообщения все разнотипные и теряется куча возможностей языка вообще.
Есть идея делать как в RMI или Корбе - маршалировать сообщения в транспортный формат с посл. разборкой их на стороне слушателя. в таком случае можно и иметь преимущества классов и наследования и иметь фикс. кусок памяти на каждое сообщение и не заниматься их созданием, удалением. но тут возникают естественно накладные на преобразованиях (ну скажем в XML ).


А какие подходы еще известны для подобного обмена? Как правильнее подойти к этой проблемме?
Спасибо большое!

PS: ногами не пинать. я не профи.

Операция new для большинства классов довольно быстрая, и gc по молодому поколению работает очень быстро в JVM от Sun Microsystems, так что не напрягайтесь на этот счет.

Это сообщение отредактировал(а) MaxPayneC - 13.1.2010, 18:52

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

Да, я тоже хотел посоветовать apache MQ. Пусть их реализация сама занимается потоком и нагрузкой, она для этого писалась, ее испольуют в ентрпрайз уровне, почему бы и вам не использовать. 

сорри.
не понял.
1.есть скорость образования мессагов. и соотв. резервирования ресурсов (память). потребление производит алгоритм приложения
2.есть скорость обработки мессагов (не важно кем и как)
3. есть скорость высвобождения ресурсов (память). освобождение производит алгоритм приложения _и_ gc в конце концов.

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

не хочется попасть в ситуацию когда на 1 проце стареньком каком-то скорость потребления ресурсов будет превышать скорость их высвобождения - в результате не успевания _не_ алгоритмов приложения, а не достаточной скорострельности gc ... в таком случае постепенно (минута, час, день, неделя, и т.д. но ведь будет!) будет осуществлен выход приложения за пределы выделенного VM размера памяти.
какая разница как реализована обработка очереди и где - важна скорость появления и уничтожения экземпляров ... в конце концов очередь может содержать всего скажем 10 элементов, где и как они будут обрабатываться - не важно, даже не важно будут ли они успевать обрабатываться - может и их потебителей то в данный момент не будет вообще. но вот появляться и уничтожатся по кольцу очереди сообщения будут с высокой скоростъю . вот тут я и боюсь ..
Я возможно что-то не понял?.

Если приложение само генерирует обьекты, то во время "уборки" освобожденных обьектов новые не будут создаваться. Аналогично, если приложение получает обьекты из сети, то оно не будет их читать из сетевого соединения во время уборки. Поэтому режим full gc иногда называют "stop the world". Иными словами, приложение просто замедляет свою работу при нехватке ресурсов. А пресловутый "выход приложения за пределы выделенного VM размера памяти" есть обычно результат "утечки" памяти и это ответственность программиста не допустить ее.

Что же касается идеи не создавать всякий раз новые обьекты, а повторно использовать обьекты из хранилища, то обычно рекомендуют это делать в крайнем случае. Считается, что в большинстве случаев эффективнее создавать/удалять.


Это сообщение отредактировал(а) COVD - 13.1.2010, 22:11

не проверил .
написал простейший тест, проверил. использовал в качестве контайнера очереди ConcurrentLinkedQueue. по кругу.
Достиг без включения задержек где-то около 3е6 мессагов в секунду (при размере очереди в 1000 элементов) (отдельный поток)
.....
AVG Msg to sec:3117774.193548387 ccc:96651000 ddt/1000:31 ql.size():1001
AVG Msg to sec:3117548.3870967743 ccc:96644000 ddt/1000:31 ql.size():1001
AVG Msg to sec:3123967.7419354836 ccc:96843000 ddt/1000:31 ql.size():1001
.....


памяти достиг (не сразу, но быстро) ~17.6М (конечно это при моих конкр. мессагах всего лищь 2-х классов и т.д. и т.п. конкретного приложения). и память больше не растет (уже 20 мин.). Что не может не радовать.
А получается действительно есть механизм, который как-то следит и действительно тормозит все потоки при некотором критерии пока не почистит хвосты.
хорошо. .
Спасибо всем еще раз!

Так называемые микротесты для приложений на java очень редко позволяют оценить реальную производительность приложения, по двум причинам: компилятор сильно оптимизирует код, и скорее всего ненужные операции он "спалит" и не будет выполнять в действительности. Вторая причина в том, что JVM скомпилирует часто вызываемый код, дабы ускорить его работу, после определенного числа его вызовов.

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