• Home
• org.apache.mina
• mina-integration-xbean
• 2.2.1
• source code

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

na.mina-integration-xbean.2.2.1.source-code.mina-integration-xbean.xsd Maven / Gradle / Ivy

  
  
    
      
    
    
      
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      
    
    
      
        
          
            
          
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      
However, the identical interface doesn't mean that it behaves in an exactly
same way with {@link IoFilterChain}. {@link DefaultIoFilterChainBuilder}
doesn't manage the life cycle of the {@link IoFilter}s at all, and the
existing {@link IoSession}s won't get affected by the changes in this builder.
{@link IoFilterChainBuilder}s affect only newly created {@link IoSession}s.

IoAcceptor acceptor = ...;
DefaultIoFilterChainBuilder builder = acceptor.getFilterChain();
builder.addLast( "myFilter", new MyFilter() );
...

      ]]>
    
    
      
        
          
            
          
          
            
              
              
            
          
        
        
          
            
          
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      ErrorGeneratingFilter egf = new ErrorGeneratingFilter();
For activate the change of some bytes in your {@link IoBuffer}, for a probability of 200 out
of 1000 {@link IoBuffer} processed :
egf.setChangeByteProbability(200);
For activate the insertion of some bytes in your {@link IoBuffer}, for a
probability of 200 out of 1000 :
egf.setInsertByteProbability(200);
And for the removing of some bytes :
egf.setRemoveByteProbability(200);
You can activate the error generation for write or read with the
following methods :
egf.setManipulateReads(true);
egf.setManipulateWrites(true); 
      ]]>
    
    
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      Life Cycle Management

Please note that this filter doesn't manage the life cycle of the {@link Executor}.
If you created this filter using {@link #ExecutorFilter(Executor)} or similar
constructor that accepts an {@link Executor} that you've instantiated, you have
full control and responsibility of managing its life cycle (e.g. calling
{@link ExecutorService#shutdown()}.

If you created this filter using convenience constructors like
{@link #ExecutorFilter(int)}, then you can shut down the executor by calling
{@link #destroy()} explicitly.

Event Ordering

All convenience constructors of this filter creates a new
{@link OrderedThreadPoolExecutor} instance. Therefore, the order of event is
maintained like the following:

All event handler methods are called exclusively.
(e.g. messageReceived and messageSent can't be invoked at the same time.)
The event order is never mixed up.
(e.g. messageReceived is always invoked before sessionClosed or messageSent.)

However, if you specified other {@link Executor} instance in the constructor,
the order of events are not maintained at all. This means more than one event
handler methods can be invoked at the same time with mixed order. For example,
let's assume that messageReceived, messageSent, and sessionClosed events are
fired.

All event handler methods can be called simultaneously.
(e.g. messageReceived and messageSent can be invoked at the same time.)
The event order can be mixed up.
(e.g. sessionClosed or messageSent can be invoked before messageReceived
is invoked.)

If you need to maintain the order of events per session, please specify an
{@link OrderedThreadPoolExecutor} instance or use the convenience constructors.

Selective Filtering

By default, all event types but sessionCreated, filterWrite,
filterClose and filterSetTrafficMask are submitted to the
underlying executor, which is most common setting.

If you want to submit only a certain set of event types, you can specify them
in the constructor. For example, you could configure a thread pool for
write operation for the maximum performance:

IoService service = ...;
DefaultIoFilterChainBuilder chain = service.getFilterChain();

chain.addLast("codec", new ProtocolCodecFilter(...));
// Use one thread pool for most events.
chain.addLast("executor1", new ExecutorFilter());
// and another dedicated thread pool for 'filterWrite' events.
chain.addLast("executor2", new ExecutorFilter(IoEventType.WRITE));


Preventing {@link OutOfMemoryError}

Please refer to {@link IoEventQueueThrottle}, which is specified as
a parameter of the convenience constructors.
      ]]>
    
    
      
        
          
            
          
          
            
              
              
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      
    
    
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      Normall {@code FileRegion} objects should be handled by the
{@link org.apache.mina.core.service.IoProcessor} but this is not always possible
if a filter is being used that needs to modify the contents of the file
before sending over the network (i.e. the
{@link org.apache.mina.filter.ssl.SslFilter} or a data compression filter.)

 This filter will ignore written messages which aren't {@link FileRegion}
instances. Such messages will be passed to the next filter directly.

NOTE: this filter does not close the file channel in
{@link FileRegion#getFileChannel()} after the data from the file has been
written. The {@code FileChannel} should be closed in either
{@link org.apache.mina.core.service.IoHandler#messageSent(IoSession,Object)}
or in an {@link org.apache.mina.core.future.IoFutureListener} associated with the
{@code WriteFuture}.

      ]]>
    
    
      
        
          
        
      
      
      
    
  


  
  
    
      Interference with {@link IoSessionConfig#setIdleTime(IdleStatus, int)}

This filter adjusts idleTime of the {@link IdleStatus}s that
this filter is interested in automatically (e.g. {@link IdleStatus#READER_IDLE}
and {@link IdleStatus#WRITER_IDLE}.) Changing the idleTime
of the {@link IdleStatus}s can lead this filter to a unexpected behavior.
Please also note that any {@link IoFilter} and {@link IoHandler} behind
{@link KeepAliveFilter} will not get any {@link IoEventType#SESSION_IDLE}
event. To receive the internal {@link IoEventType#SESSION_IDLE} event,
you can call {@link #setForwardEvent(boolean)} with true.

Implementing {@link KeepAliveMessageFactory}

To use this filter, you have to provide an implementation of
{@link KeepAliveMessageFactory}, which determines a received or sent
message is a keep-alive message or not and creates a new keep-alive
message:



Name
Description
Implementation


Active

You want a keep-alive request is sent when the reader is idle.
Once the request is sent, the response for the request should be
received within keepAliveRequestTimeout seconds. Otherwise,
the specified {@link KeepAliveRequestTimeoutHandler} will be invoked.
If a keep-alive request is received, its response also should be sent back.


Both {@link KeepAliveMessageFactory#getRequest(IoSession)} and
{@link KeepAliveMessageFactory#getResponse(IoSession, Object)} must
return a non-null.



Semi-active

You want a keep-alive request to be sent when the reader is idle.
However, you don't really care if the response is received or not.
If a keep-alive request is received, its response should
also be sent back.


Both {@link KeepAliveMessageFactory#getRequest(IoSession)} and
{@link KeepAliveMessageFactory#getResponse(IoSession, Object)} must
return a non-null, and the timeoutHandler property
should be set to {@link KeepAliveRequestTimeoutHandler#NOOP},
{@link KeepAliveRequestTimeoutHandler#LOG} or the custom {@link KeepAliveRequestTimeoutHandler}
implementation that doesn't affect the session state nor throw an exception.



Passive

You don't want to send a keep-alive request by yourself, but the
response should be sent back if a keep-alive request is received.


{@link KeepAliveMessageFactory#getRequest(IoSession)} must return
null and {@link KeepAliveMessageFactory#getResponse(IoSession, Object)}
must return a non-null.



Deaf Speaker

You want a keep-alive request to be sent when the reader is idle, but
you don't want to send any response back.


{@link KeepAliveMessageFactory#getRequest(IoSession)} must return
a non-null,
{@link KeepAliveMessageFactory#getResponse(IoSession, Object)} must
return null and the timeoutHandler must be set to
{@link KeepAliveRequestTimeoutHandler#DEAF_SPEAKER}.



Silent Listener

You don't want to send a keep-alive request by yourself nor send any
response back.


Both {@link KeepAliveMessageFactory#getRequest(IoSession)} and
{@link KeepAliveMessageFactory#getResponse(IoSession, Object)} must
return null.




Please note that you must implement
{@link KeepAliveMessageFactory#isRequest(IoSession, Object)} and
{@link KeepAliveMessageFactory#isResponse(IoSession, Object)} properly
whatever case you chose.

Handling timeout

{@link KeepAliveFilter} will notify its {@link KeepAliveRequestTimeoutHandler}
when {@link KeepAliveFilter} didn't receive the response message for a sent
keep-alive message. The default handler is {@link KeepAliveRequestTimeoutHandler#CLOSE},
but you can use other presets such as {@link KeepAliveRequestTimeoutHandler#NOOP},
{@link KeepAliveRequestTimeoutHandler#LOG} or {@link KeepAliveRequestTimeoutHandler#EXCEPTION}.
You can even implement your own handler.

Special handler: {@link KeepAliveRequestTimeoutHandler#DEAF_SPEAKER}

{@link KeepAliveRequestTimeoutHandler#DEAF_SPEAKER} is a special handler which is
dedicated for the 'deaf speaker' mode mentioned above. Setting the
timeoutHandler property to {@link KeepAliveRequestTimeoutHandler#DEAF_SPEAKER}
stops this filter from waiting for response messages and therefore disables
response timeout detection.
      ]]>
    
    
      
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
      
      
        
          false.
          ]]>
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      
    
    
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
    
  


  
  
    
      
    
    
      
        
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
              
              
            
          
        
        
          
            
          
          
            
              
              
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
              
              
            
          
        
        
      
      
        
          
        
      
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
      
    
  


  
  
    
      
If you don't need to maintain the order of events per session, please use
{@link UnorderedThreadPoolExecutor}.
      ]]>
    
    
      
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
        
          
        
      
      
      
    
  


  
  
    
      
If you don't need to maintain the order of events per session, please use
{@link UnorderedThreadPoolExecutor}.

If you don't need to prioritize sessions, please use
{@link OrderedThreadPoolExecutor}.
      ]]>
    
    
      
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
          
            
          
        
        
          
            
          
        
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
        
          
        
      
      
      
        
          
        
      
      
      
    
  


  
  
    
      
ProfilerTimerFilter profiler = new ProfilerTimerFilter(TimeUnit.MILLISECOND, IoEventType.MESSAGE_RECEIVED);
chain.addFirst("Profiler", profiler);

• IoEventType.MESSAGE_RECEIVED
• IoEventType.MESSAGE_SENT
• IoEventType.SESSION_CREATED
• IoEventType.SESSION_OPENED
• IoEventType.SESSION_IDLE
• IoEventType.SESSION_CLOSED