Zeroc Ice中间件之通讯器资源回收

引言:

 

    一个类的方法非常多,且被调用较多时,就不宜采用“单方法单代理”的方式了来调用远程ICE服务了。其本质原因是,客户端每次申请新代理都会占用本机的一个端口。如果“单方法单代理”遭遇峰值,可能会直接导致本机端口原因引发异常。异常内容如下:

41:30,031:[CCX_S_FA_INVESTINCOME]002143
Exception in thread "main" Ice.SyscallException
    error = 0
	at IceInternal.Selector.<init>(Selector.java:29)
	at IceInternal.ThreadPool.<init>(ThreadPool.java:77)
	at IceInternal.Instance.finishSetup(Instance.java:786)
	at Ice.CommunicatorI.finishSetup(CommunicatorI.java:286)
	at Ice.Util.initialize(Util.java:212)
	at Ice.Util.initialize(Util.java:222)
	at com.ccx.stock.financialAnalysisNew.DerRepoDataClient.getOwnPrx(DerRepoDataClient.java:83)
	at com.ccx.stock.financialAnalysisNew.DerRepoDataClient.CCX_S_FA_INVESTINCOME(DerRepoDataClient.java:204)
	at com.ccx.stock.financialAnalysisNew.TestDerRepoDataClient.main(TestDerRepoDataClient.java:44)
Caused by: java.io.IOException: Unable to establish loopback connection
	at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:106)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:122)
	at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:27)
	at java.nio.channels.Pipe.open(Pipe.java:133)
	at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:104)
	at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:26)
	at java.nio.channels.Selector.open(Selector.java:209)
	at IceInternal.Selector.<init>(Selector.java:25)
	... 8 more
Caused by: java.net.BindException: Address already in use: connect
	at sun.nio.ch.Net.connect(Native Method)
	at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
	at java.nio.channels.SocketChannel.open(SocketChannel.java:146)
	at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:78)
	... 16 more

 

    下文将对此问题做以简单介绍。

 

正文:

 

    (晚点续上)

 

     (续上)
 
1,首先有以下几个要点需要说明。


    A)项目中ICE通讯使用的是默认TPC/IP(socket)通讯;
    B)Java1.4后以NIO升级老版IO(以支持多路复用);
    C)请求发出后,返回之前,请求者需要被阻塞(java Object.wait()等及线程机制的需要);

2,接下来说说引言中提到的报错信息。


    第2行:Ice.SyscallException,ICE骨架支持异常。

    第13行:Unable to establish loopback connection,本机对本机的连接不能持久化。

    第24行BindException: Address already in use: connect,地址已经被占用。

 

3,详细分析。

 

    本例异常,引发的根本原因是13行与24行。

 

    24行的异常。主要是由于Java每个socket请求时,都会占用*至少*一个端口,本例测试时循环5000个socket请求,在400左右时便出现上述异常。其原因就在当前请求的socket端口已被之前的socket占有。关于此异常很常见,随便搜索一下,可以看到大量的说明,因此这里跳过。

 

    13行的异常。也是本例异常产生的重点。

 

    loopback connection,这是什么connection呢?!是形如如下的connection:

  TCP    10.0.2.128:3024        10.0.2.128:3046      ESTABLISHED
  TCP    10.0.2.128:3046        10.0.2.128:3024      ESTABLISHED

    这两行TCP连接互相监听,组成一对“loopback connection”。初看此连接觉得很费解,为什么会出现这样的TCP(socket)连接呢?回想一下正文第1节C中提到的“阻塞-唤醒”这一需要。我们假设有一个名A的socket请求发出后,很自然进入阻塞状态,随后服务者B在处理结束(正常、异常、强制),想以更效率的DI(Donot call me, I'll call U.)方式唤醒请求者A进行后续处理。

 

    这时就遇到一个问题DI的唤醒如何实现。可能的方式有三:一是B处理结束后有数据需要处理或发生异常;二是超时timeout;三是强制方式(如Executors强制限时完成等)。一看就只有第一种方式了。让自己的3024监听自己的3046,如果自己的socket请求正常调用就不说了;非正常情况下,只要把异常处理或者超时处理交给3046来处理并返回给3024,通知失败(有返回数据需要处理时可被自动唤配),随后自己即可被唤醒了。

 

    这样也就解释了为什么会有loopback connection异常发生。

 

    另外,需要说明的是ICE穿墙采用的是“双向连接”方式,每个客户端请求可能需要使用不止一两个端口。因此在客户端编写并发、单请求单通路,这类socket短时峰值较高的代码时,应该尽力避免。

 

总结:

 

    1,由于java socket连接本身存在“对端口资源的消耗性 与 端口资源的有限性”这一问题,加之ICE默认TCP双向连接的特点更加强了消耗性影响,因此在使用ICE创建通讯器请求远程代理时,尽可能加强代理“复用性”,减少“回收与重申请”。

 

    2,ICE是主要是用于企业架构的,而非通信的。如果不是为架构而来,建议可以考虑一下mina——更专业的java通信框架。

 

尾声:

 

    因为笔者是C/C++,Java双修,双“半吊子”,对socket的理解,欢迎大家批评、讨论。

 

(完)

 

 

 

你可能感兴趣的:(java,中间件,socket,Mina,sun)