Случайная ошибка на рабочем сервере: метод ‹имя› не поддерживается на этом прокси

Один из 4 производственных серверов время от времени генерирует массу ошибок, утверждая:

Метод RunRules не поддерживается на этом прокси, это может произойти, если метод не помечен атрибутом OperationContractAttribute или если тип интерфейса не помечен атрибутом ServiceContractAttribute.

Метод «RunRules» является одним из методов интерфейса wcf [ServiceContract] и помечен как [OperationContract].

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

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

Для меня это почти как поврежденная vtable. Просто интересно, как бы вы подошли к этой проблеме? Ненавижу просить ИТ-специалистов начать воссоздавать образ машины без веских доказательств.

Спасибо!


production wcf castle-windsor wcffacility
person Zhen.Lee    schedule 26.08.2010    source источник
comment
вы нашли решение этой проблемы? у нас очень похожая проблема.   -  person Kostassoid    schedule 18.04.2012
comment
У меня такая же ошибка при использовании замка wcf. перезапуск веб-сайта в IIS исправляет это для меня. Но я также хотел бы получить ответ.   -  person Aran Mulholland    schedule 18.04.2012
comment
Как вы регистрируете свои услуги на клиенте?   -  person Aran Mulholland    schedule 18.04.2012
comment
Я также получил эту ошибку, имея IIS на моей локальной машине и выполняя сборку из визуальной студии. Это когда мне нужно перезапустить веб-сайт в IIS, кажется, он перепутался. @Kostassoid, ты нашел решение?   -  person Aran Mulholland    schedule 20.04.2012
comment
@AranMulholland: еще нет. мы так же, как и вы, подумали, что нам пришлось перезапустить пул приложений, чтобы он снова заработал. но это произошло только один раз, поэтому у нас нет никакой статистики. Единственная интересная вещь заключается в том, что у нас есть WCF на основе iis и Windows-сервисов, и только прокси-серверы на основе IIS потерпели неудачу.   -  person Kostassoid    schedule 20.04.2012
comment
Просто для уточнения. До этой ошибки в том же методе иногда получалась неправильная служба через контейнер замка. Вы используете средство интеграции WCF с замком (используя WindsorServiceHostFactory)? Является ли эта служба чистой (без DI-контейнеров и т. д.)?   -  person Petar Vučetin    schedule 23.04.2012
comment
@PetarVucetin Когда мы получаем эту ошибку, мы используем WindsorSevcieHostFactory на стороне службы, а также используем средство wcf для разрешения служб на стороне клиента.   -  person Aran Mulholland    schedule 23.04.2012
comment
Это был бы мой главный подозреваемый.   -  person Petar Vučetin    schedule 23.04.2012

Ответы (1)


arrow_upward
0
arrow_downward

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

// use this in loop incrementing levelIndex up to st.FrameCount
// to grab all possible callstack entries
StackTrace st = new StackTrace();
st.GetFrame(levelIndex).GetMethod().Name;

Затем с помощью такой утилиты, как ILSpy, разберите Castle DLL и попробуйте проанализировать, какое состояние вызывает конкретный поток выполнения, который заканчивается исключением, которое вы получили.

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

person sll    schedule 23.04.2012