Manipulation INET Erlang http erreurs client

j'ai une application Erlang qui fait un grand nombre d'appels http vers des sites externes à l'aide INET, en utilisant le code ci-dessousManipulation INET Erlang http erreurs client

case http:request(get, {Url, []}, [{autoredirect, false}], []) of 
{ok, {{_, Code, _}, _, Body}}-> 
    case Code of 
    200 -> 
     HandlerFn(Body); 
    _ -> 
     {error, io:format("~s returned HTTP ~p", [Broker, Code])} 
    end; 
Response -> %% block to handle unexpected responses from inets 
    {error, io:format("~s returned ~p", [Broker, Response])} 
end.

Il y a un bloc explicite pour gérer quoi que ce soit INET étranges pourrait retourner [réponse]. Malgré cela, je reçois toujours ce qui ressemble à des rapports d'erreurs inets déposés sur la console [échantillon ci-dessous]. Qu'est-ce que je fais mal ici? Ai-je besoin de configurer une sorte de gestionnaire d'erreur inets ailleurs?

Merci.

=ERROR REPORT==== 24-Apr-2010::06:49:47 === 
** Generic server <0.6618.0> terminating 
** Last message in was {connect_and_send, 
          {request,#Ref<0.0.0.139358>,<0.6613.0>,0,http, 
           {"**********",80}, 
           "*****************************", 
           [],get, 
           {http_request_h,undefined,"keep-alive", 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,"news.bbc.co.uk", 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,[],undefined,undefined,undefined, 
            undefined,"0",undefined,undefined, 
            undefined,undefined,undefined,undefined,[]}, 
           {[],[]}, 
           {http_options,"HTTP/1.1",infinity,false,[], 
            undefined,false,infinity}, 
           "************************************", 
           [],none,[],1272088179114,undefined,undefined}} 
** When Server state == {state, 
          {request,#Ref<0.0.0.139358>,<0.6613.0>,0,http, 
           {"******************",80}, 
           "*****************************", 
           [],get, 
           {http_request_h,undefined,"keep-alive", 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,"news.bbc.co.uk", 
            undefined,undefined,undefined,undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,[],undefined,undefined, 
            undefined,undefined,"0",undefined, 
            undefined,undefined,undefined,undefined, 
            undefined,[]}, 
           {[],[]}, 
           {http_options,"HTTP/1.1",infinity,false,[], 
            undefined,false,infinity}, 
           "****************************************", 
           [],none,[],1272088179114,undefined,undefined}, 
          undefined,undefined,undefined,undefined,undefined, 
          {[],[]}, 
          {[],[]}, 
          undefined,[],nolimit,nolimit, 
          {options, 
           {undefined,[]}, 
           0,2,5,120000,2,disabled,false,inet,default, 
           default,[]}, 
          {timers,[],undefined}, 
          httpc_manager,undefined} 
** Reason for termination == 
** {error,{connect_failed,{#Ref<0.0.0.139358>,{error,nxdomain}}}} 

=ERROR REPORT==== 24-Apr-2010::06:49:47 === 
HTTPC-MANAGER<httpc_manager> handler (<0.6618.0>, started) failed to connect and/or send request #Ref<0.0.0.139358> 
    Result: {error,{connect_failed,{#Ref<0.0.0.139358>,{error,nxdomain}}}}

Source

2010-04-24 Justin

Pour chaque requête HTTP que vous faites, un processus de httpc_handler séparé est généré "en interne". Ce processus tente d'abord d'ouvrir une socket vers le domaine souhaité. Dans ce cas, le domaine est inexistant et l'ouverture du socket échoue. En conséquence, le processus engendré décide d'arrêter. Comme le processus du gestionnaire est écrit selon les principes de gen_server, votre gestionnaire d'erreurs va vider le dernier état du processus de mort. Il n'y a rien à faire ou à faire à ce sujet.

Source

2010-04-24 08:02:45 Zed

Eh bien, c'est une erreur intermittente; c'est donc un problème avec le serveur distant. La question est, comment puis-je gérer l'erreur à mon extrémité? – Justin

Je pense que sa question est plus sur la façon de gérer le fait que le processus inets s'est écrasé et non pourquoi il s'est écrasé. –

Je suppose que http crée un nouveau processus qui meurt avec nxdomain. Ce crash Sasl ramasse et imprime dans la coquille.

Source

2010-04-24 11:49:36 Lukas

En supposant que votre application respecte le format OTP, le superviseur chargé du traitement des inets doit être configurable pour redémarrer le processus. L'écrasement des processus est "normal" pour une application erlang et il y a toutes sortes de façons dans un arbre de superviseur pour gérer l'occasion. Lukas a eu raison de dire que SASL se contente de signaler le fait que le processus s'est écrasé. Cela évite que votre rappel ne soit jamais appelé afin qu'il ne puisse pas gérer le crash. En fait, il ne peut pas gérer le crash car il dépend en particulier d'être appelé par le processus qui s'est écrasé. Sans voir comment votre processus d'initialisation est démarré et le code qui fait l'appel Il est difficile de vous conseiller plus que de dire que l'endroit approprié pour gérer l'accident est dans votre arbre de superviseur. Je suggère de lire la documentation sur la conception du système Erlang: http://www.erlang.org/doc/design_principles/users_guide.html pour avoir une idée de la façon dont les processus erlang sont destinés à être utilisés et manipulés.

Source

2010-04-25 01:09:00

Le client HTTP inets a une interface plutôt incohérente. Je suggère d'utiliser lhttpc à la place.

Source

2010-04-26 12:30:21 legoscia

Manipulation INET Erlang http erreurs client

Répondre

Questions connexes