2012-04-08 1 views
8

Обычно использование Google OpenId работает отлично, тысячи раз в день, после чего оно начнет прерывисто работать неправильно и отсрочить в течение нескольких часов (некоторые запросы будут проверяться, но не все). Повторная проверка будет в конечном итоге работать.Google OpenId: конечная точка OpenID не найдена (прерывистая)

Сообщения об ошибках:

Event code: 200000 
Event message: No OpenID endpoint found. : https://www.google.com/accounts/o8/id 

Sequence contains no elements 

Добавление урожайности Log4Net:

DotNetOpenAuth.Yadis: 
Error while performing discovery on: "https://www.google.com/accounts/o8/id": 
DotNetOpenAuth.Messaging.ProtocolException: 
Error occurred while sending a direct message or getting the response. 
---> System.Net.WebException: The operation has timed out  
    at System.Net.HttpWebRequest.GetResponse()  
    at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse 
    (HttpWebRequest request, DirectWebRequestOptions options) 
    in c:\...\Dot...Core\Messaging\StandardWebRequestHandler.cs:line 127  
--- End of inner exception stack trace ---  
    at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse 
    (HttpWebRequest request, DirectWebRequestOptions options) 
    in c:\...\Dot...Core\Messaging\StandardWebRequestHandler.cs:line 175 
    at DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse 
    (HttpWebRequest request, DirectWebRequestOptions options) 
    in c:\...\Dot...Core\Messaging\UntrustedWebRequestHandler.cs:line 250 
    at DotNetOpenAuth.Yadis.Yadis.Request 
    (IDirectWebRequestHandler requestHandler, 
     Uri uri, Boolean requireSsl, String[] acceptTypes) 
    in c:\...\Dot...OpenId\Yadis\Yadis.cs:line 172 
    at DotNetOpenAuth.Yadis.Yadis.Discover 
    (IDirectWebRequestHandler requestHandler, UriIdentifier uri, Boolean requireSsl) 
    in c:\...\DotNetOpenAuth.OpenId\Yadis\Yadis.cs:line 63 
    at DotNetOpenAuth.OpenId.UriDiscoveryService.Discover 
    (Identifier identifier, IDirectWebRequestHandler requestHandler, 
      Boolean& abortDiscoveryChain) 
    in c:\...\DotNet...OpenId\OpenId\UriDiscoveryService.cs:line 51 
    at DotNetOpenAuth.OpenId.IdentifierDiscoveryServices.Discover 
    (Identifier identifier) 
    in c:\...\Dot...OpenId\OpenId\IdentifierDiscoveryServices.cs:line 58 
    at DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.Create 
    (Identifier userSuppliedIdentifier, OpenIdRelyingParty relyingParty, 
     Realm realm, Uri returnToUrl, Boolean createNewAssociationsAsNeeded) 
    in ...OpenId.RelyingParty\OpenId\RelyingParty\AuthenticationRequest.cs:line 364 

И

DotNetOpenAuth.Http WebException: 
Timeout from https://www.google.com/accounts/o8/id, no response available. 

Любые идеи?

+0

Выполняют ли исходящие HTTP-запросы на другие серверы в эти трудные времена? –

+0

Да, как и все входящие запросы. –

+0

DotNetOpenAuth.Http \t Время ожидания WebException с https://www.google.com/accounts/o8/id, ответа не имеется. DotNetOpenAuth.Yadis \t Ошибка при выполнении обнаружения на странице: «https://www.google.com/accounts/o8/id»: DotNetOpenAuth.Messaging.ProtocolException: при отправке прямого сообщения или получении ответа произошла ошибка. ---> System.Net.WebException: операция была отключена в System.Net.HttpWebRequest.GetResponse() ... –

ответ

2

Похоже, вам необходимо исправить латентность сети. Кажется маловероятным, что Google будет узким местом здесь.

Вы также можете увеличить время ожидания HTTP на своем конце, чтобы уменьшить частоту отказов. Полный набор опций доступен here. В частности, вы, вероятно, ищете:

<untrustedWebRequest 
      timeout="00:00:10" 
      readWriteTimeout="00:00:01.500" /> 

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

+0

Считается, что это связано с отключением DNS-сервера –

2

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

Короче говоря, я изменил основной DNS для производственного сервера на общедоступный DNS Google, 8.8.8.8, и он сразу же начал работать. Я вручную удалил кэш DNS на рабочем сервере до этого (без положительного результата), поэтому он заставляет меня полагать, что DNS-сервер (предоставленный нашим центром хостинга) имел плохую запись в кэш, которая в конечном итоге вызывала проблему.

Надеюсь, это поможет кому-то другому, кто сталкивается с этим сценарием.