WebActivatorEx重复执行?不!那是作为使用者的我们傻逼!!

作者:V君 发布于:2018-6-15 22:42 Friday 分类:挖坑经验

TL;DR:

如果在发布新版本后出现疑似WebActivatorEx启动入口被执行多次的情况

首先检查bin里面是否有上个版本残留的DLL,干掉它们就解决了,然后把锅甩给运维

 

那么,开始我的故事。


~前奏~


由于首次在正式项目引入git源代码管理体系,仓库结构设计的相当散乱。

这不赶上重组git仓库,重新建立了解决方案,命名空间和项目名称也重新规划了。



好不容易发布一个新版本到测试环境,运行起来出现致命错误的黄页。

连最开始的初始化都没完成,错误处理也措手不及,好久不见的黄页就这样呈现出来。


~扯一扯~


由于不喜欢Log4Net这种只能用配置文件的充满Java味道的东西。

现在项目中的日志组件是由我自己实现的,有以下特性:

  • 由写入时间决定文件名
  • 6个级别,外加可选启用的虚拟级别“ALL”将其他级别内容凑一起输出
  • 按指定大小分文件
  • 多次启停可续写
  • 自动删除指定天数的旧文件

写入方式是基于线程安全的FileStream共享只读打开,方便边写边看。

内容格式是三行一空行的条目:

  • 第一行写时间、级别、线程信息(如果有写程序集,也能快速发现这次的问题。之后补上吧)
  • 第二行写摘要,由开使用者定义的简短摘要
  • 第三行写详情的JSON,有日志位置堆栈,可以加入任意对象作为附加信息

在日志组件初始化之后,我通常会打一句“Logger Init”在日志中体现应用程序启动。

我们有为此专门做了个小工具来分析日志,用上了Chris NielsenJSON可视化界面实现。


~诊断~


打住,话题收回来,黄页的错误信息是“文件被占用”,堆栈显示正在打“Logger Init”时…

一开始的时候很有自信,以为自己写的实现没问题,可能被文件共享出来占用了。

用Procexp查文件句柄,一个都没查出… 

但作为应用程序启动的体现“Logger Init”却被打进日志文件里…

老大的意思是想让我先把多节点负载均衡砍掉,以单节点跑起来,降低复杂度再诊断。

当时没辙只好听话照办喽,然并卯。

还是掏出诊断大杀器ProcMon看看“是谁动了我的奶酪”,看到结果时开始觉得自信不足了:

——真的是ASP.NET程序池进程访问的文件,而且是同一条原生线程访问了两次。

——第一次成功打开,第二次打开失败,最后还把文件关闭了——由CLR,程序都崩溃了嘛!

难道是自己的实现有问题,多线程竞态现象?

.NET的托管线程可能会复用原生线程,出现TID一样的情况也不能排除多线程。

在初始化的地方加了锁,然而问题依旧存在。其实并不是我的代码写的不严谨,这是后话。


咋办?


让文件打开的共享模式可读可写吧,想到了这样高风险的激进尝试。

然而——还是失败了,但仔细观察发现ProcMon监视条目详情有蹊跷:

第一次打开文件的共享模式是只读,第二次才是符合激进尝试的可读可写。

两次打开文件的原生堆栈有差异,很可惜看不到托管堆栈,如果能看到程序集就能解决问题了。

远程调试吧。没办法的办法了,在日志初始化的地方打个断点看看会不会两次命中。

调试结果令人十分失望,只命中了一次,打开失败的第二次。天知道第一次在哪儿打开?

这时猫同事建议我把“Logger Init”改一下,看看有没有打出来。这才恍然大悟。

我拒绝了建议,且断言上个版本残留程序集,去服务器bin看看,断言成立!

抓住运维的肩膀使劲晃,“你让我浪费了两天的时间排查” 乂目


~结语~


甩完锅之后还是要总结一下教训的,发布版本应该将之前的文件干掉,再把新的包部署上去。

标签: 软件开发 C# ASP.NET 软件故障诊断

评论(0) 引用(0) 浏览(225)

ASP.NET WEB场:在使用StateServer站点集群节点之间共享会话

作者:V君 发布于:2018-3-22 17:31 Thursday 分类:挖坑经验

TL;DR

步骤1: 在每个节点部署的web.config里配置状态服务为StateServer,使用一致的主机和端口;

步骤2: 为每个节点IIS网站设置一致的ID.

点击查看原图



扯一扯:

终于有机会接触ASP.NET的WEB负载均衡, 运维配置好测试环境之后开始捣腾.

按照公司沿袭下来的习惯,用的是歪门邪道的nginx反向代理实现请求分发.

说到会话,当然就是登录状态啦! 一上来就掉进坑里: 登录不了.

诊断下来发现, 原来死循环重定向了: 因为节点之间会话不通,


导致节点A处理完登录之后回到节点B处理的首页,节点B没有得到会话判定为未登录

接着又重定向到节点A处理的登录页面, 登录页面会把已登录的请求重定向回首页.

如此反复, 甚是尴尬.


经过一番咕狗,找到M$DN上的帮助文档(325056),开始按照文档操作(这里又一次自己跳坑里).

由于错误理解帮助文档中所指的路径,误以为是部署web站点的文件路径要求一致,

尝试了之后发现不行,又回来仔细读文档. 这才发现要一致的是网站ID.


0rz.


标签: 软件开发 ASP.NET 负载均衡

评论(0) 引用(0) 浏览(179)

排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数

作者:V君 发布于:2017-6-9 17:01 Friday 分类:填坑经验

WEB应用程序出现响应很慢甚至卡死的现象,

Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)


于是锅放到我这里辣.


DebugDiag得出堆栈已经显示具体代码位置了, 

想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.

 

参考其 sosex 的 readme.txt MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈

要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )


搞起! .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程

然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值

这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.

 

标签: 软件开发 ASP.NET 调试技术 windbg

评论(0) 引用(0) 浏览(588)

记一次COOKIE域造成ASP.NET会话丢失

作者:V君 发布于:2017-5-24 16:05 Wednesday 分类:填坑经验

TL;DR

从浏览器 COOKIES 开始检查, 注意每次请求时 asp.net_sessionid 是否有变化, 

注意响应 COOKIES 是否有设置 Domain. 于是发现为了兼容子域名被设定了值.

加上调试条件编译跳过就解决了.


稍稍扯扯:

最初,发现 ajax 请求没有返回预期内容, 调试发现 Session 里面的东西变 null 了.

第一反应是Session配置问题或可能被 Abandon 过, 全文检索代码没发现被调用. 

先排除被 Abandon 这个可能.

去 web.config 看看 Session 配置, 切换了 InProcess 和 StateService 模式都不奏效.

然后观察每次请求上下文,发现 SessionId 每次都会变,COOKIE asp.net_sessionid 也每次都变

最后只好把焦点放到浏览器了, 仔细观察 COOKIE 响应况发现了原因.

标签: 软件开发 ASP.NET 调试技术 Web技术

评论(0) 引用(0) 浏览(628)

解决一蛋痛的WCF-REST配置问题:未找到注册基址方案

作者:V君 发布于:2017-3-14 20:12 Tuesday 分类:挖坑经验

状况:

访问时出现以下错误

找不到具有绑定 WebHttpBinding 的终结点的与方案 http 匹配的基址。注册的基址方案是[]

注意, 注册的基址方案是空的, 和遍地都是的 “注册的基址方案是[http]”不同

 

TL;DR:

在 web.config 配置基址前缀就能解决该问题.

<serviceHostingEnvironment>

    <baseAddressPrefixFilters>

        <add prefix="http://localhost" />

    </baseAddressPrefixFilters>

</serviceHostingEnvironment>

扯扯:

扯你妹不想扯了, 花了好大劲都解决不了. 

结果 ServerAdmin 告诉咱们想起以前的项目遇到类似的情况时,负责人的做法...


so.解决不了配置问题的码农不是好运维? ( ゚∀。)

 

标签: 软件开发 C# ASP.NET MVC WCF REST 运行时错误

评论(0) 引用(0) 浏览(459)

Powered by emlog 去你妹的备案 sitemap