МДБ и долговечность - PullRequest
       74

МДБ и долговечность

2 голосов
/ 02 августа 2011

Чтобы обеспечить долговечность, следует ли отделить сервер приложений, на котором развернут MDB, от JMS-провайдера (сервера), чтобы, если сервер приложений выключился и был перезапущен позже, MDB можно было отправлять сообщения что он пропустил, когда сервер приложений не работал?

Ответы [ 3 ]

2 голосов
/ 01 ноября 2012

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

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

В этом случае разделение JMS-провайдера может повысить вашу надежность, поскольку сервер, на котором работает только этот провайдер, может иметь меньший риск сбоя(меньше, более выделенная система, особенно без вашего собственного кода = меньше вероятность сбоя) и может функционировать в качестве буфера для тех ситуаций, когда вам нужно перезапустить сервер приложений.С другой стороны, с каждым сервером вы увеличиваете вероятность того, что по крайней мере один из них выйдет из строя, увеличивается и вероятность того, что вы допустили ошибку конфигурации где-то.Это компромисс, который вы должны сделать сами.

0 голосов
/ 02 августа 2011

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

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

В этом случае разделение JMS-провайдера может повысить вашу надежность, поскольку сервер, на котором работает только этот провайдер, может иметь меньший риск сбоя(меньше, более выделенная система, особенно без вашего собственного кода = меньше вероятность сбоя) и может функционировать в качестве буфера для тех ситуаций, когда вам нужно перезапустить сервер приложений.С другой стороны, с каждым сервером вы увеличиваете вероятность того, что по крайней мере один из них выйдет из строя, увеличивается и вероятность того, что вы допустили ошибку конфигурации где-то.Это компромисс, который вы должны сделать сами.

0 голосов
/ 02 августа 2011

Я бы сказал, да. Одним из вариантов может быть развертывание автономного HornetQ:

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636

Таким образом, вам не нужно развертывать полнофункциональный сервер JBoss, что экономит деньги за счет снижения характеристик ваших хостов. Объем памяти HornetQ в автономном режиме может быть очень низким.

Если разделение JMS-брокера и MDB-клиента не подходит, то, как я однажды сделал это, разработал кеш в клиенте, который хранит неотправленные сообщения, так что, если сервер не работает, он сохраняет сообщения до тех пор, пока JBoss снова не включится. 1008 *

...