Resolution:
The following two scenarios may lead to this behavior.
 
1). Assuming the client is connected to EMS using a FT URL (comma separated URL). After receive() is called but before it returns, the client has lost connection to the EMS server either because of a network issue or the EMS server has restarted. When this happens, the internal reconnect mechanism of the EMS client library will kick in until the connection is reconnected or all reconnect attempts are used. If no connections can be made, the receive call will not return.
 
2). The same client is calling another JMS API in another thread just before the receive() is called, using the same session that is used for the consumer. If that call is blocked, the blocking time will add to the receive() call, that is, until this other call finishes the clock will not start for receive (int timeout). For example, in the case below, you call session.createProducer(), which say takes five seconds to return. Then the receive() will only return after six seconds assuming there are no pending messages on the queue.

============= Begin Code Sample =============
    long start = System.currentTimeMillis();
        Thread t = new Thread(){
            public void run(){
                try {
                    session.createProducer(null);
                } catch (JMSException e) {
                    e.printStackTrace();
                }
            }
        };
        t.start();
        msg = msgConsumer.receive(1000);

============= End Code Sample =============

MessageConsumer received with timeout [receive (int timeout)] does not return after the timeout has elapsed.