TIBCO Обработка отказа EMS снова соединяются для C# (TIBCO.EMS.dll)
У вас есть поток входа в систему, и вы сохраняете пользовательский токен в localStorage как ключ usertoken. Вы также убедились, что ваши запросы обрабатываются правильно, если установлен заголовок авторизации.
Самый простой способ работать с запросами API - это немного больше абстрагироваться от axios, автоматически добавлять токен авторизации и, возможно, предварительно обрабатывать полученный ответ. Например, вы можете захотеть обрабатывать некоторые ошибки глобально, а не в каждом конкретном случае, или хотите преобразовать запрос во что-то, что всегда одинаково.
Сначала вы хотите создать абстракцию, которая вызывает axios.request. Вы можете передать ему объект конфигурации, как описано здесь здесь . Сейчас для вас важнее всего пара «ключ-значение» headers, но вы можете расширить ее в будущем.
export default request (config) {
const userToken = window.localStorage.getItem('usertoken');
const requestConfig = { ...config };
if (!requestConfig.headers) {
requestConfig.headers = {};
}
if (userToken) {
requestConfig.headers.authorization = `Bearer ${userToken}`;
}
return axios.request(requestConfig);
}
Теперь мы можем расширить это:
export default post (url, data = {}, config = {}) {
return request({
...config,
method: 'POST'
url,
data
});
}
При проверке запроса в консоли разработчика вы должны увидеть, что, если токен пользователя правильно задан в localStorage, у вас есть дополнительный заголовок в вашем запросе, который отправляется на сервер.
3 ответа
Это сообщение должно подвести итог моих текущих комментариев и объяснить мой подход более подробно...
TIBCO 'ConnectionFactory' и типы 'Соединения' являются тяжелыми, ориентированными на многопотоковое исполнение типами. TIBCO предлагает, чтобы Вы поддержали использование одного ConnectionFactory (на настроенную фабрику сервера) и одно Соединение на фабрику.
Сервер также, кажется, ответственен за оперативную обработку отказа 'Соединения' и повторное соединение, поэтому давайте подтвердим, что это делает свое задание, и затем облокотитесь на ту функцию.
Создание клиентского решения будет немного более включенным, чем фиксация сервера или клиентской проблемы установки. Все сессии, которые Вы создали из неудавшегося соединения, должны быть воссозданы (не говоря уже о производителях, потребителях и местах назначения). Существуют, не "повторно подключают" или "обновляют" методы на любом типе. Сессии не поддерживают ссылку на свое родительское соединение также.
Необходимо будет справиться с поиском объектов соединения/сессии и сойти с ума, повторно инициализируя всех! или реализуйте своего рода обработчик событий отказа сессии, который может получить новое соединение и повторно подключить их.
Так, на данный момент давайте закопаем и посмотрим, является ли клиент установкой для получения уведомления об обработке отказа (ТиБ, пользователи Эмса ведут pg 292). И удостоверьтесь, что повышенное исключение поймано, содержит URL обработки отказа и обрабатывается правильно.
Прежде всего, да, я отвечаю на свой собственный вопрос. Его важное для примечания, однако, что без ajmastrean, я нигде не был бы. огромное спасибо!
ОДИН: ConnectionFactory. SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout должен быть установлен соответственно. Я думаю повторная попытка значений по умолчанию слишком быстро (на порядке 1/2 секунды между повторениями). Наши серверы EMS могут занять много времени к обработке отказа из-за сетевого устройства хранения данных, и т.д. - таким образом, 5 повторений в 1/2s интервалах нигде не рядом достаточно долги.
ДВА: Я полагаю, что его важное включает heartbeat клиент-сервер и heartbeat клиента сервера. Не смог проверить, но без тех на месте, клиент не мог бы получить уведомление, что сервер в режиме офлайн или переключается в режим обработки отказа. Это, конечно, является серверной установкой для EMS.
ТРИ: можно наблюдать за событием обработки отказа установкой Tibems. (Верный) SetExceptionOnFTSwitch; и затем обеспечивая электричеством обработчик событий исключения. Когда в единственной серверной среде, Вы будете видеть, что "Соединение было завершено" сообщение. Однако, если Вы будете в отказоустойчивой мультисерверной среде, то Вы будете видеть это: "Соединение выполнило отказоустойчивый переключатель к". Вам строго не нужно это уведомление, но это может быть полезно (особенно в тестировании).
ЧЕТЫРЕ: По-видимому, не ясный в документации EMS, соединение снова соединяется, НЕ будет работать в единственной серверной среде. Необходимо быть в мультисервере, отказоустойчивой среде. Существует прием, как бы то ни было. Можно поместить тот же сервер в список соединения дважды - странный, я знаю, но он работает, и он включает встроенное, повторно подключают логику для работы.
некоторый код:
private void initEMS()
{
Tibems.SetExceptionOnFTSwitch(true);
_ConnectionFactory = new TIBCO.EMS.TopicConnectionFactory(<server>);
_ConnectionFactory.SetReconnAttemptCount(30); // 30retries
_ConnectionFactory.SetReconnAttemptDelay(120000); // 2minutes
_ConnectionFactory.SetReconnAttemptTimeout(2000); // 2seconds
_Connection = _ConnectionFactory.CreateTopicConnectionM(<username>, <password>);
_Connection.ExceptionHandler += new EMSExceptionHandler(_Connection_ExceptionHandler);
}
private void _Connection_ExceptionHandler(object sender, EMSExceptionEventArgs args)
{
EMSException e = args.Exception;
// args.Exception = "Connection has been terminated" -- single server failure
// args.Exception = "Connection has performed fault-tolerant switch to <server url>" -- fault-tolerant multi-server
MessageBox.Show(e.ToString());
}
Клиентские приложения могут получить уведомление об обработке отказа путем установки tibco.tibjms.ft.switch.exception системного свойства
Возможно, потребности библиотеки это для работы?