Changes Between 2.x and 1.x

Apache MINA > Index >

Overview ·         Home ·         Features ·         Testimonials ·         Documentation ·         Performance ·         Downloads ·         Road Map ·         FAQ Community ·         Contact ·         Support Forum ·         Contributors ·         Related Projects ·         Donations

Changes Between 2.x and 1.x Apache MINA 2.x provides a new API that is partly backward-incompatible from 1.x. Sacrificing backward-compatibility somewhat, 2.x simplifies the overly complex part of the previous API into more intuitive one. Please note that this document explains incompatible changes only, because most part of the API is backward-compatible. Apache MINA 2.x 一套新的API, 这可能与之前的1.x 稍有不兼容. 虽然牺牲了少许的向后兼容, 但2.x 将之前的API过于复杂的部分简化为更加直接的实现方式. 请注意这份文档仅仅解释了不兼容的改变, 这套API体系的绝大部分都是向后兼容的. ThreadModel Has Been Removed. ThreadModel被移除. ThreadModel was initially introduced to simplify the process to apply a predefined thread model to an IoService. However, configuring most thread models has turned out to be too simple to introduce any new construct. ThreadModeal caused a lot of confusion rather than ease of use. ThreadModel一开始作为简化应用一个预先定义的线程模型到IoService的流程而引入的. 然而, 配置大多数的线程模型已经变得太简单而不至于引入任何新的构造函数. 相对于它的易于使用, ThreadModeal引起的更多的则是困惑和问题. IoService Configuration Has Been Simplified. IoService配置被简化. In 1.x, IoService and its sub-interfaces (i.e. IoAcceptor and IoConnector) had many ways to configure itself. Basically, it had two ways to configure a service: 在 1.x里, IoService和它的子接口(比如, IoAcceptor和IoConnector) 都拥有很多种配置方式. 基本上来说, 配置一个服务通常使用以下两种方式: ·         Specify an IoServiceConfig with bind() or connect() call explicitly.  通过显式调用bind()或connect()来指定一个IoServiceConfig. ·         SocketAcceptor acceptor = new SocketAcceptor(); ·         SocketAcceptorConfig myServiceConfig = new SocketAcceptorConfig(); ·         myServiceConfig.setReuseAddress(true); acceptor.bind(myHandler, myServiceConfig); ·         Use IoService.defaultConfig property, which is employed when no IoServiceConfig is specified. 调用IoService.defaultConfig属性, 当没有IoServiceConfig指定时. ·         SocketAcceptor acceptor = new SocketAcceptor(); ·         acceptor.getDefaultConfig().setReuseAddress(true); acceptor.bind(new InetSocketAddress(8080), myHandler); Configuring an IoFilterChain brings another headache. In IoService, there's an additional global IoFilterChainBuilder besides the IoFilterChainBuilder in an IoServiceConfig. This means that two IoFilterChainBuilders are used to configure one IoFilterChain. Most users configure an IoFilterChain using only the global IoFilterChainBuilder and find that's enough. 配置一个IoFilterChain带来了另一个头疼的问题. 在IoService里, 除了IoServiceConfig里有一个IoFilterChainBuilder外,还有一个额外的全局的IoFilterChainBuilder. 这就是说, 有两个IoFilterChainBuilders用来配置这一个IoFilterChain. 大多数用户在配置IoFilterChain时,  仅仅使用全局的IoFilterChainBuilder, 并发现这已经足够了. IoAcceptor acceptor = new SocketAcceptor(); acceptor.getFilterChain().addLast("myFilter1", new MyFisrtFilter()); acceptor.getDefaultConfig().getFilterChain().addLast("myFilter2", new MySecondFilter()); acceptor.bind(new InetSocketAddress(8080), myHandler); // Which filter will be the first? 那么, myFilter1和myFilter2哪个将会被首先添加呢? To address this complication, MINA 2.0 simplified the API to enable easy bootstrapping of your network application. Please compare the following code to the previous examples. 为了解决这一问题, MINA 2.0简化了这个环节. 请比较下面这段代码: SocketAcceptor acceptor = new SocketAcceptor(); acceptor.setReuseAddress(true); acceptor.getFilterChain().addLast("myFilter1", new MyFirstFilter()); acceptor.getFilterChain().addLast("myFilter2", new MySecondFilter()); acceptor.getSessionConfig().setTcpNoDelay(true); acceptor.setLocalAddress(new InetSocketAddress(8080)); acceptor.setHandler(myHandler); acceptor.bind();   // New API restricts one bind per acceptor, and  you can't bind more than once.新的API限制了每个acceptor只能有一个bind, 并且只能bind一次 // The following statement will throw an IOException.下面的代码将会抛出一个IOException acceptor.bind(); You might already have noticed that Spring framework integration became easier, too. 同样地, 你可能会注意到Spring框架集成也变得容易多了. ByteBuffer Pooling Has Been Removed, and a Heap Buffer is the Default Buffer Type. ByteBuffer池被移除, 堆缓存成为默认缓存类型. ·         No more error-prone acquire() and release()  不再有容易出错的acquire()和release(). ·         Better out-of-the-box performance and stability in most JVMs 对于大多数JVM, 有了更好的测试表现和稳定性 Direct ByteBuffer pooling was one of the cool features that MINA advertised in early days. According to recent benchmarks, however, direct buffers are known to perform worse than heap buffers in most modern JVMs. Moreover, unexpected OutOfMemoryError is often thrown if the maximum direct buffer memory is not configured properly. 直接ByteBuffer池机制曾经是MINA早起宣扬的一个很酷的特性之一. 但根据最近的一些测试表明, 直接缓存在大多数现代JVM上表现都比堆缓存差. 而且, 如果直接缓存的最大内存配置不合适, 意外的OutOfMemoryError会经常抛出. To provide out-of-the-box best performance and stability, the Apache MINA team decided to change the default buffer type from 'direct' to 'heap'. Because heap buffers don't need any pooling, ByteBuffer pooling has been removed, too. ByteBuffer.acquire() and ByteBuffer.release() also have been removed, because there's no pooling anymore. 为了提高测试表现和稳定性, Apache MINA团队决定把默认缓存类型由”直接”改为”堆”的方式. 因为堆缓存不再需要任何池的机制, 因此ByteBuffer池也被移除. 同时由于不再有池的机制, ByteBuffer.acquire()和ByteBuffer.release()也被移除.

Added by Trustin Lee, last edited by Trustin Lee on Apr 09, 2007  (view change)

Edit Page   Browse Space   Add Page   Add News   Add Diagram

Copyright © 2004-2007, The Apache Software Foundation (stats: mail · site) <script type="text/javascript"> var sc_project=2754704; var sc_invisible=0; var sc_partition=27; var sc_security="aca8bb11"; </script><script src="http://www.statcounter.com/counter/counter_xhtml.js" type="text/javascript"> </script>