Re: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 18.01.12 10:27
Оценка: 56 (2)
А>Это такой баг или чем-то обусловлено? Как победить? Как вообще можно хостить службу ожидающую высокой нагрузки?
http://blogs.msdn.com/b/sajay/archive/2009/08/03/concurrent-receives-maxpendingreceive.aspx
Народная мудрось
всем все никому ничего(с).
Re[11]: WCF: UserNamePasswordValidator concurrency
От: rumatavz  
Дата: 22.04.11 14:10
Оценка: +1
R>>А куда Вам больше?
А>есть куда. во время выполнения запросов к БД проц фактически простаивает большую часть времени. создание параллельных запросов увеличивает пропускную сопсобность в разы.

Отсюда вывод — работать с базой асинхронно.
В случае с множеством потоков большая часть из них будет простаивать, а поток — не бесплатный ресурс.
WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 11:13
Оценка:
Возникла следующая проблема с сабжем: вызовы Validate выполняются последовательно независимо от параллельных вызовов со стороны многих клиентов. Т.е. подключилось скажем 1000 клиентов и каждый последовательно проходит валидацию. Это ооочень сильно бьет по производительности в случае параллельных вызовов методов службы от многих клиентов.

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

з.ы. Более полно проблема описана здесь.
Re: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 11:31
Оценка:
Здравствуйте, Аноним, Вы писали:

Попробуйте

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]


но тогда вам прийдется добавить логику синхронизации в классе сервиса.
Re[2]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 11:36
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>
P>[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
P>


У службы настроен ConcurrencyMode.
Я в p.s. исходного сообщения указал ссылку, где подробно описаны мытарства, там было проделано вообще все, что только можно. Стивен Чен из MSFT сначала откликнулся на вопрос, а потом позорно слился.
Re[2]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 12:32
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>но тогда вам прийдется добавить логику синхронизации в классе сервиса.


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

[ServiceContract(SessionMode = SessionMode.Required)] //Required будет давать вам "отлуп" в виде экзепшена, если будете использовать несоотв. биндинг (например, basicHttpBinding)
public interface IMyContract
{
}

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession, /*опционально, если вам нужно*/ ConcurrencyMode=ConcurrencyMode.Multiple)]
public class MyContract:IMyContract
{
}

ну и сконфигурить биндинг...


или
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
Re[3]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 12:35
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:


Да, и код валидатора в студию. Авось, вы там локами балуетесь
Re[4]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 12:57
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>Да, и код валидатора в студию. Авось, вы там локами балуетесь


код валидатора

Thread.Sleep(1000);


никаких локов нигде вообще не в теле службы ни в коде валидатора. более того как только выключаю валидатор вызовы сразу становятся параллельными
Re[3]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 13:02
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>А что если поставить InstanceContextMode в Single...

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

это тоже было проделано — см. ссылку.

P>
P>[ServiceContract(SessionMode = SessionMode.Required)] //Required будет давать вам "отлуп" в виде экзепшена, если будете использовать несоотв. биндинг (например, basicHttpBinding)
P>public interface IMyContract
P>{
P>}

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


P>[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession, /*опционально, если вам нужно*/ ConcurrencyMode=ConcurrencyMode.Multiple)]
P>public class MyContract:IMyContract
P>{
P>}
P>

P>ну и сконфигурить биндинг...


P>или

P>
P>[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
P>


ну можно вообще обойтись без сессии в таком случае — использовать WSBinding — он устанавливает логическую сессию и производит аутентификацию единожды. но проблемы это не решает когда пользователи работают по схеме: подключился, вызвал метод-два, отключился.
Re: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 13:23
Оценка:
Здравствуйте, Аноним, Вы писали:

честно говоря я не ожидал подобного — это просто хэдшот любому highload серверу на wcf. неужели никто не разрабатывает ничего серьезного (высоконагруженного) на wcf раз не наткнулся на такой нехилый bottlneck'и?
Re[5]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 13:42
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:


P>>Да, и код валидатора в студию. Авось, вы там локами балуетесь


А>код валидатора


А>
А>Thread.Sleep(1000);
А>


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

Log4Net appender, который вы используете не тормозит, параллельно "лоча" потоки?

Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.
+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.).
Re[2]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 13:45
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:


А>честно говоря я не ожидал подобного — это просто хэдшот любому highload серверу на wcf. неужели никто не разрабатывает ничего серьезного (высоконагруженного) на wcf раз не наткнулся на такой нехилый bottlneck'и?


Балансировка с WCF работает, но там есть серьезные ограничения на биндинги и бихейворы
Re[6]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 13:53
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.

делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через
30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!

P>+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.).

Антоннело высказал извиняюсь полный бред тупо набивая посты. Ему разжевали, что вызовы Validate выполняются последовательно в то время как методы службы параллельно, но считает уместным сумничать на тему занятых ядер...
Re[3]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 13:59
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>Балансировка с WCF работает, но там есть серьезные ограничения на биндинги и бихейворы

балансировка ? throttling? да, работает, но распространяется только методы служб. а на PasswordValidator's сие как оказалось не рапространяется. итого полезность wcf я для себя на сегодня вижу только в решении следующем: подключилось дофига клиентов, прошли по очереди(!) аутентификацию и наконец-то заработали параллельно ну это очевидный баг, почему мелкософт так позорно слился в той теме мало того, что не пофиксив, так еще и не отписавшись. сразу скажу: автор той темы — не я, я наткнулся на сей баг вчера. гугля нашел только одну такую тему с подобной проблемой.
Re[7]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 21.04.11 14:01
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:


P>>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.

А>делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через
А>30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!

P>>+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.).

А>Антоннело высказал извиняюсь полный бред тупо набивая посты. Ему разжевали, что вызовы Validate выполняются последовательно в то время как методы службы параллельно, но считает уместным сумничать на тему занятых ядер...

Хм, да точно. Невнимательно прочитал. Сорри.
Остается только повторить тоже самое у себя на машине. А, все-таки, трейс не помешал бы.

Вероятно очередь запросов строится одним потоком и там же происходит аутентификация.
А WCF рантайм, в зависомости от настроек сервиса (InstanceContextMode, SessionMode, Concurency, Binding и прочего) выгребает реквесты с этой очереди.
Но это только догадки, нужно в литературу посмотреть, и, конечно, рефлектором.
Re[8]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 21.04.11 14:38
Оценка:
Здравствуйте, perekrestov, Вы писали:

Вобщем перебирая варианты обнаружил, что таки Validate выполняется параллельно — порциями по ~10. Откуда эта цифра и как на нее влиять пока не понял.
Re[9]: WCF: UserNamePasswordValidator concurrency
От: rumatavz  
Дата: 22.04.11 10:09
Оценка:
А>Вобщем перебирая варианты обнаружил, что таки Validate выполняется параллельно — порциями по ~10. Откуда эта цифра и как на нее влиять пока не понял.

А куда Вам больше?
Увеличение одновременно выполняемых потоков только увеличит накладные расходы на переключение контекстов, а быстрее выполнятся всё равно не будет, т.к. число физических процессоров ограничено.
Re[10]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 22.04.11 12:08
Оценка:
Здравствуйте, rumatavz, Вы писали:

R>А куда Вам больше?

есть куда. во время выполнения запросов к БД проц фактически простаивает большую часть времени. создание параллельных запросов увеличивает пропускную сопсобность в разы.

R>Увеличение одновременно выполняемых потоков только увеличит накладные расходы на переключение контекстов, а быстрее выполнятся всё равно не будет, т.к. число физических процессоров ограничено.

не в кассу

з.ы. провел несколько раз еще простейшие тесты и таки выполняется все последовательно. в ветке мелкософта отписался если кому интересно
Re[12]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 22.04.11 14:58
Оценка:
Здравствуйте, rumatavz, Вы писали:

R>Отсюда вывод — работать с базой асинхронно.

как вы пришли к этому выводу? WCF вызывает метод Validate который должен выдать "результат". О какой асинхронности доступа к БД вы говорите? что она даст нам в этом случае?

R>В случае с множеством потоков большая часть из них будет простаивать, а поток — не бесплатный ресурс.

все эти банальности как бы общеизвестны.
раскройте тему применительно к топику
Re[13]: WCF: UserNamePasswordValidator concurrency
От: rumatavz  
Дата: 22.04.11 15:53
Оценка:
R>>Отсюда вывод — работать с базой асинхронно.
А>как вы пришли к этому выводу? WCF вызывает метод Validate который должен выдать "результат". О какой асинхронности доступа к БД вы говорите? что она даст нам в этом случае?

Я имел ввиду, что если есть пул потоков, из которых выполняется одновременно выполняется только 10, то асинхронный вызов — в духе BeginRead позволил бы потоку вернуться в пул и обрабатывать другой вызов во время работы с БД(даже если WCF просто вызывает какой то метод, который выдаёт результат).

В данном случае признаю неуместность совета, т.к. даже если поток спит остальные запросы всё равно ожидают .
Re[14]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 22.04.11 16:03
Оценка:
Здравствуйте, rumatavz, Вы писали:

R>Я имел ввиду, что если есть пул потоков, из которых выполняется одновременно выполняется только 10, то асинхронный вызов — в духе BeginRead позволил бы потоку вернуться в пул и обрабатывать другой вызов во время работы с БД(даже если WCF просто вызывает какой то метод, который выдаёт результат).

это понятно. проблема в том, что итого нет и 10 параллельных вызовов, есть последовательное выполнение. более того, я руками делал ThreadPool.SetMinThreads(350, 350), тротлинг тоже задан в такие значения, но все тщетно. судя по молчанию мелкософта — все очень плохо и баг имеет место быть. самое ужасное, что автор подобного топика на msdn создал тему пол года назад, а ответа все нет. они просто тупо тихо слились — не икомментировать, не исправлять
Re: WCF: UserNamePasswordValidator concurrency
От: vf  
Дата: 22.04.11 17:16
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Как вообще можно хостить службу ожидающую высокой нагрузки?


Реализовать авторизацию через ж.. на другом уровне, добавать user/password/token в каждый метод сервиса?!
Re[2]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 23.04.11 06:49
Оценка:
Здравствуйте, vf, Вы писали:

vf>Реализовать авторизацию через ж.. на другом уровне, добавать user/password/token в каждый метод сервиса?!

да, уже думал об этом, других вариантов действительно нет ну, разве, кроме, что Java

all:
и кто там говорил про исход с Java на .NET?
Re[7]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 23.04.11 20:26
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:


P>>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.

А>делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через
А>30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!
А с чего ты взял что ququing у тебя на сервере а не на клиенте?
Народная мудрось
всем все никому ничего(с).
Re[8]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 24.04.11 05:49
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>А с чего ты взял что ququing у тебя на сервере а не на клиенте?


прочти внимательно. там все описано в подробностях и приведен тест. что это ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг ))) пропадает.
Re[9]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 24.04.11 10:13
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Tom, Вы писали:


Tom>>А с чего ты взял что ququing у тебя на сервере а не на клиенте?


А>прочти внимательно. там все описано в подробностях и приведен тест. что это ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг ))) пропадает.


Нужен конфиг сервера и клиента. Если то что ты описал в посте действительно так — т.е. "and figured out that there is no new "http request" in process until previous one passed", то куинг происходит на клиенте а не на сервере. Предпологаю что проблема в том, что ты не поменял дефолтное значение MaxConnections которое по умолчанию 2.
Народная мудрось
всем все никому ничего(с).
Re[10]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 24.04.11 11:16
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>Предпологаю что проблема в том, что ты не поменял дефолтное значение MaxConnections которое по умолчанию 2.

и как ты объяснишь мое:
что это за ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг пропадает.

ну да ладно, вот код который используется
 ServicePointManager.DefaultConnectionLimit = int.MaxValue;

и далее я сие выделил в тексте

всетаки ты не прочитал кстати, автор той темы не я, но там есть и мои ответы, в том числе (цитирую):

It's a simple test:
sealed class MyPasswordValidator : UserNamePasswordValidator
{
        public override void Validate(string userName, string password)
        {
            Thread.Sleep(1000);
        }
    }

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]
    public sealed class MyService : IMyService
    {
        public int Get(int i)
        {
            return i;
        }
    }
}


Binding:
<basicHttpBinding>
            <binding name="SubscriberBasicTransportWithMessageCredential">
              <security mode="TransportWithMessageCredential">
                <message clientCredentialType="UserName" />
              </security>
            </binding>


Throttling:
<serviceThrottling maxConcurrentCalls="350" maxConcurrentSessions="350" maxConcurrentInstances="350" />


From client i create 30 ChannelFactory with different credetials and 30 channels. Then starts parallel asyncrhonous calls (i see 30 different https sessions). In the result responses comes sequentially with interval of 1 second (Thread.Sleep(1000) in the Validate) — 1 response per second! But in real parallel validation it must be 30 per second and grow up in in accordance with parallel requests!

Where is parallel password validagion? %)

What i'm doing wrong?

p.s. sorry fo my poor english )))
p.s1. and one more thing: if i move Thread.Sleep(1000) from Validate to the service method body — Get — i see 30 responses per second ))) i.e. service method calls is parallel but not Validate


не нужно упрощать проблему невнимательно читая мои ответы. в них уже содержаться ответы на твои вопросы.
Re[11]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 24.04.11 14:35
Оценка:
А>всетаки ты не прочитал кстати, автор той темы не я, но там есть и мои ответы, в том числе (цитирую):
Я понял, остаётся только после того как 30 запросов приняты сервером остановить его по брейкпоинту и посмотреть где каждый поток ожидает. Может быть это даст информацию к размышлению. Мне на самом деле интересен результат ибо у нас точно такой же высоко нагруженный сервер и кастом валидаторы. Просто пока они работаю быстро — мы не столкнулись с подобными проблемами, либо просто пока их не заметили.
Народная мудрось
всем все никому ничего(с).
Re[12]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 24.04.11 19:08
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>Я понял, остаётся только после того как 30 запросов приняты сервером остановить его по брейкпоинту и посмотреть где каждый поток ожидает. Может быть это даст информацию к размышлению. Мне на самом деле интересен результат ибо у нас точно такой же высоко нагруженный сервер и кастом валидаторы. Просто пока они работаю быстро — мы не столкнулись с подобными проблемами, либо просто пока их не заметили.


надо попробовать.
проблема всплыла когда я стал делать стресс-тест для выяснения пропускной способности моих сервисов... и результаты меня прямо скажем не просто огорчили, а шокировали
Re: WCF: UserNamePasswordValidator concurrency
От: OTMOP Россия  
Дата: 25.04.11 11:00
Оценка:
АВТОР! Убил
Пойду свои валидаторы тестить. Пока также не сталкивался с проблемой производительности, т. к. пока что нагрузки невелики, но скоро надо подключать остальные офисы.

Если так — просто жесть.
Viva la Resistance!
Re[2]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 25.04.11 13:09
Оценка:
Здравствуйте, OTMOP, Вы писали:

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


очень жду результатов ваших тестов.

OTM>Если так — просто жесть.

не то слово
Re[3]: WCF: UserNamePasswordValidator concurrency
От: OTMOP Россия  
Дата: 25.04.11 15:16
Оценка:
Здравствуйте, Аноним, Вы писали:

А>очень жду результатов ваших тестов.


Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится
Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.

НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.
Viva la Resistance!
Re[4]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 07:34
Оценка:
Здравствуйте, OTMOP, Вы писали:

OTM>Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится

OTM>Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.
как я и ожидал. кстати с WS биндингом PerSession совсем необязателен для обхода этой проблемы — он и так проводит разовую аутентификаццию эмулируя логическую сессию — у меня и c PerCall прексрасно работает в рамках одного канала .

OTM>НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.

да что там багтрекер, вы посмотрите первоначальный пост, там есть ссылка на social.msdn.com. как я уже писал, другой чел поднял эту проблему полгода назад, на нее откликнулись сразу два MSFT и оба слились без каких-либо комментариев, признаний бага, воркэраундов и т.д и т.п. Вы почитайте последний пост там, как я взываю к справедливости , а они полчат уже неделю. свинью подложили натуральные свиньи )))
Re[5]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 26.04.11 08:04
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, OTMOP, Вы писали:


OTM>>Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится

OTM>>Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.
А>как я и ожидал. кстати с WS биндингом PerSession совсем необязателен для обхода этой проблемы — он и так проводит разовую аутентификаццию эмулируя логическую сессию — у меня и c PerCall прексрасно работает в рамках одного канала .

OTM>>НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.

А>да что там багтрекер, вы посмотрите первоначальный пост, там есть ссылка на social.msdn.com. как я уже писал, другой чел поднял эту проблему полгода назад, на нее откликнулись сразу два MSFT и оба слились без каких-либо комментариев, признаний бага, воркэраундов и т.д и т.п. Вы почитайте последний пост там, как я взываю к справедливости , а они полчат уже неделю. свинью подложили натуральные свиньи )))
А почему не создать баг на msconnect?
Народная мудрось
всем все никому ничего(с).
Re[6]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 09:17
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>А почему не создать баг на msconnect?


наверное потому, что я не в курсе что это
Re[7]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 26.04.11 09:43
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Tom, Вы писали:


Tom>>А почему не создать баг на msconnect?


А>наверное потому, что я не в курсе что это

http://connect.microsoft.com/

Создаш баг — кинь ссылку сюда, будем голосовать.
Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
Народная мудрось
всем все никому ничего(с).
Re[8]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 26.04.11 09:53
Оценка:
А>>наверное потому, что я не в курсе что это
Tom>http://connect.microsoft.com/

Tom>Создаш баг — кинь ссылку сюда, будем голосовать.

Tom>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.

Конкретно для WCF — ссылка: https://connect.microsoft.com/wcf
Народная мудрось
всем все никому ничего(с).
Re[9]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 11:34
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>>http://connect.microsoft.com/

создал. насколько позволяет знание англ языка )

Tom>>Создаш баг — кинь ссылку сюда, будем голосовать.

здесь

Tom>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.

в форму создания бага скопипастил из social.msdn

Tom>Конкретно для WCF — ссылка: https://connect.microsoft.com/wcf

пасип
Re[10]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 26.04.11 11:37
Оценка:
Tom>>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
А>в форму создания бага скопипастил из social.msdn
лучше было бы пример сделать и убедиться что там есть проблема.
Ответили бы я думаю намного быстрее.
Народная мудрось
всем все никому ничего(с).
Re[11]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 11:42
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>лучше было бы пример сделать и убедиться что там есть проблема.


это изначально сложно — и не пример сделать, а
1. сертификат создать
2. добавить его в хранилище
3. привязать к порту

т.к. используется HTTPS а без защищенного транспорта wcf нe даст передавать credentials

поэтому вряд ли поможет )
Re[11]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 26.04.11 14:15
Оценка:
Здравствуйте, Аноним, Вы писали:



А>[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]

А> public sealed class MyService : IMyService
А> {
А> public int Get(int i)
А> {
А> return i;
А> }
А> }
А>}
А>[/c#]

А>Binding:

А>
А><basicHttpBinding>
А>            <binding name="SubscriberBasicTransportWithMessageCredential">
А>              <security mode="TransportWithMessageCredential">
А>                <message clientCredentialType="UserName" />
А>              </security>
А>            </binding>
А>


А>Throttling:

А>
А><serviceThrottling maxConcurrentCalls="350" maxConcurrentSessions="350" maxConcurrentInstances="350" />
А>


Я могу ошибаться, но, кажется,

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]

особо не имеет смысла
В этом случае уж лучше InstanceContextMode.Single использовать.
Re[12]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 14:30
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>Я могу ошибаться, но, кажется,

нет, вы не ошибаетесь, я перестраховался исключительно для форума — в других местах люди сходу тыкают в отсутствие Multiple не зная что он у PerSession по дефолту включен. Т.е. я упредил такие вопросы
Re[12]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 26.04.11 16:50
Оценка:
А>поэтому вряд ли поможет )
А причём тут вообще сертификаты и HTTPS ?
Как я понял проблкема в кастом валидаторе, точнее в его вызове, тогда она должна проявляться в обычном wshttpbinding/basichttpbinding-е?
Народная мудрось
всем все никому ничего(с).
Re[13]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 26.04.11 16:59
Оценка:
Здравствуйте, Tom, Вы писали:

А>>поэтому вряд ли поможет )

Tom>А причём тут вообще сертификаты и HTTPS ?
Tom>Как я понял проблкема в кастом валидаторе, точнее в его вызове, тогда она должна проявляться в обычном wshttpbinding/basichttpbinding-е?

>>без защищенного транспорта wcf нe даст передавать credentials
Re[14]: WCF: UserNamePasswordValidator concurrency
От: perekrestov Украина  
Дата: 27.04.11 17:07
Оценка:
Здравствуйте, Аноним, Вы писали:


>>>без защищенного транспорта wcf нe даст передавать credentials


Даст, если подсунуть соотв. биндинг (только передавайте все поверх https):

                        <customBinding>
                <binding name="InsecureBinding">
                    <textMessageEncoding>
                        <readerQuotas maxStringContentLength="2147483647" maxArrayLength="1000"/>
                    </textMessageEncoding>
                    <security allowInsecureTransport="true" authenticationMode="UserNameOverTransport"/>
                    <httpTransport maxReceivedMessageSize="1000000"/>
                </binding>
            </customBinding>




                     <service behaviorConfiguration="MyBehavior" name="Services.DataService">
                <endpoint address="" binding="customBinding" bindingConfiguration="InsecureBinding" contract="Services.IDataService"/>
            </service>



<behavior name="MyBehavior">
                    <serviceMetadata httpGetEnabled="true" httpsGetEnabled="false"/>
                    <serviceDebug includeExceptionDetailInFaults="true"/>
                    <serviceCredentials>
                        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="SomeNamespace.CustomServiceUserValidator, Mycompany.AssemblyName"/>
                    </serviceCredentials>
                </behavior>
Re[15]: WCF: UserNamePasswordValidator concurrency
От: Аноним  
Дата: 27.04.11 17:21
Оценка:
Здравствуйте, perekrestov, Вы писали:

P>Даст, если подсунуть соотв. биндинг (только передавайте все поверх https):


ну я имел ввиду стандартные привязки.

чем сложнее (нестандартнее) код постишь на форумах/багтрекерах, тем больше отвлеченных от темы вопросов и "решений" дают, и ложных ошибок находят
запостишь вот с кастомным биндингом в багтрекер, а они тебе напишут, что: проблема в ваших биндингах и вообще не надо использовать небезопасные транспорты с открытыми удостоверениями, и "вообще микрософт так не рекомедует... поэтому у вас ниче и не работает" (С)

P>
P>                        <customBinding>
P>                <binding name="InsecureBinding">
P>                    <textMessageEncoding>
P>                        <readerQuotas maxStringContentLength="2147483647" maxArrayLength="1000"/>
P>                    </textMessageEncoding>
P>                    <security allowInsecureTransport="true" authenticationMode="UserNameOverTransport"/>
P>                    <httpTransport maxReceivedMessageSize="1000000"/>
P>                </binding>
P>            </customBinding>
P>
Re[3]: WCF: UserNamePasswordValidator concurrency
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.01.12 14:37
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>all:

А>и кто там говорил про исход с Java на .NET?

О да, особенность поведения игрушечного UserNamePasswordValidator в WCF, это, конечно, приговор всему дотнету
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[12]: WCF: UserNamePasswordValidator concurrency
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.01.12 14:37
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>т.к. используется HTTPS а без защищенного транспорта wcf нe даст передавать credentials


WindowsStreamSecurityBinding спасет отца русской демократии.
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[2]: WCF: UserNamePasswordValidator concurrency
От: Tom Россия http://www.RSDN.ru
Дата: 18.01.12 15:08
Оценка:
Здравствуйте, Tom, Вы писали:

А>>Это такой баг или чем-то обусловлено? Как победить? Как вообще можно хостить службу ожидающую высокой нагрузки?

Tom>http://blogs.msdn.com/b/sajay/archive/2009/08/03/concurrent-receives-maxpendingreceive.aspx

До кучи для 3.5
http://support.microsoft.com/kb/976462
Народная мудрось
всем все никому ничего(с).
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.