1. javaweb怎么整合mina

1. 浏览器驱动Ext 向Web服务器发出请求

2. Web服务器由Struts处理请求
3. Struts处理请求的过程中通过Mina客户端，向Mina服务器发出请求
4. Mina服务器处理请求，向web服务器返回请求
5. web服务器通过Mina客户端获取返回值，通过Struts将返回值返回给浏览器
6. Ext接收返回值，在浏览器上显示

2. Java Mina通讯框架中，假如我的通讯协议里传的是：十六进制的数据，编码解码的时候用哪种方式

自己写个解码器好了
实现一个 ProtocolCodecFactory 这个可以网上查
解码继承 CumulativeProtocolDecoder
我用byte方式传送 接收的是 mina的 IoBuffer
用以下函数 转成 byte 数组
public static byte [] ioBufferToByte(Object message)
{
if (!(message instanceof IoBuffer))
{
return null;
}
IoBuffer ioBuffer = (IoBuffer)message;
ioBuffer.flip();
byte[] readByte = new byte[ioBuffer.limit()];
try
{
ioBuffer.get(readByte);
}
catch (Exception e)
{
System.out.println(e.toString());
}
return readByte;
}

在解码器里
private IoBuffer buff = IoBuffer.allocate(300).setAutoExpand(true);

while (in.hasRemaining()) {
byte b = in.get();
buff.put(b);

}
byte[] tmpByteArr = Utils.ioBufferToByte(buff); //将所有IoBuffer数据转为byte数组

3. 初学java mina架构，先收到messageReceived事件 后收到sessionOpened事件 下面贴出了输出日志

日志的输出，不能100%判断先后 。。。。。。。。

4. apache mina可以做什么

Apache的Mina（Multipurpose Infrastructure Networked Applications）是一个网络应用框架，可以帮助用户开发高性能和高扩展性的网络应用程序；它提供了一个抽象的、事件驱动的异步API，使Java NIO在各种传输协议（如TCP/IP，UDP/IP协议等）下快速高效开发。
Apache Mina也称为：
NIO框架
网络套接字（networking socket）类库
事件驱动的异步API(注意：在JDK7中也新增了异步API)
总之：简单理解它是一个封装底层IO操作，提供高级操作API的通讯框架！

5. java mina可以实现http server吗

erver端的Session实现通常是通过在Server端为请求的客户分配SessionID实现的，然后把SessionID号发送给client端，client端把这个SessionID记录下来，这里一般是通过Cookie记录，如果Cookie禁用掉的话就得通过URL重写的方式了，这样

6. java mina接收与发送字节数组(byte[])

要自己根据发送的数据包格式写一个过滤器 ，或者将发送的数据包封装成对象再发送。

7. java mina(2.x)文件双向传输

你得想法应该是这样吧：将用户传的文件传给服务器，然后服务器接受（有一个接受文版件权），然后将接受文件处理，（再存储成一个文件），第二个文件传回用户端。我感觉你可以上网搜一个上传图片的一个处理过程看一下，这个过程也是io处理，你得问题在第二部，那么你应该是在第二部读取文件的时候出问题了。你先尝试下不经过处理的文件传输回去，然后再改下对象试试。


8. java mina 怎么打成jar包放在服务器上呀~~

打开记事本输入
Manifest-Version: 1.0
Main-Class: xxx
其中 xxx 是你 public static void main 所在的class
然后另存为 1.mf

接着在你class所在的文件夹下 进行打专包

jar -cvmf 1.mf 输出名.jar *.class

这样当前属文件夹下的所有class都被打包了起来

你双击那个.jar包 就可以运行了

如果使用了package 别忘了加前缀

9. java mina 可以多线程写么

MINA,Grizzly[grizzly-nio-framework],xSocket都是基于javanio的ork.这里的性能缺陷的焦点是指当一条channel上的SelectionKey.OP_READready时,1.是由selectthread读完数据之后再分发给应用程序的handler,2.还是直接就分发,由handlerthread来负责读数据和handle.mina,xsocket是1.grizzly-nio-framework是2.尽管读channelbuffer中bytes是很快的,但是如果我们放大,当连接channel达到上万数量级,甚至,这种延迟响应的效果将会愈加明显.MINA:forallselectedKeys{.}xSocket:forallselectedKeys{readdata,.}其中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(selected>0){process();}}process()-->forallsession-channal:OP_READ-->read(session):这个read方法是AbstractPollingIoProcessor.privatevoidread(Tsession)方法.read(session)的主要执行流程是readchannal-datatobuf,ifreadBytes>0thenIoFilterChain.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(ret>0){readBytes=ret;}}}finally{buf.flip();}if(readBytes>0){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..onPostData--->HandlerAdapter.onData[ourdataHandler]performOnDatainWorkerPool[threadpool].因为是把channel中的数据读到readQueue中,应用程序的dataHandler.onData会被多次调用直到readQueue中的数据读完为止.所以依然存在类似mina的陷阱.解决的方法依然类似,因为这里有NonBlockingConnection.----------------------------------------------------------------------------------------------再下面以grizzly-nio-frameworkv1.9.18源码为例:tcpusagee.g:Controllersel=newController();sel.((){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()--->.SelectorHandlerRunner.run()--->selectorHandler.select()thenhandleSelectedKeys:forallselectedKeys{NIOContext.execute:.execute--->ourfilter.execute.}你会发现这里没有readdatafromchannel的动作,因为这将由你的filter来完成.所以自然没有mina,xsocket它们的陷阱问题,分发提前了.但是你要注意SelectorHandler:Selector:SelectorHandlerRunner:Thread[SelectorHandlerRunner.run]都是1:1:1:1,也就是说只有一条线程在.相比之下虽然grizzly在并发性能上更优,但是在易用性方面却不如mina,xsocket,比如类似mina,xsocket中表示当前连接或会话的IoSession,INonBlockingConnection对象在grizzly中由NIOContext来负责,但是NIOContext并没有提供session/connectionlifecycleevent,以及常规的read/write操作,这些都需要你自己去扩展SelectorHandler和ProtocolFilter,从另一个方面也可以说明grizzly的可扩展性,灵活性更胜一筹.转载