码迷,mamicode.com
首页 > 其他好文 > 详细

DICOM:fo-dicom之C-STORE再分析‘解决System.ObjectDisposedException异常’

时间:2015-04-18 01:14:47      阅读:194      评论:0      收藏:0      [点我收藏+]

标签:fo-dicom   dicom   c-store   tcpclient   

背景:

在我的【DICOM系列专栏】中希望尽量涵盖关于DICOM协议的所有知识,但是在具体到某个知识点的讲解时往往会穿插使用DICOM协议的多种开源实现,例如基于C++的dcmtk、基于C#的fo-dicom、甚至是最近更加入的基于Java的dcm4che。之所以穿插介绍多种开源实现,简单概括其用意有三,第一,开源实现各有利弊,为了方便大家自己动手练习,第一时间会选择对该知识点实现最简单的开源库;第二,开源库的实现过程中应用到了许多编码和工程的设计理念,直接查看源码有时候会看起来与DICOM协议脱离甚远,因此在着重介绍DICOM协议具体内容时会使用实现直接、最符合DICOM协议原状的开源库;第三,开源库最终是为了实际应用,某些时候为了项目效率和性能考虑,会使用实现技术最新的开源库。

题记:

对于开源库的实现技术,之前部分博文也进行过简单分析。例如DICOM医学图像处理:Dcmtk与fo-dicom保存文件的不同设计模式之“同步VS异步”+“单线程VS多线程”。fo-dicom与mDCM库同属于DICOM的C#开源实现,正如上述博文所述,fo-dicom中使用了大量的.NET异步编程模式技术对mDCM进行重构。之前博文只对fo-dicom中I/O操作(文件读取和保存)的异步实现进行了介绍,近期在项目具体部署过程中遇到了一个奇葩问题,最终排查发现是由于之前对fo-dicom库中网络部分的异步实现理解有偏差所致。因此此次博文通过分析fo-dicom中的C-STORE服务实现再次分析fo-dicom中使用的.NET异步编程模型。

fo-dicom C-STORE服务弹出System.ObjectDisposedException异常

之前在DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store博文中对于C-STORE SCU的介绍直接使用的是fo-dicom在github上的官方示例,其代码很简单,如下所示:

var client = new DicomClient();
client.AddRequest(new DicomCStoreRequest(@"test.dcm"));
client.Send("127.0.0.1", 12345, false, "SCU", "ANY-SCP");

单个文件的发送请求与DICOM标准第7部分中对于C-STORE的具体描述严格一致,fo-dicom在具体实现时,首先利用AddRequest将数据体添加到client内部的数据链表中,然后通过Send函数利用TCP协议发送到指定的PACS服务端。
但是在C-STORE SCU服务的具体应用场景中,尤其是放射科,往往需要传送的是一个Series序列中的多张图像,也就是说需要构造多个DicomCStoreRequest对象通过AddRequest添加到DicomClient内部数据链表中,然后通过Send()进行发送。因此直接来看的话,对于序列的发送,实现代码应该是:

for(int i=0;i<series.number;++i)
{
    DicomCStoreRequest req = new DicomCStoreRequest(series.files[i]);
    client.AddRequest(req);
    client.Send("127.0.0.1",12345,false,"SCU","ANY-SCP");
}

但是在具体部署Release发布版时,会偶然随机性的出现崩溃的现象,且概率较高,传输320层图像序列大概每间隔两到三次出现一次崩溃。调试时刻发现断点停在fo-dicom库的核心代码DicomService中,如下图所示:
技术分享
通过查看日志可以发现,运行过程中对于每个文件的传输会对应一次“System.ObjectDisposedException异常”。
技术分享

fo-dicom C-STORE的异步实现分析

虽然调试时刻,断点停止在fo-dicom库内部DicomService类中,但是在搜索fo-dicom相关bug提交及论坛中并未发现出现过该类问题。因此决定仔细研究一下fo-dicom中C-STORE服务的实现流程,希望从中找到原因。
一次C-STORE的SCU请求在fo-dicom中实现很简洁,只需要两句代码,
1)client.AddRequest(new DicomCStoreRequest(@”test.dcm”));
**2)**client.Send(“127.0.0.1”,12345,false,”SCU”,”ANY-SCP”);
接下来让我们逐一进行分析,

DicomClient.AddRequest分析:

DicomClient中对于AddRequest的具体实现如下,

    public void AddRequest(DicomRequest request) {
        if (_service != null && _service.IsConnected) {
            //zssure:2015-04-14,try to conform whether AddRequest and Send uses the same one client
            LogManager.Default.GetLogger("Dicom.Network").Info("zssure debug at 20150414,the DicomRequest object is {0},DicomServiceUser is{1}", request.GetHashCode(), _service.GetHashCode());
            //zssure:2015-04-14,end
            _service.SendRequest(request);
            if (_service._timer != null)
                _service._timer.Change(Timeout.Infinite, Timeout.Infinite);
        } else
            _requests.Add(request);
    }

可以看出,AddRequest在向内部请求列表中添加具体DicomCStoreRequest请求时会进行判断,如果当前连接已开启(\_serivce!=null)且未断开(_service.IsConnected),AddRequest会直接触发发送操作;如果当前连接已关闭或断开,只负责将用户的DicomCStoreRequest请求添加到内部链表中,等待连接建立后触发发送操作。
按照这样的理解,只要在AddRequest添加数据之前开启连接,AddRequest单个函数就相当于发送操作。因此之前的代码可以简化,例如:

bool isConnected=false;
for(int i=0;i<series.number;++i)
{
    DicomCStoreRequest req = new DicomCStoreRequest(series.files[i]);
    client.AddRequest(req);
    if(!isConnected)
    {
        client.Send("127.0.0.1",12345,false,"SCU","ANY-SCP");
        isConnected=true;
    }
}

通过上述改进,我们期望在for循环体内之调用一次Send函数,其目的是建立连接,随后只调用AddRequest来完成后续的发送操作。但是具体测试过程中出现了,只发送成功首张图像的情况,而且多次测试都是如此,并未解决我们前文遇到的System.ObjectDisposedException异常。从代码直观来看上述代码修改后应该至少是可以完成for循环发送整个序列的,为何只发送了首张图像呢?问题可能出现在Send函数中,因此我们需要继续看下去。

DicomClient.Send分析:

DicomClient中的Send函数源代码如下:

    public void Send(string host, int port, bool useTls, string callingAe, string calledAe) {
        EndSend(BeginSend(host, port, useTls, callingAe, calledAe, null, null));
    }

这种以BeginXXX和EndXXX为命名的配套函数,就是之前博文 DICOM医学图像处理:Dcmtk与fo-dicom保存文件的不同设计模式之“同步VS异步”+“单线程VS多线程”中介绍的fo-dicom中使用的.NET中的异步编程模型,即APM。这是.NET中引入的比较早的异步编程模型,目前.NET中的代理(delegate)中都有对APM模型的实现,具体细节请阅读之前博文,这里就不介绍的。
知道了采用的是APM异步线程模型后,我们继续看,

    public IAsyncResult BeginSend(string host, int port, bool useTls, string callingAe, string calledAe, AsyncCallback callback, object state) {
        _client = new TcpClient(host, port);
        //zssure:2015-04-14,try to conform whether AddRequest and Send uses the same one client
        LogManager.Default.GetLogger("Dicom.Network").Info("zssure debug at 20150414,the TcpClient object is {0},HashCode{1}", _client.ToString(),_client.GetHashCode()); 
        //zssure:2015-04-14,end

        if (Options != null)
            _client.NoDelay = Options.TcpNoDelay;
        else
            _client.NoDelay = DicomServiceOptions.Default.TcpNoDelay;

        Stream stream = _client.GetStream();

        if (useTls) {
            var ssl = new SslStream(stream, false, ValidateServerCertificate);
            ssl.AuthenticateAsClient(host);
            stream = ssl;
        }

        return BeginSend(stream, callingAe, calledAe, callback, state);
    }

从中可以看出,DicomClient在BeginSend内部会创建新的TcpClient连接对象。待连接建立后,会再建立新的DicomServiceUser,即我们之前在AddRequest函数中看到的_service服务连接。

    public IAsyncResult BeginSend(Stream stream, string callingAe, string calledAe, AsyncCallback callback, object state) {
        var assoc = new DicomAssociation(callingAe, calledAe);
        assoc.MaxAsyncOpsInvoked = _asyncInvoked;
        assoc.MaxAsyncOpsPerformed = _asyncPerformed;
        foreach (var request in _requests)
            assoc.PresentationContexts.AddFromRequest(request);
        foreach (var context in _contexts)
            assoc.PresentationContexts.Add(context.AbstractSyntax, context.GetTransferSyntaxes().ToArray());

        _service = new DicomServiceUser(this, stream, assoc, Logger);
        //zssure:2015-04-14,try to conform whether AddRequest and Send uses the same one client
        LogManager.Default.GetLogger("Dicom.Network").Info("zssure debug at 20150414,the DicomServiceUser object is {0},HashCode{1}", _service.ToString(),_service.GetHashCode());
        //zssure:2015-04-14,end
        _assoc = new ManualResetEventSlim(false);

        _async = new EventAsyncResult(callback, state);
        return _async;
    }

BeginXXX与EndXXX函数其实是使用Windows编程中常用的事件(Event)通知的方式来实现异步处理。如果再BeginXXX函数运行后直接调用EndXXX函数会使得当前线程被阻塞。正如EndSend具体代码所示,

    public void EndSend(IAsyncResult result) {
        if (_async != null)
            _async.AsyncWaitHandle.WaitOne();

        if (_assoc != null)
            _assoc.Set();

        if (_client != null) {
            try {
                _client.Close();
            } catch {
            }
        }

        _service = null;
        _client = null;
        _async = null;
        _assoc = null;

        if (_exception != null && !_abort)
            throw _exception;
    }

在该函数中可以清晰看到EndSend函数内部在等待BeginXXX工作线程完成工作,且当前线程出于阻塞状态,即_async.AsyncWaitHandle.WatiOne();。待工作完成后,会关闭之前的TcpClient连接,抛弃内部缓存的成员变量,即_service=null,_client=null,_assoc=null。

问题解决:

至此,我们可以看出DicomClient类内部虽然内部采用了APM异步编程模式,但是以EndSend(BeginSend(XXX))方式调用的Send函数本身是同步的,在调用的地方会阻塞当前线程,直至图像发送完成,且在完成后会关闭之前建立的连接和服务。由此我们可以大致猜测出之前两次尝试的问题所在,具体情况如下表:
技术分享
而之前出现的System.ObjectDisposedException异常多半是由于在for循环内部频繁重新创建/抛弃TcpClient、频繁创建/抛弃DicomServiceUser。那么如何才能解决该问题呢?,其实很简单,通过查看DicomServiceUser类的源码就知道答案了,如下所示:

        public void OnReceiveAssociationAccept(DicomAssociation association) {
            _client._assoc.Set();
            _client._assoc = null;

            foreach (var request in _client._requests)
            {
                //zssure:2015-04-14,try to conform whether AddRequest and Send uses the same one client
                LogManager.Default.GetLogger("Dicom.Network").Info("zssure debug at 20150414,the DicomRequest object is {0},the DicomClient is{1},the DicomServiceUser is {2}", request.GetHashCode(), _client.GetHashCode(),this.GetHashCode());
                //zssure:2015-04-14,end

                SendRequest(request);
            }
            _client._requests.Clear();
        }

也就是说:

在创建DicomServiceUser服务对象时,那一刻DicomServiceUser内部会对之前添加的所有DicomRequest进行遍历,逐个发送。因此要发送Series序列中的多幅图像时,在for循环内部只需要调用 AddRequest函数将每个图像添加到DicomClient内部数据列表中即可。待添加完成后,在for循环外部调用一次Send函数即可触发具体发送操作,此刻在DicomServiceUser内部会逐个将之前添加的DicomRequest进行发送。

即修改后的代码如下,

for(int i=0;i<series.number;++i)
{
    DicomCStoreRequest req = new DicomCStoreRequest(series.files[i]);
    client.AddRequest(req);
}
client.Send("127.0.0.1",12345,false,"SCU","ANY-SCP");

实际测试结果:

通过上述问题,相信已经找到了问题的解决方法。接下来让我们具体运行验证一下。下面两幅截图分别是修改前和修改后的运行结果,如下所示:
技术分享

技术分享
从图中我们可以看出,之前将AddRequest和Send同时放到for循环时由于频繁创建/抛弃DicomServiceUser对象,因此每一幅图像发送时都会新建连接从而输出SendAssociationRequest函数内部的调试日志。并且会抛出异常。
修改后的方案,在for循环内部运行时并未输出任何日志。待for循环退出后,执行Send函数时,只创建了一次DicomServiceUser服务对象,因此调试日志中只输出了一次SendAssociationRequest函数的调试日志,随后就是逐个发送之前添加的DicomCStoreRequest请求,只输出简单的C-STORE请求和响应日志。

ZSSURE总结:

至此我们已经解决了实际遇到的问题,如果不是因为现场部署发现,可能该问题会继续埋藏下去,为以后服务运行留下隐患。最后用一张简单的图来总结一下这次问题的原因:将AddRequest放入for循环,Send放在循环外才能高效完成C-STORE实际应用场景。
技术分享




作者:zssure@163.com
日期:2015-04-18

DICOM:fo-dicom之C-STORE再分析‘解决System.ObjectDisposedException异常’

标签:fo-dicom   dicom   c-store   tcpclient   

原文地址:http://blog.csdn.net/zssureqh/article/details/45104357

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!