- 请求处理过程描述
服务端 使用 框架 加载 业务so,并未业务so创建协程处理,处理完成后给出 响应。so入口函数接收(const Type&in, Type &out,Type &extend),是否给出响应的前提是 out里面要有 业务so的处理结果,即 out 不能是空的。这样处理的 原因是 有些客户端 只关心 消息是否被服务端收到,不关心处理结果,这时 服务端在收到 请求后 直接发送响应告诉 客户端 收到消息了, 而服务端业务so处理 完消息后 置out为空,就不会再次向同一笔请求 发送响应.
- 框架调用业务so伪码:
try
{
loadso;
proc_func=get_symbol:入口函数
proc_func(in,out,extend);
}
catch(...)
{
printf "unkow exception"
}
- 问题点:
业务现网请求消息20%超时,服务端框架日志里有 “unkow exception”,但因为框架要处理很多业务,框架日志是公用的,不能确认"unkow exception”是不是超时请求引起的。
调整框架日志和业务so级别 为debug,框架调用业务so会输出两条接口日志(req,ans);
- 分析
a.怀疑是坏的请求,框架解析请求失败。根据请求里关键字,查看接口日志,发现只有req,没有ans,可以确定 框架接收到了请求,说明网络没问题(在进行这步是可以进行抓包,和有80%成功率),并且请求没问题。
b.业务so 有该请求的运行日志,发现运行到某 特定行后 就不往下处理,没产生core文件;可以确认问题不在框架,结合框架产生的异常异常日志,说明 业务so 产生了异常。
c.从业务so输出的最后一条debug日志点 往下分析,异常一定是后续产生的;逐行代码分析,重点关注可能抛出异常的函数(老司机一眼看出来,牛),最终锁定在string str.substr(pos),该函数原型为
string substr(size_t pos=0,size_t len=npos)const;
If this is greater than the string length, it throws out_of_range.
- 总结
a.发现现网问题,先向直接领导汇报,说自己正在处理,领导可以帮助协调资源,评估影响。
b.打开日志级别到debug,所有日志都要打开。(刚开始没有打印接口日志,导致框架没输出req,不能确定是不是框架没收到消息.)
c.确定请求处理的最后几行代码。逐行分析.(有经验老司机,一眼就看出来问题代码行)
d.建议框架既然捕获了异常,就输出标准异常的详情.e.what(),catch(exception e){} catch(...){}
e.业务so 使用guard 类 局部对象 在析构函数中判断 out 是否为空,以判断是不是异常退出,保证业务so 因业务异常退出时 能输出日志,有据可查. 同时guard 内也可以进行 资源释放回收,防止资源泄露.
记客户端请求超时分析过程
时间: 2024-11-05 00:12:43
记客户端请求超时分析过程的相关文章
SQL Server 磁盘请求超时的833错误原因分析以及解决
本文出处:http://www.cnblogs.com/wy123/p/6984885.html 最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的errorlog中出现磁盘请求超过一定时间才完成的error消息.对于此类问题,到底是存储系统或者磁盘的故障,还是SQL Server 自己的问题,亦或是应用程序引发的呢?又要如何解决?本文将对引起此问题的某一方面的因素进行简单的分析,但是无法涵盖所有潜在的可能性,因此遇到类似问题还要做具体的分析. SQL
IOS-网络(GET请求和POST请求、HTTP通信过程、请求超时、URL转码)
1 // 2 // ViewController.m 3 // IOS_0129_HTTP请求 4 // 5 // Created by ma c on 16/1/29. 6 // Copyright © 2016年 博文科技. All rights reserved. 7 // 8 9 #import "ViewController.h" 10 #import "MBProgressHUD+MJ.h" 11 12 @interface ViewController
基于TCP网络通信的自动升级程序源码分析-客户端请求服务器上的升级信息
每次升级,客户端都会获取服务器端存放在upgradefile文件夹下的需要升级的文件和升级信息配置文件(即upgradeconfig.xml文件) 我们来看一下代码 //升级信息配置文件相对应的类 ( 升级信息配置文件是由这个类转化成的) private UpgradeConfig upgradeConfig = null; //客户端存储升级配置文件的地址 是放在客户端根目录下的 (就是把服务器 upgradefile/upgradeconfig.xml下载到客户端存放的位置) string
记一次ORACLE的UNDO表空间爆满分析过程
这篇文章是记录一次ORACLE数据库UNDO表空间爆满的分析过程,主要整理.梳理了同事分析的思路.具体过程如下所示: 早上收到一数据库服务器的UNDO表空间的告警邮件,最早一封是7:55发出的(监控作业是15分钟一次),从告警邮件分析,好像是UNDO表空间突然一下子被耗尽了. DB Tablespace Allocated Free Used % Free % Used 192.168.xxx.xxx:1521 UNDOTBS1 16384 190.25 16193.75 1.16 99 使用一
HTTP协议及其请求头分析
众所周知,Internet的基本协议是TCP/IP协议,目前广泛采用的FTP.Archie Gopher等是建立在TCP/IP协议之上的应用层协议,不同的协议对应着不同的应用. WWW服务器使用的主要协议是HTTP协议,即超文体传输协议.由于HTTP协议支持的服务不限于WWW,还可以是其它服务,因而HTTP协议允许用 户在统一的界面下,采用不同的协议访问不同的服务,如FTP.Archie.SMTP.NNTP等.另外,HTTP协议还可用于名字服务器和分布式对象管 理. HTTP的早期版本为HT
CXF客户端请求服务流程
CXF(使用版本2.7.6)对Web服务封装度已经非常高了,你只需要像正常写代码一样,附加几个额外的注解直接发布,服务端差不多就完成了:对于客户端更简单,只需要知道Web服务的URL地址和接口,就能如调用本地代码一样,几乎感觉不到与本地代码有什么区别.这就是封装的威力,虽然高度封装简化了我们对Web服务的使用,但也间接地阻挡了我们对其深入了解.本文就将源码层面来分析CXF其内部是如何完成客户端对Web服务的调用封装的,但并不包含服务端对服务请求的处理过程,如有需要可参看上篇,CXF中Web服务请
Tomcat7.0源码分析——请求原理分析(中)
前言 在<TOMCAT7.0源码分析--请求原理分析(上)>一文中已经介绍了关于Tomcat7.0处理请求前作的初始化和准备工作,请读者在阅读本文前确保掌握<TOMCAT7.0源码分析--请求原理分析(上)>一文中的相关知识以及HTTP协议和TCP协议的一些内容.本文重点讲解Tomcat7.0在准备好接受请求后,请求过程的原理分析. 请求处理架构 在正式开始之前,我们先来看看图1中的Tomcat请求处理架构. 图1 Tomcat请求处理架构 图1列出了Tomcat请求处理架构中的主
Tomcat源码分析——请求原理分析(下)
前言 本文继续讲解TOMCAT的请求原理分析,建议朋友们阅读本文时首先阅读过<TOMCAT源码分析——请求原理分析(上)>和<TOMCAT源码分析——请求原理分析(中)>.在<TOMCAT源码分析——请求原理分析(中)>一文我简单讲到了Pipeline,但并未完全展开,本文将从Pipeline开始讲解请求原理的剩余内容. 管道 在Tomcat中管道Pipeline是一个接口,定义了使得一组阀门Valve按照顺序执行的规范,Pipeline中定义的接口如下: getBas
Tomcat7.0源码分析——请求原理分析(上)
前言 谈起Tomcat的诞生,最早可以追溯到1995年.近20年来,Tomcat始终是使用最广泛的Web服务器,由于其使用Java语言开发,所以广为Java程序员所熟悉.很多人早期的J2EE项目,由程序员自己实现Jsp页面或者Servlet接受请求,后来借助Struts1.Struts2.Spring等中间件后,实际也是利用Filter或者Servlet处理请求,大家肯定要问了,这些Servlet处理的请求来自哪里?Tomcat作为Web服务器是怎样将HTTP请求交给Servlet的呢? 本文就