Где перехватить неудачное соединение в вызывающем классе WCF?

Джефф, из вашего вопроса я не совсем уверен, как вы имитируете сбой соединения. Я предполагаю, что «как будто сервер не отвечает» означает, что вы ищете какую-то ошибку тайм-аута. Вероятно, вы имитируете неотзывчивый сервер, заставляя медленный ответ от вашего вызова службы с помощью Thread.Sleep () на стороне сервера. Правильно? Достаточно близко?

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

Чтобы пояснить, тайм-ауты WCF контролируются конфигурацией привязки. Глядя на свой код, вы создаете свою собственную привязку следующим образом:

var elements = new List<BindingElement>();
elements.Add(new BinaryMessageEncodingBindingElement());
elements.Add(new HttpTransportBindingElement());
var binding = new CustomBinding(elements);

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

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

var binding = new CustomBinding(elements);
//Set the timeout to something reasonable for your service
//This will fail very quickly
binding.SendTimeout = TimeSpan.FromSeconds(1);

Наконец, чтобы перехватить исключения и вызвать правильные события, вы можете обновить делегат AsyncCallback следующим образом. Исключение возникает при вызове EndGet ().

AsyncCallback asyncCallBack = delegate(IAsyncResult result)
{
    IFeedService service = ((IFeedService)result.AsyncState);
    try
    {
        var items = service.EndGet(result);
        ItemsRetrieved(this, EventArgs.Empty);
    }
    catch (System.TimeoutException ex)
    {
        //Handles timeout
        ServiceCallError(this, EventArgs.Empty);
    }
    catch (System.ServiceModel.CommunicationException ex)
    {
        //Handles a number of failures:
        //  Lack of cross-domain policy on target site
        //  Exception thrown by a service
        ServiceCallError(this, EventArgs.Empty);
    }
    catch (System.Exception ex)
    {
        //Handles any other errors here
        ServiceCallError(this, EventArgs.Empty);
    }
};

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

new ChannelFactory<IFeedService>("feedServiceEndpoint");

Это должно со временем сделать приложение более удобным в обслуживании.

Надеюсь, это поможет.

Джерри

Обновлено:

Джефф,

Пожалуйста, взгляните на этот код и комментарии внутри, чтобы получить более подробное объяснение того, что здесь происходит. Метод MakeCall () создает функцию (делегат), которая передается методу BeginGet (). Эта функция позже выполняется, когда служба отвечает.

Внесите предложенные изменения и установите точки останова в строках, начинающихся с «AsyncCallback asyncCallback» и «var items». Вы увидите, что первый проход отладчика просто объявляет код (функцию / делегат) для выполнения, когда служба отвечает, а второй проход - это фактическая обработка этого ответа, начиная с внутренней части объявления вашего делегата. Это означает, что внешний try / catch не будет в области видимости, когда будет обработан ответ на вызов службы.

public void MakeCall(DateTime lastTime, Dictionary<string, string> context)
{
    try
    {
        AsyncCallback asyncCallBack = delegate(IAsyncResult result)
        {
            try
            {
                var items = ((IFeedService)result.AsyncState).EndGet(result);
                if (ItemsRetrieved != null)
                    ItemsRetrieved(this, new ServiceCallerEventArgs(items));
            }
            catch (Exception ex)
            { 
                //This will catch errors from the service call
            }
        };
        _channel.BeginGet(lastTime, context, asyncCallBack, _channel);
    }
    catch(Exception ex)
    {
        //This will not catch an error coming back from the service.  It will 
        //catch only errors in the act of calling the service asynchronously.

        //The communication with the service and response is handled on a different
        //thread, so this try/catch will be out of scope when that executes.

        //So, at this point in the execution, you have declared a delegate 
        //(actually an anonymous delegate the compiler will turn into a hidden class) 
        //which describes some code that will be executed when the service responds.

        //You can see this in action by setting a breakpoint just inside the delegate
        //at the line starting with "var items".  It will not be hit until the service
        // responds (or doesn't respond in a timeout situation).
    }
}

Джерри

Раньше я сталкивался с подобной проблемой. Основная проблема заключается в том, как IDisposable реализован на экземплярах вашего прокси / канала. То, как я решил эту проблему, показано в приведенном ниже коде, где IDirector - мой контракт на обслуживание:

public class ProxyWrapper : IDisposable
{
    private IDirector proxy;
    private ChannelFactory<IDirector> factory;
    int callCount = 0;

    public ProxyWrapper()
    {
        factory = new ChannelFactory<IDirector>();

        proxy = factory.CreateChannel();
    }

    public IDirector Proxy
    {
        get
        {
            if (callCount > 0)
                throw new InvalidOperationException("The proxy can only be accessed once for every ProxyWrapper instance. You must create a new ProxyWrapper instance for each service request.");
            // only allow the proxy/channel to be used for one call.

            callCount++;
            return proxy;
        }
    }

    public void Dispose()
    {
        IClientChannel channel = (IClientChannel)proxy;

        try
        {
            if (channel.State != CommunicationState.Faulted)
            {
                channel.Close();
            }
            else
            {
                channel.Abort();
            }
        }
        catch (CommunicationException)
        {
            channel.Abort();
        }
        catch (TimeoutException)
        {
            channel.Abort();
        }
        catch (Exception)
        {
            channel.Abort();
            throw;
        }
        finally
        {
            channel = null;
            proxy = null;
        }
    }
}

Способ использования вышеуказанного класса следующий:

    public static void Login(string userName, string password)
    {
        using (ProxyWrapper wrapper = new ProxyWrapper())
        {
            currentSession = wrapper.Proxy.Login(userName, password);
        }
    }

Поскольку класс ProxyWrapper реализует IDisposable, если мы используем экземпляр класса ProxyWrapper внутри блока using, метод Dispose() гарантированно будет вызван, даже если возникнет исключение. Код в методе Dispose() будет обрабатывать все случаи и состояния прокси / канала. Затем вы можете добавить в этот метод код делегата обработки ошибок / ведения журнала / событий.

Прочтите следующую запись в блоге для получения дополнительной информации и более общей версии приведенного выше кода: http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx

Чтобы отловить ошибки связи с сервером, я бы предложил поместить вызов .CreateChannel() в try ... catch и обработать там такие вещи, как CommunicationException и TimeoutExceptions.

Кроме того, один из основных советов: создание ChannelFactory - довольно дорогостоящая операция, поэтому вы можете сделать это отдельно и где-нибудь сохранить эту ссылку на объект ChannelFactory.

Если вам нужно создать и, возможно, повторно создать канал из ChannelFactory, вы можете затем использовать этот сохраненный / кэшированный экземпляр ChannelFactory снова и снова, не создавая его все время.

Но в остальном, я думаю, у вас здесь все хорошо!

Марк

Ваш экземпляр ChannelFactory будет в состоянии «Прервано», когда произойдет этот тайм-аут. Вы обнаружите, что исключение генерируется не тогда, когда исключение происходит в вызове, а когда вы вызываете _channel.Dispose ().

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

Вот почему вы все еще получаете исключение - здесь оно не обрабатывается.

Обновление:

Судя по трассировке стека, похоже, что фреймворк пытается выполнить ваш делегат обратного вызова и получает исключение. Вы ответили в другом месте, что попытка / перехват содержимого вашего делегата не решает проблему ... как насчет внутренних исключений? Каков полный вывод TheException.ToString ()?

Я пробежался через .NET Framework, и ему действительно разрешено возвращаться к пулу потоков (по крайней мере, в трассировке стека, которая у вас есть), что приведет к необработанному исключению и к смерти вашего потока. Если что-то еще хуже, вы всегда можете взять на себя потоки ... развернуть свой собственный поток и синхронно вызвать службу внутри, а не использовать встроенный асинхронный шаблон (если это не тип связи WCF Duplex, который я не делаю) не думаю, что это так).

Я все еще думаю, что полная информация об исключениях (если есть что-то еще) может быть полезна.

Джефф, покажите нам свой код, когда вы попытаетесь поместить блок try / catch вокруг вызова EndGet. Трудно поверить, что это не исключение, и видение этого поможет мне поверить в это.

Кроме того, в рамках этого эксперимента избавьтесь от обработчика событий UnhandledException. Я думаю, вы поймаете это исключение, как только BrowserHttpRequest поймет, что есть 404. Я думаю, что без события UnhandledException попытка / уловка вокруг EndGet перехватит исключение, если оно есть. Я думаю, вы улавливаете промежуточное состояние процесса обработки исключений.

Я также хотел бы, чтобы вы поместили System.Debugger.Break или что-то в этом роде сразу после вызова EndGet.

Прав ли я, думая, что вы создали свой ServiceCaller класс так, чтобы его можно было вызывать в using блоке?

Если да, то в этом проблема. Классы каналов WCF были спроектированы таким образом, чтобы было чрезвычайно сложно написать полностью общий код утилизации, который учитывает все возможные состояния ошибок. Если бы это было просто, то сами классы каналов можно было бы безопасно удалить, и вам не понадобился бы класс-оболочка.

Единственный безопасный способ, который я нашел на сегодняшний день, - это инкапсулировать не логику удаления, а всю последовательность вызовов, таким образом:

public static void Invoke<TContract>(ChannelFactory<TContract> factory, Action<TContract> action) where TContract : class {

    var proxy = (IClientChannel) factory.CreateChannel();
    bool success = false;
    try {
        action((TContract) proxy);
        proxy.Close();
        success = true;
    } finally {
        if(!success) {
            proxy.Abort();
        }
    }
}

Я знаю, что это синхронный вызов, но принцип тот же. Вместо того, чтобы пытаться определить, следует ли вам вызывать Close или Abort, вы определяете это заранее, основываясь на том, как далеко вам удалось пройти через вызов, прежде чем он упал.

Обратите внимание: в этой специальной обработке требуется только реальный канал. Вы можете избавиться от фабрики как хотите, AFAIK.

Я думаю, что проблема в том, как вы спроектировали вызывающего абонента.

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

Я бы перенес создание и закрытие канала в метод make call.

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