Предистория:

Согласно RFC-2616, HTTP header можно передавать кучей разных способов.
Мы использовали вариант КЛЮЧ = <ЗНАЧЕНИЕ-1>,<ЗНАЧЕНИЕ-2>,...,<ЗНАЧЕНИЕ-N>
Библиотека Apache CXF до версии 2.5.8 (включительно) обрабатывала такую ситуацию корректно.

Проблема:

С версии 2.5.9 Apache CXF втихаря «улучшились» и допустимыми признают только КЛЮЧ = <ЗНАЧЕНИЕ>
Ни в документации, ни на форуме апача нет ответа на вопрос:

Как разрешить Apache CXF принимать параметры заголовка HTTP-запроса (HTTP header) через запятую?

Исследование исходных кодов библиотеки указало на решение проблемы.

Решение:

В конфиге beans.xml надо добавить:

<jaxrs:properties>
     <!-- enable comma separated HTTP header values. Example" "X-ListID: 0,100,13,25,16" -->
     <entry key="org.apache.cxf.http.header.split" value="true" />
</jaxrs:properties>

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

Первоначальная эйфория и «Ухты!»-эффект проходят.

Проводя уже около 6 лет собеседования с Java-разработчиками заметил, что из приходивших кандидатов вообще никто не знает, что можно штатными средствами JDK удалённо мониторить состояние JVM с контейнерами сервлетов.
Поэтому далее пошаговый рецепт, как настроить и использовать эту замечательную возможность

С 9.0 версии PostgreSQL есть встроенный механизм Master-Slave репликации (streaming replication).
Однако, с его появлением выбрасывать старые триггерные механизмы не следует.

В общем случае, если нам требуется нечто большее, чем одна абсолютно точная копия всего DB-сервера, то триггеры остаются с нами.

Примеры таких ситуаций:

• Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).
• Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
• В проекте приходится использовать продуктовый «зоопарк» — т.е. Master и Slave имеют по какой-то причине разные версии, или же версии одинаковые, но ОС разной «битности».
• В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
• Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.

Добавляйте в комментариях дополнительные варианты.

Примечание: Возможность построения failover задекларирована месяц назад в версии 9.1 под названием «Synchronous Replication». Однако, лично я пока ещё эксперименты не проводил.

Когда начинается разговор об IAAS (упрощенно — виртуализации серверов), то сразу же звучат мантры "VMware, Hyper-V, XEN, OpenVZ/Virtuozzo, KVM, Jail".
Каждая из этих технологий имеет своих апологетов, имеет свои положительные и, разумеется, отрицательные стороны. Принципиально, все решения можно разделить на 2 группы по потребительским свойствам:

• контейнерная виртуализация (на уровне операционной системы) — какая операционная система используется в физическом сервере — такие виртуальные машины можно в ней и создавать (Linux-Linux, Windows-Windows, xBSD-xBSD) — гомогенная виртуализация
• аппаратная виртуализация и паравиртуализация — на физическом сервере с одной операционной системой можно создавать виртуальные машины с иными ОС (Linux-Linux, Linux-Windows, Linux-xBSD, Windows-Linux, Windows-Windows ...) — гетерогенная виртуализация

Однако, в нашей отрасли, редко кто вспоминает о существовании очень интересного решения — Parallels Server Bare Metall.