我负责运维一个短信接口站点sms。调用上游短信供应商下发短信后，他们会给我们推送发送报告。报告是类似DELIVRD、DI:9432这样的码。为了方便识别，系统里有一个报告码与其描述的关系，一开始是写死在程序里的。这样的弊端是，后期每次添加了这个映射关系后，都要更新网站程序，增大了维护成本。
为了降低维护成本，我做了改进方案。
将这个映射关系保存到一个文本文件ReportCodeMapper.txt里，提供一个页面来允许修改这个文件的内容。 对于使用的逻辑，声明一个静态的Dictionary，初始化时从这个文本文件里读取出来再做转换add到这个Dictionary里。 类文件结构如下：
文件是保存在站点下的，所以在读取的时候需要调用Server.MapPath方法来得到其物理文件路径。由于使用逻辑在SmsSDK类库里，我要添加引用System.Web，然后借助System.Web.HttpContext.Current.Server.MapPath。
很快，我驾轻就熟写完了代码。
发布之后，发现程序在每次处理推送的报告时都会报异常：
时间：2016-01-12 19:21:51 读取文件异常：System.NullReferenceException: 未将对象引用设置到对象的实例。 在 SmsSDK.ReportCodeMapper..ctor()
由于这次上线同时改动的代码逻辑比较多，我丝毫没怀疑是文件解析报的异常。
于是，进一步在必须的地方加日志。再进行模拟流请求操作，再监控记录的日志。 这样几次下来，最终发现还真是HttpContext.Current为null导致的。
问题是定位到了，然后就感到疑惑， 用一般处理文件(.ashx)来发布的接口，被流请求调用时HttpContext.Current是null？
开始排障：模拟报告推送需要指定xml格式的参数，为了快速定位问题，我找了个.ashx文件，在其ProcessRequest(HttpContext context)方法首行调用ReportCodeMapper.GetDesc方法，模拟流请求调用这个.ashx接口，发现正常。
这增加了我的疑惑。由于时间近夜半，于是回滚了版本。
次日来公司后，再继续排查，最终发现，原因出在我在调用AddRecord方法时，使用了线程池。这才豁然。见下图：
儿时记得看过一篇课文，说有个农夫要寻觅一颗草药，他每天爬山去找寻，但一直无果。在将要灰心的放弃时，意外发现他苦苦寻觅的草药，就在他每天经过的山脚下。
其实，问题的原因，只要用心认真细致的追查，你会发现，原因很简单。