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