Кластеризация не работает - PullRequest
2 голосов
/ 15 апреля 2011

Я настраиваю кластеризацию для двух котов, используя apache спереди и mod_jk в качестве соединителя. Я попробовал тестовое приложение, чтобы проверить конфигурацию, и она работает нормально. Сеанс успешно реплицируется, и аварийное переключение обнаружено успешно. Но когда я попробовал это для моего реального приложения, это не работает. Я сделал изменения в httpd.conf соответственно и очень осторожно. Нет исключений, нет ошибок в журналах. Я не могу отследить проблему. Первоначально я получал NotSerializableException для определенных классов, и я сделал их сериализуемыми. Теперь нет никаких исключений, но я все еще не могу загрузить приложение, если tomcat хостинга выключен, даже когда другой член tomcat кластера жив. Ребята, пожалуйста, помогите мне. Я понимаю, что довольно сложно найти решение, если вы не уверены в проблеме.

1 Ответ

4 голосов
/ 25 апреля 2011

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

Существует общее правило, когда вы видите что-то, что выглядит невозможным. И это правило таково, что вы не видите того, что, как вы думаете, вы видите. Часто из-за того, что в шутку называют PEBKAC (проблема существует между клавиатурой и стулом). Действительно разочаровывает то, что, независимо от того, насколько это очевидно, вы можете смотреть на это 100 раз, и это не будет очевидно, потому что вы видите, что вы «знаете», а не то, что есть.

По моему опыту, есть два хороших способа решить эту проблему.

  1. Отнесите это кому-нибудь еще и попросите его найти то, что вы делаете по-другому. Учитывая, что они видят то, что есть, а не то, что вы «знаете», они часто видят то, что вы не можете. (Через некоторое время вы сможете вернуть услугу когда-нибудь.)
  2. Начните с рабочей и нерабочей конфигураций и начните разделять путь между ними до тех пор, пока не получите минимальную разницу, которая говорит о разнице между рабочей и нерабочей. Уменьшите эту разницу, и вы либо будете знать, что исправить, либо у вас будет контрольный пример, чтобы дать кому-то еще.

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

Предполагая, что у вас есть тестовая система, сохраните эту конфигурацию. Затем начните извлекать большие куски вашего реального приложения, которые, по вашему мнению, не имеют ничего общего с проблемами конфигурации, периодически проверяя, что вы на правильном пути. (И сохраняйте каждый раз, когда вы есть.) Когда у вас есть минимальное приложение, начните пытаться приблизить его к работающему тестовому приложению. Где-то вы найдете изменения, которые имеют значение. Это может быть где угодно. Как только вы найдете его, вы, как правило, будете точно знать, как исправить вашу производственную систему. Или, если вы этого не сделаете, вы будете достаточно ясно знать свою проблему.

Иногда вы находите странную ошибку. Если это так, то вам следует начать пытаться максимально упростить все, пока у вас не появится хороший отчет об ошибке для отправки.

...