Java ErrorListener类代码示例

import com.jme3.network.ErrorListener; //导入依赖的package包/类
public ConnectorAdapter( Connector connector, MessageListener<Object> dispatcher, 
                         ErrorListener<Object> errorHandler, boolean reliable )
{
    super( String.valueOf(connector) );
    this.connector = connector;        
    this.dispatcher = dispatcher;
    this.errorHandler = errorHandler;
    this.reliable = reliable;
    setDaemon(true);        
    writer = Executors.newFixedThreadPool(1, 
                        new NamedThreadFactory(String.valueOf(connector) + "-writer", true));
}
 

import com.jme3.network.ErrorListener; //导入依赖的package包/类
public ConnectorAdapter( Connector connector, MessageListener<Object> dispatcher, 
                         ErrorListener<Object> errorHandler, boolean reliable )
{
    super( String.valueOf(connector) );
    this.connector = connector;        
    this.dispatcher = dispatcher;
    this.errorHandler = errorHandler;
    this.reliable = reliable;
    setDaemon(true);
 
    // The backlog makes sure that the outbound channel blocks once
    // a certain backlog level is reached.  It is set high so that it
    // is only reached in the worst cases... which are usually things like
    // raw throughput tests.  Technically, a saturated TCP channel could
    // back up quite a bit if the buffers are full and the socket has
    // stalled but 16,000 messages is still a big backlog.       
    outbound = new ArrayBlockingQueue<ByteBuffer>(OUTBOUND_BACKLOG); 
 
    // Note: this technically adds a potential deadlock case
    // with the above code where there wasn't one before.  For example,
    // if a TCP outbound queue fills to capacity and a client sends
    // in such a way that they block TCP message handling then if the HostedConnection
    // on the server is similarly blocked then the TCP network buffers may
    // all get full and no outbound messages move and we forever block
    // on the queue.
    // However, in practice this can't really happen... or at least it's
    // the sign of other really bad things.
    // First, currently the server-side outbound queues are all unbounded and
    // so won't ever block the handling of messages if the outbound channel is full.
    // Second, there would have to be a huge amount of data backlog for this
    // to ever occur anyway.
    // Third, it's a sign of a really poor architecture if 16,000 messages
    // can go out in a way that blocks reads. 
    
    writer = new WriterThread();
    writer.start();                                           
}