Кто нибудь встречал такую ошибку в центральном узле ?

все что видел в инете описано для подчиненного узла и не лечится само собой. А тут раз два в день появляется и исчезает со следующим обменом.

у меня узел центральный(1 из 5) и только от него получаю такую ошибку.

явно вижу что тэг <v8de:Digest2 v2="490478325d9db6322ebaa66796df8b3a">75fc24be3cc96725e8e5099172eed09f</v8de:Digest2> отличается от того что должен быть.

Появляется то где? В центральной базе? Тогда от какого узла?

написал неряшливо..
центральный узел. у него 5 подчиненных. от 1 из 5 получаю это сообщение.

Выгружаешь в него что-то без выгрузки изменений конфигурации

Делай новую почку

(0) конфигурация идентичная. никаких изменений в центре нет.

(4) сделал бы . если ошибка повторялась каждый раз.  а она пару раз в день только

(6) Значит какой то обмен с кривым файлом конфигурации прилетает

(7) я даже знаю где криво... написал в (0) тэг. только не пойму почему

(8) Может была где-то станция с такой же почкой. Что-то с ней случилось, поставили новую, выгрузили туда начальный образ. А прежнюю станцию с недавнего времени зачем то врубили и та, радостная начала слать свои файлы в центр

Что, серьёзно, само-проявляющая и само-исчезающая ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой" в центральном узле? :)

Ладно бы, в подчинённом. Можно было бы предложить, что в том "глюкающем" узле, сделали копию рабочей базы и они теперь обе периодически лезут в обмен...

Но в главном узле... О_О

В голову приходит только одна мысль: как ни странно это звучит, но база центрального узла периодически может быть подчинённой. Озадачил? :)

Ответ: если база периодически обменивается по другому плану обмена, где она подчинённая :))

(10) все реально, без Б.
шедулер запускает 1С , выдает файл . в нет тег не правильный. центр его читает и выдает ошибку.
через полчаса тот же шедулер выдает новый файл ион успешно прочитан центром.

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

(12) мысль дельная

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

<v8de:Digest2 v2="490478325d9db6322ebaa66796df8b3a">75fc24be3cc96725e8e5099172eed09f</v8de:Digest2>

хотелось бы понять в этом теге 490478325d9db6322ebaa66796df8b3a что есть такое...

Ан нет, допустимо. Если файлы сообщений не удаляются из каталога обмена, а перезаписываются со следующим обменом, то теоретически возможно. Кто последним перезаписал - того и тапочки :)

поменял пути.. продолжаем наблюдения

(15) как я понимаю, это так называемые внутренние идентификаторы конфигураций. Хотя не исключаю, что хэши. Старый и новый, после получения и принятия изменения конфигурации.

(18) есть описания в нете как лечить эту проблему в удаленном узле. там это называют "хеш".

Кстати, по поводу (15): посмотри есть ли в тексте сообщения обмена ключи типа "/v8md:Metadata". Если есть - поздравляю! :) Не знаю как, но ты получил в свой центральный узел изменение конфигурации от другого центрального узла :))

Впрочем - нет. Была бы ошибка типа "Изменения конфигурации не могут быть получены от подчинённого узла" :(

<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">;
                <v8de:Version>216.0</v8de:Version>
                <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
                <v8de:Digest2 v2="1883fd09d48778053832d043152fce85">a645a0ddf22d9b29acf73b0c515f4e84</v8de:Digest2>
            </v8de:Config>

целиком этот кусок .

это утром , с ошибкой.

<v8msg:Message xmlns:v8msg="http://v8.1c.ru/messages">;
    <v8msg:Header>
        <v8msg:ExchangePlan>ПоМагазину</v8msg:ExchangePlan>
        <v8msg:To>дд</v8msg:To>
        <v8msg:From>бо</v8msg:From>
        <v8msg:MessageNo>1373</v8msg:MessageNo>
        <v8msg:ReceivedNo>1525</v8msg:ReceivedNo>
    </v8msg:Header>
    <v8msg:Body>
        <v8de:Changes xmlns:v8="http://v8.1c.ru/data"; xmlns:v8de="http://v8.1c.ru/dataexchange/2005/02"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">;
            <v8de:Signature>083db94f-d53a-493f-b85e-e9bb9b18d864</v8de:Signature>
            <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">;
                <v8de:Version>216.0</v8de:Version>
                <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
                <v8de:Digest2 v2="1883fd09d48778053832d043152fce85">a645a0ddf22d9b29acf73b0c515f4e84</v8de:Digest2>
            </v8de:Config>


а это тот же узел , но в середине дня

<v8msg:Message xmlns:v8msg="http://v8.1c.ru/messages">;
    <v8msg:Header>
        <v8msg:ExchangePlan>ПоМагазину</v8msg:ExchangePlan>
        <v8msg:To>дд</v8msg:To>
        <v8msg:From>бо</v8msg:From>
        <v8msg:MessageNo>1421</v8msg:MessageNo>
        <v8msg:ReceivedNo>1547</v8msg:ReceivedNo>
    </v8msg:Header>
    <v8msg:Body>
        <v8de:Changes xmlns:v8="http://v8.1c.ru/data"; xmlns:v8de="http://v8.1c.ru/dataexchange/2005/02"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">;
            <v8de:Signature>083db94f-d53a-493f-b85e-e9bb9b18d864</v8de:Signature>
            <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">;
                <v8de:Version>216.0</v8de:Version>
                <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
                <v8de:Digest2 v2="490478325d9db6322ebaa66796df8b3a">a645a0ddf22d9b29acf73b0c515f4e84</v8de:Digest2>
            </v8de:Config>

Кэши, надеюсь, на том подчинённом узле уже были очищены при первом же подозрении на них и файлы из папок Config и ConfigSave удалялись?

(23) может какие деятели там сделали копию базы и на ней отлаживаются?

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

<v8msg:Message xmlns:v8msg="http://v8.1c.ru/messages">;
    <v8msg:Header>
        <v8msg:ExchangePlan>ОбменВРаспределеннойИнформационнойБазе</v8msg:ExchangePlan>
        <v8msg:To>01</v8msg:To>
        <v8msg:From>02</v8msg:From>
        <v8msg:MessageNo>1132</v8msg:MessageNo>
        <v8msg:ReceivedNo>1188</v8msg:ReceivedNo>
    </v8msg:Header>
    <v8msg:Body>
        <v8de:Changes xmlns:v8="http://v8.1c.ru/data"; xmlns:v8de="http://v8.1c.ru/dataexchange/2005/02"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">;
            <v8de:Signature>d95f474a-a3d6-4944-9abb-f6c18c95d728</v8de:Signature>
            <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">;
                <v8de:Version>216.0</v8de:Version>
                <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
                <v8de:Digest2 v2="e9e8b596739c44c6042b222b6b7af491">4b8884208cda89bd9739980f459f0d97</v8de:Digest2>
            </v8de:Config>
            <v8de:Data/>
        </v8de:Changes>
        <Parameters/>
    </v8msg:Body>
</v8msg:Message>

У тебя только в v8de:Digest2 видна проблема - "плывёт" идентификатор конфигурации. На практике я могу такого же эффекта добиться, подменяя конфигурацию в подчинённом узле... но это из области фантастики.

(0)
1.Отключить подчиненный от обмена
2.Выгрузить из центра .cf
3.Загрузить конфу в подчиненный
4.Подключить подчиненный к обмену
5.Сделать обмен заново

+(27)Если не поможет то наоброт - перенести конфу из подчиненного в центр.

Ну а пока, если без веры в чудеса :), то наиболее правдоподобна версия с копией рабочей базы, у которой не выключено выполнение регламентных заданий. (12) и (13), я надеюсь, мы эту версию отсеяли.

(24) чистилось конечно. но ошибка опять появилась

(29) тоже на это пеняю.
а еще смущает слово "хеш" из (18). не пойму что это такое вообще