SocketException, посылая много сообщений (код 10048)

Я посылаю много сообщений, используя cloudQueue. BeginAddMessage и EndAddMessage. Я ограничиваю сумму, начинается, которые еще не возвратились к 500. Все же я получаю исключение с кодом 10048 (значение истощения гнезда).

Microsoft.WindowsAzure.Storage.StorageException: Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

Решение, которое я нашел после поиска, которому все советуют, чтобы изменить регистрацию, однако поскольку это планируется в роли рабочего в Голубом, я не могу сделать этого.

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

Мой вопрос: есть ли ошибка на стороне лазури здесь? Что я должен сделать, чтобы зафиксировать это кроме искусственного замедления добавления сообщений к ползанию?

Вот испытательная функция, которую я использую, чтобы послать сообщения. В моем случае, приблизительно после 16500 добавляемых сообщений и отзыв, законченный правильно и стабильный, это замедляется и скоро бросает упомянутое исключение.

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

Исключение брошено из AsyncCallback endAddCallback .

    static void Main()
    {
        Console.SetBufferSize(205, Int16.MaxValue - 1);

       //Set the maximum number of concurrent connections (12*6 in my case)
        ServicePointManager.DefaultConnectionLimit = 12 * Environment.ProcessorCount;
        //setting UseNagleAlgorithm to true reduces network traffic by buffering small packets of data and transmitting them as a single packet, but setting to false can significantly reduce latencies for small packets.
        ServicePointManager.UseNagleAlgorithm = false;
        //if true, "Expect: 100-continue" header is sent to ensure a call can be made. This uses an entire roundtrip to the service point (azure), so setting to false sends the call directly.
        ServicePointManager.Expect100Continue = false;

        CloudStorageAccount storageAccount = CloudStorageAccount.Parse(__CONN_STRING);
        CloudQueueClient client = storageAccount.CreateCloudQueueClient();
        CloudQueue queue = client.GetQueueReference(__QUEUE_NAME);
        queue.CreateIfNotExists();
        List ids = new List();
        for (Int32 i = 0; i < 40000; i++)
            ids.Add(Guid.NewGuid());

        SendMessages(queue, ids.Select(id => new CloudQueueMessage(id.ToString())).ToList().AsReadOnly());
    }

    public static void SendMessages(CloudQueue queue, IReadOnlyCollection messages)
    {
        List toSend = messages.ToList();
        Object exceptionSync = new Object();
        Exception exception = null;
        CountdownEvent cde = new CountdownEvent(toSend.Count);
        AsyncCallback endAddCallback = asyncResult =>
        {
            Int32 endedItem = (Int32)asyncResult.AsyncState;
            try
            {
                queue.EndAddMessage(asyncResult);
                Console.WriteLine("SendMessages: Ended\t\t{0}\t/{1}", endedItem + 1, toSend.Count);
            }
            catch (Exception e)
            {
                Console.WriteLine("SendMessages: Error adding {0}/{1} to queue: \n{2}", endedItem + 1, toSend.Count, e);
                lock (exceptionSync)
                {
                    if (exception == null)
                        exception = e;
                }
            }
            finally { cde.Signal(); }
        };

        for (Int32 i = 0; i < toSend.Count; i++)
        {
            lock (exceptionSync)
            {
                if (exception != null)
                    throw exception;
            }
            //if number of added but not ended is larger than the MAX, yield and check again.
            while (true)
            {
                Int32 currentOngoing = (i- (cde.InitialCount - cde.CurrentCount));
                if (currentOngoing > 500)
                    Thread.Sleep(5);
                else
                    break;
            }
            Console.WriteLine("SendMessages: Beginning\t{0}\t/{1}", i + 1, toSend.Count);
            queue.BeginAddMessage(toSend[i], endAddCallback, i);
        }

        cde.Wait();
        if (exception != null)
            throw exception;
        Console.WriteLine("SendMessages: Done.");
    }
3
Роль рабочего в Голубом должна дать вам права изменить некоторых (если не все) ключи через событие OnStart или через RDP.. Что является ключом вы can' t изменяют?
добавлено автор CHI Coder 007, источник
Идет. Из того, что я извлек уроки из использования TPL, есть два типа нитей: нити IO и нити Процесса. Возможно, внедрение Async Очередей - not' t использование того же самого внедрения как Столы. Независимо, I' d интересоваться наблюдением вашей работы над Столами, если вы желаете. Я пытаюсь никогда не прекратить учиться и думать, что ваш код интересен (I' m в новинку для async также, но обертывающий в TPL)
добавлено автор CHI Coder 007, источник
Идет. Из того, что я извлек уроки из использования TPL, есть два типа нитей: нити IO и нити Процесса. Возможно, внедрение Async Очередей - not' t использование того же самого внедрения как Столы. Независимо, I' d интересоваться наблюдением вашей работы над Столами, если вы желаете. Я пытаюсь никогда не прекратить учиться и думать, что ваш код интересен (I' m в новинку для async также, но обертывающий в TPL)
добавлено автор CHI Coder 007, источник
Да it' s возможный отредактировать регистрацию. Есть 2 пути: Задача запуска или событие OnStart
добавлено автор CHI Coder 007, источник
Да it' s возможный отредактировать регистрацию. Есть 2 пути: Задача запуска или событие OnStart
добавлено автор CHI Coder 007, источник
Роль рабочего в Голубом должна дать вам права изменить некоторых (если не все) ключи через событие OnStart или через RDP.. Что является ключом вы can' t изменяют?
добавлено автор CHI Coder 007, источник
@makerofthings7 Видят мой ответ Джо для обновления. Я могу послать вам код для столов, если вы хотите, don' t знают, как релевантный это должно было бы приклеить его в этой нити.
добавлено автор David S., источник
@makerofthings7 Видят мой ответ Джо для обновления. Я могу послать вам код для столов, если вы хотите, don' t знают, как релевантный это должно было бы приклеить его в этой нити.
добавлено автор David S., источник
В любом случае я должен отметить, что это будет перемещать или делать проблему менее видимой только (и использовать больше ресурсов), и что все еще, кажется, есть ошибка, где гнезда - not' t закрытый.
добавлено автор David S., источник
В любом случае я должен отметить, что это будет перемещать или делать проблему менее видимой только (и использовать больше ресурсов), и что все еще, кажется, есть ошибка, где гнезда - not' t закрытый.
добавлено автор David S., источник
Я попробую это и отчитаюсь, спасибо. Я don' t знают, почему я принял его couldn' t быть сделанным. Однако странно что я don' t получают эту ошибку с клиентом стола, даже при том, что it' s очень быстро также.
добавлено автор David S., источник
Я попробую это и отчитаюсь, спасибо. Я don' t знают, почему я принял его couldn' t быть сделанным. Однако странно что я don' t получают эту ошибку с клиентом стола, даже при том, что it' s очень быстро также.
добавлено автор David S., источник
Я wasn' t зная, что я мог изменить регистрацию в роли рабочего? Ключи - HKLM\System\CurrentControlSet\Services\Tcpip\Parameters (оценивает MaxUserPort и TCPTimeWaitDelay). Как предложено в этом ответе и других местах stackoverflow.com/questions/1339142/…
добавлено автор David S., источник
Я wasn' t зная, что я мог изменить регистрацию в роли рабочего? Ключи - HKLM\System\CurrentControlSet\Services\Tcpip\Parameters (оценивает MaxUserPort и TCPTimeWaitDelay). Как предложено в этом ответе и других местах stackoverflow.com/questions/1339142/…
добавлено автор David S., источник
Какое-либо обновление по этой проблеме? I' m видящий это с Голубой регистрацией веб-сайтов Голубой очереди на версии 3.0.3 Хранения
добавлено автор Yoenhofen, источник
Какое-либо обновление по этой проблеме? I' m видящий это с Голубой регистрацией веб-сайтов Голубой очереди на версии 3.0.3 Хранения
добавлено автор Yoenhofen, источник

6 ответы

Облако [Blob|Table|Queue] Клиент не поддерживает государство и может использоваться через многие объекты.

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

  • , которому алгоритм Nagle разработан, чтобы помочь в этом случае, комплектуя вместе маленькие запросы в tcp слое, устанавливая его в истинный, может немного увеличиться во время ожидания сообщения в некоторых случаях, но под напряжением, скорее всего, это будет незначительно, поскольку запросы не должны будут долго ждать, чтобы быть больше, чем окно nagle ищет (1400 байтов)
  • Увеличение ServicePointManager. DefaultConnectionLimit, чтобы составлять быстрое открытие и закрытие гнезд.
  • Может вы предоставлять больше информации относительно того, где вы кодируете, бежит, и если есть какой-либо другой код, используя связи, в то время как это бежит. По умолчанию запросы клиента посылают, поддерживают = верный, который должен держать постоянные связи с Голубым обслуживанием и позволить многократным просьбам использовать то же самое гнездо, не имея необходимость открываться/закрываются/снова соединяются.

Кроме того, относительно вашего комментария предприятий стола, не показывающих то же самое поведение, текущим проводным протоколом, который поддерживает Обслуживание Стола, является Атом/Паб, который может быть довольно болтливым (xml и т.д.). Поэтому простая вставка предприятия намного больше, чем простая очередь guid сообщение. Чрезвычайно из-за различия в размере движение стола делает лучшую работу, использующую слой TCP ниже его, таким образом, это не истинные яблоки к сравнению яблок.

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

joe

2
добавлено
Спасибо Джо - I' ve теперь попробовал несколько вещей: Позвольте nagle алгоритм не, имел значимого эффекта, все еще получите исключение. Увеличенный предел связи 5 раз: все еще исключение (возможно, всего несколько секунд спустя чем обычно). Позволенный и nagle и увеличивающийся предел связи: все еще исключение также. Я также пытался уменьшить ключ реестра TcpTimedWaitDelay к 30 секундам. Это имело некоторый эффект, но увеличивая случаи заявления отправки различным очередям одновременно, исключение все еще появляется очень быстро. В какой информации вы нуждаетесь о счете?
добавлено автор David S., источник
О, и код работает на моем офисном компьютере. I' ve примерил несколько машин, также дома. Все машины показывают тысячи TIME_WAIT в netstat-n продукция. Но только некоторые или даже ни один, вставляя в хранение стола.
добавлено автор David S., источник

Облако [Blob|Table|Queue] Клиент не поддерживает государство и может использоваться через многие объекты.

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

  • , которому алгоритм Nagle разработан, чтобы помочь в этом случае, комплектуя вместе маленькие запросы в tcp слое, устанавливая его в истинный, может немного увеличиться во время ожидания сообщения в некоторых случаях, но под напряжением, скорее всего, это будет незначительно, поскольку запросы не должны будут долго ждать, чтобы быть больше, чем окно nagle ищет (1400 байтов)
  • Увеличение ServicePointManager. DefaultConnectionLimit, чтобы составлять быстрое открытие и закрытие гнезд.
  • Может вы предоставлять больше информации относительно того, где вы кодируете, бежит, и если есть какой-либо другой код, используя связи, в то время как это бежит. По умолчанию запросы клиента посылают, поддерживают = верный, который должен держать постоянные связи с Голубым обслуживанием и позволить многократным просьбам использовать то же самое гнездо, не имея необходимость открываться/закрываются/снова соединяются.

Кроме того, относительно вашего комментария предприятий стола, не показывающих то же самое поведение, текущим проводным протоколом, который поддерживает Обслуживание Стола, является Атом/Паб, который может быть довольно болтливым (xml и т.д.). Поэтому простая вставка предприятия намного больше, чем простая очередь guid сообщение. Чрезвычайно из-за различия в размере движение стола делает лучшую работу, использующую слой TCP ниже его, таким образом, это не истинные яблоки к сравнению яблок.

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

joe

2
добавлено
Спасибо Джо - I' ve теперь попробовал несколько вещей: Позвольте nagle алгоритм не, имел значимого эффекта, все еще получите исключение. Увеличенный предел связи 5 раз: все еще исключение (возможно, всего несколько секунд спустя чем обычно). Позволенный и nagle и увеличивающийся предел связи: все еще исключение также. Я также пытался уменьшить ключ реестра TcpTimedWaitDelay к 30 секундам. Это имело некоторый эффект, но увеличивая случаи заявления отправки различным очередям одновременно, исключение все еще появляется очень быстро. В какой информации вы нуждаетесь о счете?
добавлено автор David S., источник
О, и код работает на моем офисном компьютере. I' ve примерил несколько машин, также дома. Все машины показывают тысячи TIME_WAIT в netstat-n продукция. Но только некоторые или даже ни один, вставляя в хранение стола.
добавлено автор David S., источник

Я подозреваю, что это - потому что CloudQueueClient не предназначен для многопоточного (async) доступа, поскольку вы делаете его.

Попытайтесь воссоздать CloudQueue в SendMessages как это

    CloudQueueClient client = storageAccount.CreateCloudQueueClient();
    CloudQueue queue = client.GetQueueReference(__QUEUE_NAME);

Я читал на многочисленных форумах, что CloudXXClient предназначается, чтобы использоваться однажды и располагаться. Тот руководитель мог бы обратиться здесь.

Нет большой эффективности, которая будет получена, поскольку ctor для клиента не отправляет запрос очереди и имеет проблемы пронизывания.

0
добавлено
Можно ли попытаться двинуться, где CloudQueueMessage создается? Возможно, есть некоторый странный случай закрытия C#. Попытайтесь создать тот объект в функции.
добавлено автор CHI Coder 007, источник
Действительно ли какой-либо из объектов доступен и может потребовать, моются?
добавлено автор CHI Coder 007, источник
они не доступны
добавлено автор David S., источник
Попробованный это - даже если я объявляю и иллюстрирую примерами каждое сообщение в петле, я получаю то же самое исключение. То же самое для клиента/очереди. У меня нет предупреждений закрытия от ReSharper также.
добавлено автор David S., источник
Спасибо за ответ. Я пытался сделать то, что вы сказали, для каждого повторения в для петли, и также послали созданный очередь для повторения как государственный объект к отзыву так, чтобы я использовал его для EndAddMessage функция также. К сожалению, это не работало, я получаю то же самое исключение.
добавлено автор David S., источник

Я подозреваю, что это - потому что CloudQueueClient не предназначен для многопоточного (async) доступа, поскольку вы делаете его.

Попытайтесь воссоздать CloudQueue в SendMessages как это

    CloudQueueClient client = storageAccount.CreateCloudQueueClient();
    CloudQueue queue = client.GetQueueReference(__QUEUE_NAME);

Я читал на многочисленных форумах, что CloudXXClient предназначается, чтобы использоваться однажды и располагаться. Тот руководитель мог бы обратиться здесь.

Нет большой эффективности, которая будет получена, поскольку ctor для клиента не отправляет запрос очереди и имеет проблемы пронизывания.

0
добавлено
Можно ли попытаться двинуться, где CloudQueueMessage создается? Возможно, есть некоторый странный случай закрытия C#. Попытайтесь создать тот объект в функции.
добавлено автор CHI Coder 007, источник
Действительно ли какой-либо из объектов доступен и может потребовать, моются?
добавлено автор CHI Coder 007, источник
они не доступны
добавлено автор David S., источник
Попробованный это - даже если я объявляю и иллюстрирую примерами каждое сообщение в петле, я получаю то же самое исключение. То же самое для клиента/очереди. У меня нет предупреждений закрытия от ReSharper также.
добавлено автор David S., источник
Спасибо за ответ. Я пытался сделать то, что вы сказали, для каждого повторения в для петли, и также послали созданный очередь для повторения как государственный объект к отзыву так, чтобы я использовал его для EndAddMessage функция также. К сожалению, это не работало, я получаю то же самое исключение.
добавлено автор David S., источник

Это было теперь решено в Библиотеке Клиента Хранения 2.0.5.1.

Альтернативно, есть также работа: деинсталлирование KB2750149.

0
добавлено

Это было теперь решено в Библиотеке Клиента Хранения 2.0.5.1.

Альтернативно, есть также работа: деинсталлирование KB2750149.

0
добавлено
Microsoft Stack Jobs
Microsoft Stack Jobs
1 788 участник(ов)

Work & freelance only Microsoft Stack. Feed https://t.me/Microsoftstackjobsfeed Чат про F#: @Fsharp_chat Чат про C#: @CSharpChat Чат про Xamarin: @xamarin_russia Чат общения:@dotnettalks

Microsoft Developer Community Chat
Microsoft Developer Community Chat
584 участник(ов)

Чат для разработчиков и системных администраторов Microsoft Developer Community. __________ Новостной канал: @msdevru __________ Баним за: оскорбления, мат, рекламу, флуд, флейм, спам, NSFW контент, а также большое количество оффтоп тем. @banofbot