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的可擴展性,靈活性更勝一籌.轉載