МБР и долговечность
Чтобы обеспечить долговечность, следует ли отделить сервер приложений, на котором развернут MDB, от поставщика JMS (сервера), чтобы, если сервер приложений завершит работу и будет перезапущен позже, MDB можно было отправить сообщения, которые он пропустил во время работы сервера приложений?
3 ответа:
Я бы сказал, Да. Одним из вариантов может быть развертывание hornetq standalone:
Http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636
Таким образом, вам не нужно развертывать полнофункциональный сервер JBoss, экономя некоторые деньги за счет сокращения спецификаций хостов. Объем памяти HornetQ в автономном режиме может быть очень низким.
Если разделение брокера jms и клиента MDB не является вариантом, то я сделал это однажды, разрабатывая кэш в клиент, который хранит неотправленные сообщения, так что если сервер не работает, он хранит сообщения до тех пор, пока JBoss снова не будет включен.
Но если сервер никогда не принимал сообщение (потому что оно тоже было отключено), клиент не может думать, что все в порядке, и поэтому никакие сообщения не будут таинственно пропущены.
Более практично, однако, свойство долговечности действительно предполагает одну тему, к которой прислушиваются несколько удаленных клиентов. Если ваша настройка такова, что у вас уже было несколько слушателей на разных удаленных серверах для темы, я думаю, вы не задавали бы этот вопрос. Так что я предполагаю, что у вас есть ваши MDB (ы) все развернуты на одном сервере.В этом случае разделение поставщика JMS может повысить вашу надежность, так как сервер, работающий только с этим поставщиком, может иметь меньший риск сбоя (меньшая более выделенная система, особенно без вашего собственного кода = меньше вероятность сбоя) и может функционировать в качестве буфера для тех ситуаций, когда вам нужно перезапустить сервер приложений. С другой стороны, с каждым сервером вы добавляете вероятность того, что хотя бы один из них выйдет из строя, и возможность то, что вы где-то делаете ошибку конфигурации, также увеличивается. Это компромисс, который вы должны сделать сами.
Свойство долговечности больше предназначено для тех ситуаций, когда клиент думает, что все в порядке, так как тема сервера приняла сообщение, но тогда оно не может быть доставлено всем предполагаемым получателям, так как один или несколько из них были отключены.
Но если сервер никогда не принимал сообщение (потому что оно тоже было отключено), клиент не может думать, что все в порядке, и поэтому никакие сообщения не будут таинственно пропущены.
Более практично, однако, долговечность свойство действительно предполагает одну тему, к которой прислушиваются несколько удаленных клиентов. Если ваша настройка такова, что у вас уже было несколько слушателей на разных удаленных серверах для темы, я думаю, вы не задавали бы этот вопрос. Поэтому я предполагаю, что все ваши MDB(Ы) развернуты на одном сервере.
В этом случае разделение поставщика JMS может повысить вашу надежность, так как сервер, работающий только с этим поставщиком, может иметь меньший риск сбоя (меньшая более выделенная система, особенно без вашего собственного кода = меньше вероятность сбоя) и может функционировать в качестве буфера для тех ситуаций, когда вам нужно перезапустить сервер приложений. С другой стороны, с каждым сервером вы добавляете вероятность того, что хотя бы один из них аварийно завершит работу, и вероятность того, что вы где-то допустите ошибку конфигурации, также увеличивается. Это компромисс, который вы должны сделать сами.