[ 
https://issues.apache.org/jira/browse/TRAFODION-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162334#comment-16162334
 ] 

ASF GitHub Bot commented on TRAFODION-2717:
-------------------------------------------

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

    
https://github.com/apache/incubator-trafodion/pull/1209#discussion_r138233541
  
    --- 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 --
    
    This is an issue for memory allocation failed, it doesn't mean the memory 
has been ran out. I dont think it is reasonable to exit the process instead of 
returning back the issue to the client. By the way, even we have socket 
timeout, the real issue will be hidden. whatever the issue is on server-side, 
you will always get socket timeout for every client request. Can customer 
really accept the behavior? Again, the outside CATCH is to avoid process 
exiting because of a very particular bad request. If it is a real OUT OF 
MEMORY, i mean run out the memory, absolutely the process will be exiting.  
More, OutOfMemoryError is an ERROR which not belongs to exception and will not 
be covered by EXCEPTION block. In another word, the process will exit.


> DCSMaster can't solve error data send from odbc and hang
> --------------------------------------------------------
>
>                 Key: TRAFODION-2717
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2717
>             Project: Apache Trafodion
>          Issue Type: Bug
>            Reporter: mashengchen
>            Assignee: mashengchen
>
> odbc give a wrong length for dcsmaster when do new byte[length], then throw 
> exception, but not catch it, this lead to client can't get response, and 
> dcsmaster hang.
> 2017-08-09 18:13:57,497, ERROR, 
> org.trafodion.dcs.master.listener.ListenerWorker, Node Number: , CPU: , PID: 
> , Process Name: , , ,Unexpected Exception
> java.nio.BufferUnderflowException
>         at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
>         at org.trafodion.dcs.master.listener.Util.extractString(Util.java:59)
>         at 
> org.trafodion.dcs.master.listener.ConnectionContext.extractFromByteBuffer(ConnectionContext.java:170)
>         at 
> org.trafodion.dcs.master.listener.RequestGetObjectRef.buildConnectReply(RequestGetObjectRef.java:96)
>         at 
> org.trafodion.dcs.master.listener.RequestGetObjectRef.processRequest(RequestGetObjectRef.java:61)
>         at 
> org.trafodion.dcs.master.listener.ListenerWorker.run(ListenerWorker.java:113)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to