Steps to reproduce:
1. Restart MCS
2. Connect to DBRM socket
3. Send wrong packet for "readonly" command (this is format for 6.2.2+ MCS versions with extra 4 bytes for longstrings count (b'7\xc1\xfb\x14\x01\x00\x00\x00\x00\x00\x00\x00\x14')
4. No response exists

After that in next 4min 50sec any try to send correct packet for the "set_readonly" command (b'7\xc1\xfb\x14\x01\x00\x00\x00\x0e') would have no answer (same to "set_readwrite" command)
Reconnect have no affect on this but if trying to send correct (for MCS 5.x.x versions) "readonly" command (b'7\xc1\xfb\x14\x01\x00\x00\x00\x14') right after reconnect to socket, the answer exist as expected.
BUT if trying to send ANY command after sending correct "set_readonly" command, there are no answer on it too.

Roughly 4 min 50 sec after this message appears in MCS debug.log file:

DBRM Controller: Network error reading from node 1.  Reading response to command 0, length 1.  0 length response, possible time-out.  Will see if retry is possible.

InetStreamSocket::readToMagic(): I/O error1: rc-1; poll signal interrupt ( POLLHUP POLLERR )

After that everything works as expected even if trying to reproduce this steps.
Except no answer in the same connection while trying to send ANY command after sending INcorrect "set_readonly" command.

Steps below reproduces only at first MCS 5.x.x start.

Looks like there are kind a lock for any DBRM command that changes state, cause command for reading state still working.

Tested on the latest (5.6.1) and the previous version of MCS.