Поделитесь опытом работы с распределёнкой

[Klido]

Сложность: надо держать отдельный справочник с именами "домашних" серверов для каждого пользователя.

родной почтовый сервак прописан в документе юзера, так что надо иметь справочник серверов с репликой-соответствие почтовому серверу

не вижу вот почему надо ещё усложнять: агент в приложении, соответствие реплика-почтовый сервер тут же, как уведомления делать - мининастройки тут же, обрабатываем пришедший по реплике док, проверяем кому слать (разворачиваем группы и пр.)-смотрим его родной сервак-проверяем та ли реплика и шлем/не шлем

 

[TIA]

не вижу вот почему надо ещё усложнять

Прежде чем ответить на вопрос о необходимости дополнительного справочника, надо ответить на вопросы:
1.Всегда ли можно агенты запускать на всех почтовых серверах пользователей?
2.Если нет, могут ли почтовые сервера пользователей и сервера, где работают агенты быть "доверенными" (Trusted) и всегда доступными агентам других серверов?

Про "проверку реплики" не понял что имеется в виду.

 

[Klido]

1.Всегда ли можно агенты запускать на всех почтовых серверах пользователей?

агент запускается на сервере приложения, отношение которого к почтовому серверу определяется настройками, на серверах приложений, очевидно, запускать агенты, подписанные сервером - можно

2.Если нет, могут ли почтовые сервера пользователей и сервера, где работают агенты быть "доверенными" (Trusted) и всегда доступными агентам других серверов?

мы же говорим про одну организацию, а не мульти-кросс-домен?

Про "проверку реплики" не понял что имеется в виду.

ммм... агент запускается и проверяет на каком сервере(в какой реплике ) он запущен, смотрит в справочник и видит какой почтовый сервер соответствует данной реплике, строим список для уведомления и отправляем тем, у кого в списке почтовый сервер указан тот, что надо

 

[ToxaRat]

ммм... агент запускается и проверяет на каком сервере(в какой реплике ) он запущен, смотрит в справочник и видит какой почтовый сервер соответствует данной реплике, строим список для уведомления и отправляем тем, у кого в списке почтовый сервер указан тот, что надо

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

 

[TIA]

агент запускается на сервере приложения, отношение которого к почтовому серверу определяется настройками, на серверах приложений, очевидно, запускать агенты, подписанные сервером - можно

мы же говорим про одну организацию, а не мульти-кросс-домен?

Ничего это не значит. В одной организации могут быть удалённые площадки (набор серверов), соединение с которыми по очень узким каналам, диалапные или вообще фельдегерьская через сидюки Т.о. агенты, работающие на одной полощадке, могут не иметь прямого доступа к серверам другой.

ммм... агент запускается и проверяет на каком сервере(в какой реплике smile.gif) он запущен, смотрит в справочник и видит какой почтовый сервер соответствует данной реплике, строим список для уведомления и отправляем тем, у кого в списке почтовый сервер указан тот, что надо

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

 

[Klido]

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

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

Такие сервера могут быть разными в общем случае

???
У пользователя 1 почтовый сервер, которому соответствует 1 сервер с репликой. Какие гарантии ещё нужны???
в общем случае правило "ближайший доступный" ставит в соответствие почта-приложение...
это даже достаточно норм работает, если юзеры ездят по миру и им меняют почтовые сервера - они каждый раз получают уведомления из правильной реплики приложения...

 

[TIA]

(вернее - в каждой на каждом)

Вы уж определитесь. Теперь на каждом, а то было

агент запускается на сервере приложения, отношение которого к почтовому серверу определяется настройками

Две большие разницы. Т.к. отношения бывают уже не только "1 к 1", а и "1 к N" и т.д.

или я не понимаю в чем вопрос про взаимную трастовость и доступность серверов?

Я уже говорил про это. Трастовость нужна когда агент работает на сервере отличном от того, где работает с БД пользователь. Для того, чтобы проверить, дореплицировался ли именно туда документ. Иначе, пользователь опять получит уведомление, указывающее на документ которого ещё нет в его реплике, или к которому ещё не предоставлен доступ.

у пользователя 1 почтовый сервер, которому соответствует 1 сервер с репликой.

Слишком жёсткое требование, но если у вас так, то задача упрощается. Чаще отношение 1 пользователь к N серверам. Особенно при наличии кластера, но с ним проблема доставки документа меньше.

 

[Klido]

TIA

Вы уж определитесь.

да просто выхватываем из контекста

есть сервер приложения, на нем - реплика, в каждой реплике агент, который запускается на каждом сервере=в каждой реплике

про случай 1 к N - это ж и было в начале топика: как уйти от проблемы.

с помощью таблички серверов почтовый-приложения всегда определяем когда отправлять уведомление

Чаще отношение 1 пользователь к N серверам

вопрос: зачем пользователю, сидящему на 1 почтовом сервере работать с N репликами приложений хз где?

Особенно при наличии кластера, но с ним проблема доставки документа меньше.

ответ на предыдущий вопрос с кластером в теории уведомления не вызовут проблем... хотя приложения в кластере меня всегда напрягали...

Добавлено: в конце концов траблы с уведомлениями такая мелочь по сравнению с конфликтами, блокировками да и самой репликацией в распределенных приложениях, понятно...

 

[nvyush]

По ходу дискуссии решил "выделать овчинку" и реализовать таки рассылку уведомлений после репликации. Вариант с одной базой уведомлений мне понравился больше, чем реализация данного механизма во всех базах.
Вопрос знатокам — группы лучше разворачивать до или после репликации? Если до — растёт объём репликации уведомлений, если после — группы будут разворачиваться агентами на каждом сервере.

 

[TIA]

вопрос: зачем пользователю, сидящему на 1 почтовом сервере работать с N репликами приложений хз где?

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

И кстати, почтовый сервер пользователя с точки зрения сервера (прописанный в серверной адресной книге), это не тоже самое, что сервер, где пользователь открывает почту. В его локейшене может быть указан другой сервер, где имеется реплика почтовой БД.

 

[Klido]

необязательно один из них является почтовым сервером пользователя.

более того - скорее обязательно НЕ является

пользователи одного и того же почтового сервера могут работать с разными серверами приложений

серверами ДА, с разными репликами - считаю неправильным... в тяжелом случае всё равно желательно сохранять соответствие "текущий почтовый сервер-сервер реплики N"

он у уж наверняка будет переключаться на реплику текущей площадки, чтоб работало быстрее

угу+на почтовый же сервер...

И кстати, почтовый сервер пользователя с точки зрения сервера (прописанный в серверной адресной книге), это не тоже самое, что сервер, где пользователь открывает почту. В его локейшене может быть указан другой сервер, где имеется реплика почтовой БД.

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

Мы говорим о достижении гармонии или о случаях бардака с мечущимися по миру пользователями? В движении либо админу надо будет менять почтовый сервер пользователя - чтобы он быстрее получал почту в нужном месте, либо пользователю постоянно переключать локейшены, а без локальной реплики - ещё и ждать репликации почты.

Задача у нас послать уведомление с условием, что линк в уведомлении гарантировано есть в любимой реплике пользователя. Если решать для всех реплик - тогда и ждать надо ВСЕХ репликации.

 

[VladSh]

Вопрос знатокам — группы лучше разворачивать до или после репликации? Если до — растёт объём репликации уведомлений, если после — группы будут разворачиваться агентами на каждом сервере.

Не пойму, зачем какое-то группы?..
При отправке есть список пользователей, из него определяем, что всего по этой отправке необходима доставка, допустим, на 3 сервера. Для каждого сервера создаём свой запрос на отправку письма, в котором находятся только те пользователи, у которых мыло лежит на этом сервере. При репликации агент подхватывает запрос (к примеру, раз в 5 минут), ищет по нему базовый документ и проверяет его "доступность" для выполнения отправки; если док доступен, письма отправляются. Всё.
Это частный случай, вырванный из контекста общего механизма, всё гораздо веселее..

 

[TIA]

ищет по нему базовый документ и проверяет его "доступность" для выполнения отправки; если док доступен, письма отправляются

Во, это ближе к рабочему варианту. Важное отличие от предлагаемого ранее -- наличие проверки "доступности". Т.е. что модификация документа, соответствующая уведомлению дореплицировалась до сервера адресата.

Не пойму, зачем какое-то группы?.. При отправке есть список пользователей,

А группы надо разворачивать как раз чтобы получить список пользователей. Группы были по условию задачи.

 

[VladSh]

Во, это ближе к рабочему варианту. Важное отличие от предлагаемого ранее -- наличие проверки "доступности". Т.е. что модификация документа, соответствующая уведомлению дореплицировалась до сервера адресата.

Более того - это единственное железно работающее решение, т.к. пытаться "управлять репликацией" с помощью порядка реплицирования или приоритетами - это бабка надвое сказала, т.к. репликация основной БД может затупить, а БД с запросами отреплицируется полностью.. Порядок реплицирования и приоритеты - это конечно нужное дело, но не достаточное.

А группы надо разворачивать как раз чтобы получить список пользователей. Группы были по условию задачи.

Я думал, что условия задачи в начальном сообщении от Gor

 

[TIA]

Я думал, что условия задачи в начальном сообщении от Gor

Тут уже около трёх параллельно обсуждаемых веток обсуждений. Группы начались с link removed

 

[nvyush]

Во, это ближе к рабочему варианту. Важное отличие от предлагаемого ранее -- наличие проверки "доступности". Т.е. что модификация документа, соответствующая уведомлению дореплицировалась до сервера адресата.

Более того - это единственное железно работающее решение, т.к. пытаться "управлять репликацией" с помощью порядка реплицирования или приоритетами - это бабка надвое сказала, т.к. репликация основной БД может затупить, а БД с запросами отреплицируется полностью.. Порядок реплицирования и приоритеты - это конечно нужное дело, но не достаточное.

По ходу дела речь шла об агенте After documents are created or modified. Ситуация: уведомление среплицировалось, а документ — нет. Агент сработал на поступление уведомления, проверка показала отсутствие документа, сообщения не шлём. Затем документ среплицировался... Получается нужен второй агент по расписанию, который бы "подчищал" работу первого и посылал сообщения при обгоне документов уведомлениями.

 

[Klido]

вот я всё-таки не пойму зачем ещё реплицировать уведомления??? их же можно создать в нужный момент...
агент проверяет лишь приезд дока по репликации и если надо - генерит уведомление...

 

[TIA]

вот я всё-таки не пойму зачем ещё реплицировать уведомления

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

 

[nvyush]

вот я всё-таки не пойму зачем ещё реплицировать уведомления??? их же можно создать в нужный момент...
агент проверяет лишь приезд дока по репликации и если надо - генерит уведомление...

Тут обсуждаются два варианта.
Вариант 1: агент в базе документов по факту репликации документа шлёт сообщения пользователям. Недостаток: в каждой базе документов должен быть свой агент.
Вариант 2: есть служебная база уведомлений, реплицируемая в последнюю очередь. При добавлении/изменении документа в неё кладётся уведомление. Агент в базе уведомлений по факту репликации уведомления шлёт сообщения пользователям. Достоинства: единый механизм для всех баз документов. Недостаток: возможны "обгоны" документов уведомлениями.

 

[Klido]

ну как-то в контексте темы, с чего началось...

Итак, как только Вася одобрил заявку, Коля получил почтовое уведомление о том что ему пришёл новый документ на одобрение, НО
как только он пытается его открыть система ругается что прав на редактирование у него нет, т.к. Лотусовые базы ещё не среплицировались.

слова

Недостаток: возможны "обгоны" документов уведомлениями.

как раз не дают нам гарантированного решения...

с учетом

При добавлении/изменении документа в неё кладётся уведомление.

получаем что нет разницы - то ли в базе свой агент, то ли код создания уведомления...

поэтому я вот и думаю - зачем усложнять в 2 разак особо не получая выигрыша?