Github user selvaganesang commented on a diff in the pull request:

    
https://github.com/apache/incubator-trafodion/pull/1209#discussion_r137416427
  
    --- Diff: 
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerWorker.java ---
    @@ -86,39 +86,43 @@ public void run() {
             DataEvent dataEvent;
         
             while(true) {
    -            // Wait for data to become available
    -            synchronized(queue) {
    -                while(queue.isEmpty()) {
    -                    try {
    -                        queue.wait();
    -                    } catch (InterruptedException e) {
    +            try {
    +                // Wait for data to become available
    +                synchronized(queue) {
    +                    while(queue.isEmpty()) {
    +                        try {
    +                            queue.wait();
    +                        } catch (InterruptedException e) {
    +                        }
                         }
    +                    dataEvent = queue.remove(0);
                     }
    -                dataEvent = queue.remove(0);
    -            }
    -            SelectionKey key = dataEvent.key;
    -            SocketChannel client = (SocketChannel) key.channel();
    -            Socket s = client.socket();
    -            ClientData clientData = (ClientData) key.attachment();
    -            ListenerService server = dataEvent.server;
    -            dataEvent.key = null;
    -            dataEvent.server = null;
    -            
    -            switch (clientData.hdr.getOperationId()){
    -                case ListenerConstants.DCS_MASTER_GETSRVRAVAILABLE:
    -                    clientData = 
requestGetObjectRef.processRequest(clientData, s);
    -                    break;
    -                case ListenerConstants.DCS_MASTER_CANCELQUERY:
    -                    clientData = 
requestCancelQuery.processRequest(clientData, s);
    -                    break;
    -                default:
    -                    clientData = requestUnknown.processRequest(clientData, 
s);
    -                    break;
    +                SelectionKey key = dataEvent.key;
    +                SocketChannel client = (SocketChannel) key.channel();
    +                Socket s = client.socket();
    +                ClientData clientData = (ClientData) key.attachment();
    +                ListenerService server = dataEvent.server;
    +                dataEvent.key = null;
    +                dataEvent.server = null;
    +
    +                switch (clientData.hdr.getOperationId()){
    +                    case ListenerConstants.DCS_MASTER_GETSRVRAVAILABLE:
    +                        clientData = 
requestGetObjectRef.processRequest(clientData, s);
    +                        break;
    +                    case ListenerConstants.DCS_MASTER_CANCELQUERY:
    +                        clientData = 
requestCancelQuery.processRequest(clientData, s);
    +                        break;
    +                    default:
    +                        clientData = 
requestUnknown.processRequest(clientData, s);
    +                        break;
    +                }
    +                // Return to sender
    +                int requestReply = clientData.requestReply;
    +                key.attach(clientData);
    +                server.send(new PendingRequest(key, requestReply));
    +            } catch (Exception e){
    +                LOG.error("Unexpected Exception", e);
    --- End diff --
    
    I am confused here. If process exit due to out of memory error can cause 
the socket to timeout exception, it should behave the same way when the process 
exits due to runtime exception too. Looking at the JIRA, it is a question of if 
we should consider java.nio.BufferUnderFlowException as a serious error that 
needs to exit the process or as an recoverable error. In general, I would think 
it is a serious error because it is derived from runtimeexception. If it is not 
an serious error, it could have been derived from IOException like any other 
read/write error.  Did the process exit when you got BufferUnderFlowException 
before this change?


---

Reply via email to