关于javamina下载的信息
今天给各位分享javamina下载的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、会java的mina的高数帮忙看下求大神帮助
- 2、java 应用服务框架mina 和 netty应用案例都有那些，两者该怎么选择
- 3、java mina可以实现http server吗
- 4、java mina 可以多线程写么
会java的mina的高数帮忙看下求大神帮助
如果你要是使用的TextLineCodecFactory过滤器的话是按行截取。。 这个过滤器是遇到\r或\n就会认为读取一行，也就是说客户端请求数据为：a\nb\nc\n。这样MINA的服务器会触发3次messageReceived事件，message分别是a，b，c。其实数据量大无所谓MINA会正确的读取，请数检查下客户端传输的数据中是否包涵\r或\n。 如果数据中一定要有很多\r或\n的话，还要MINA服务器可以正确读取的话，就不要使用TextLineCodecFactory过滤器，可以自定义一个。
java 应用服务框架mina 和 netty应用案例都有那些，两者该怎么选择
哪个熟悉用哪个.Netty是基于线程的完全非阻塞异步模型, 强依赖于LinkedBlockingQueue. 说不定未来会有一款基于完全无锁队列(例如disruptor)的IO框架. Netty比较烦心的是需要定义Inbound,Outbound的handler, 当信道active的时候, 会先找到inbound,如果这个inbound handler里面有调用写操作或者刷新操作,则会在这个inbound处,再次查找outbound,这就要求在添加pipleline的时候要按照一定的顺序, 个人感觉这像是被强奸了一样.
java mina可以实现http server吗
erver端的Session实现通常是通过在Server端为请求的客户分配SessionID实现的，然后把SessionID号发送给client端，client端把这个SessionID记录下来，这里一般是通过Cookie记录，如果Cookie禁用掉的话就得通过URL重写的方式了，这样
java mina 可以多线程写么
MINA,Grizzly[grizzly-nio-framework],xSocket都是基于javanio的serverframework.这里的性能缺陷的焦点是指当一条channel上的SelectionKey.OP_READready时,1.是由selectthread读完数据之后再分发给应用程序的handler,2.还是直接就分发,由handlerthread来负责读数据和handle.mina,xsocket是1.grizzly-nio-framework是2.尽管读channelbuffer中bytes是很快的,但是如果我们放大,当连接channel达到上万数量级,甚至,这种延迟响应的效果将会愈加明显.MINA:forallselectedKeys{readdatathenfireMessageReceived.}xSocket:forallselectedKeys{readdata,appendittoreadQueuethenperformOnData.}其中mina在fireMessageReceived时没有使用threadpool来分发,所以需要应用程序在handler.messageReceived中再分发.而xsocket的performOnData默认是分发给threadpool[WorkerPool],WorkerPool虽然解决了线程池中的线程不能充到最大的问题[跟tomcat6的做法一样],但是它的调度机制依然缺乏灵活性.Grizzly:forallselectedKeys{[NIOContext---filterChain.execute---ourfilter.execute]bindInternal---startupAcceptor:启动AbstractPollingIoAcceptor.Acceptor.run使用executor[Executor]的线程,注册[interestOps:SelectionKey.OP_ACCEPT],然后wakeupselector.一旦有连接进来就构建NioSocketSession--对应--channal,然后session.getProcessor().add(session)将当前的channal加入到NioProcessor的selector中去[interestOps:SelectionKey.OP_READ],这样每个连接中有请求过来就由相应的NioProcessor来处理.这里有几点要说明的是:1.一个NioSocketAcceptor对应了多个NioProcessor,比如NioSocketAcceptor就使用了SimpleIoProcessorPoolDEFAULT_SIZE=Runtime.getRuntime().availableProcessors()+1.当然这个size在newNioSocketAcceptor的时候可以设定.2.一个NioSocketAcceptor对应一个javanioselector[OP_ACCEPT],一个NioProcessor也对应一个javanioselector[OP_READ].3.一个NioSocketAcceptor对应一个内部的AbstractPollingIoAcceptor.Acceptor---thread.4.一个NioProcessor也对应一个内部的AbstractPollingIoProcessor.Processor---thread.5.在newNioSocketAcceptor的时候如果你不提供Executor(线程池)的话,那么默认使用Executors.newCachedThreadPool().这个Executor将被NioSocketAcceptor和NioProcessor公用,也就是说上面的Acceptor---thread(一条)和Processor---thread(多条)都是源于这个Executor.当一个连接javaniochannal--NioSession被加到ProcessorPool[i]--NioProcessor中去后就转入了AbstractPollingIoProcessor.Processor.run,AbstractPollingIoProcessor.Processor.run方法是运行在上面的Executor中的一条线程中的,当前的NioProcessor将处理注册在它的selector上的所有连接的请求[interestOps:SelectionKey.OP_READ].AbstractPollingIoProcessor.Processor.run的主要执行流程:for(;;){intselected=selector(finalSELECT_TIMEOUT=1000L);.if(selected0){process();}}process()--forallsession-channal:OP_READ--read(session):这个read方法是AbstractPollingIoProcessor.privatevoidread(Tsession)方法.read(session)的主要执行流程是readchannal-datatobuf,ifreadBytes0thenIoFilterChain.fireMessageReceived(buf)/*我们的IoHandler.messageReceived将在其中被调用*/;到此minaNio处理请求的流程已经明了.mina处理请求的线程模型也出来了,性能问题也来了,那就是在AbstractPollingIoProcessor.Processor.run--process--read(persession)中,在process的时候mina是forallselected-channals逐次readdata再fireMessageReceived到我们的IoHandler.messageReceived中,而不是并发处理,这样一来很明显后来的请求将被延迟处理.我们假设:如果NioProcessorPool'ssize=2现在有200个客户端同时连接过来,假设每个NioProcessor都注册了100个连接,对于每个NioProcessor将依次顺序处理这100个请求,那么这其中的第100个请求要得到处理,那它只有等到前面的99个被处理完了.有人提出了改进方案,那就是在我们自己的IoHandler.messageReceived中利用线程池再进行分发dispatching,这个当然是个好主意.但是请求还是被延迟处理了,因为还有readdata所消耗的时间,这样第100个请求它的数据要被读,就要等前面的99个都被读完才行,即便是增加ProcessorPool的尺寸也不能解决这个问题.此外mina的陷阱(这个词较时髦)也出来了,就是在read(session)中,在说这个陷阱之前先说明一下,我们的client端向server端发送一个消息体的时候不一定是完整的只发送一次,可能分多次发送,特别是在client端忙或要发送的消息体的长度较长的时候.而mina在这种情况下就会call我们的IoHandler.messageReceived多次,结果就是消息体被分割了若干份,等于我们在IoHandler.messageReceived中每次处理的数据都是不完整的,这会导致数据丢失,无效.下面是read(session)的源码:privatevoidread(Tsession){IoSessionConfigconfig=session.getConfig();IoBufferbuf=IoBuffer.allocate(config.getReadBufferSize());finalbooleanhasFragmentation=session.getTransportMetadata().hasFragmentation();try{intreadBytes=0;intret;try{if(hasFragmentation/*hasFragmentation一定为ture,也许mina的开发人员也意识到了传输数据的碎片问题,但是靠下面的处理是远远不够的,因为client一旦间隔发送,ret就可能为0,退出while,不完整的readBytes将被fire*/){while((ret=read(session,buf))0){readBytes+=ret;if(!buf.hasRemaining()){break;}}}else{ret=read(session,buf);if(ret0){readBytes=ret;}}}finally{buf.flip();}if(readBytes0){IoFilterChainfilterChain=session.getFilterChain();filterChain.fireMessageReceived(buf);buf=null;if(hasFragmentation){if(readBytesIoAcceptor.accept()在port上阻塞,一旦有channel就从IoSocketDispatcherPool中获取一个IoSocketDispatcher,同时构建一个IoSocketHandler和NonBlockingConnection,调用Server.LifeCycleHandler.onConnectionAccepted(ioHandler)initializetheIoSocketHandler.注意:IoSocketDispatcherPool.size默认为2,也就是说只有2条doselect的线程和相应的2个IoSocketDispatcher.这个和MINA的NioProcessor数是一样的.说明2.IoSocketDispatcher[javanioSelector]:IoSocketHandler:NonBlockingConnection------1:1:1在IoSocketDispatcher[对应一个Selector].run中---IoSocketDispatcher.handleReadWriteKeys:forallselectedKeys{IoSocketHandler.onReadableEvent/onWriteableEvent.}IoSocketHandler.onReadableEvent的处理过程如下:1.readSocket();2.NonBlockingConnection.IoHandlerCallback.onDataNonBlockingConnection.onData---appendDataToReadBuffer:readQueueappenddata3.NonBlockingConnection.IoHandlerCallback.onPostDataNonBlockingConnection.onPostData---HandlerAdapter.onData[ourdataHandler]performOnDatainWorkerPool[threadpool].因为是把channel中的数据读到readQueue中,应用程序的dataHandler.onData会被多次调用直到readQueue中的数据读完为止.所以依然存在类似mina的陷阱.解决的方法依然类似,因为这里有NonBlockingConnection.----------------------------------------------------------------------------------------------再下面以grizzly-nio-frameworkv1.9.18源码为例:tcpusagee.g:Controllersel=newController();sel.setProtocolChainInstanceHandler(newDefaultProtocolChainInstanceHandler(){publicProtocolChainpoll(){ProtocolChainprotocolChain=protocolChains.poll();if(protocolChain==null){protocolChain=newDefaultProtocolChain();//protocolChain.addFilter(ourapp'sfilter/*应用程序的处理从filter开始,类似mina.ioHandler,xSocket.dataHandler*/);//protocolChain.addFilter(newReadFilter());}returnprotocolChain;}});//如果你不增加自己的SelectorHandler,Controller就默认使用TCPSelectorHandlerport:18888sel.addSelectorHandler(ourapp'sselectorHandleronspecialport);sel.start();------------------------------------------------------------------------------------------------------------说明1.Controller:ProtocolChain:Filter------1:1:n,Controller:SelectorHandler------1:n,SelectorHandler[对应一个Selector]:SelectorHandlerRunner------1:1,Controller.start()---forperSelectorHandlerstartSelectorHandlerRunnertorun.SelectorHandlerRunner.run()---selectorHandler.select()thenhandleSelectedKeys:forallselectedKeys{NIOContext.execute:dispatchingtothreadpoolforProtocolChain.execute---ourfilter.execute.}你会发现这里没有readdatafromchannel的动作,因为这将由你的filter来完成.所以自然没有mina,xsocket它们的陷阱问题,分发提前了.但是你要注意SelectorHandler:Selector:SelectorHandlerRunner:Thread[SelectorHandlerRunner.run]都是1:1:1:1,也就是说只有一条线程在doSelectthenhandleSelectedKeys.相比之下虽然grizzly在并发性能上更优,但是在易用性方面却不如mina,xsocket,比如类似mina,xsocket中表示当前连接或会话的IoSession,INonBlockingConnection对象在grizzly中由NIOContext来负责,但是NIOContext并没有提供session/connectionlifecycleevent,以及常规的read/write操作,这些都需要你自己去扩展SelectorHandler和ProtocolFilter,从另一个方面也可以说明grizzly的可扩展性,灵活性更胜一筹.转载
javamina下载的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、javamina下载的信息别忘了在本站进行查找喔。