title: does quickfix respond to testrequest messages automaticially?
body: <p>I have a quickfix application that occasionally according to the FIX logs sends out testrequest messages, and the counterpart always responds. tag112 set equal to tag112 of originating message.  </p>
  
  <p>When it recieves a testrequest message from the counterparty, there is no record of a heartbeat response in the fixlog and the connection is dropped.</p>
  
  <p>Annoyingly, the application seems to go into a cycle of failing to connect and failing until the application is restarted, when it reconnects instantly.</p>
  
  <p>What possibilities are there for the test request being replied to incorrectly, or an application state such that a restart would make a difference?</p>
  
  <p><strong><em>EDIT</em></strong></p>
  
  <p>curiouser this gets. The message log shows nothing beyond what I described in the question</p>
  
  <p>the event log reads</p>
  
  <pre><code>20160103-21:06:14.807 : Connecting to 127.0.0.1 on port xxxxx
  20160103-21:06:14.810 : Initiated logon request
  20160103-21:06:14.871 : Received logon response
  20160104-00:39:34.003 : IO Error: Unable to flush file /tmp/FIX.4.4-xxxxxxxxxx.body
  20160104-00:39:49.670 : IO Error: Unable to write to file /tmp/FIX.4.4-xxxxxxxxxx.body
  20160104-00:40:16.671 : Socket Error: Connection reset by peer.
  20160104-00:40:16.671 : Disconnecting
  20160104-00:40:29.194 : Connecting to 127.0.0.1 on port xxxxx
  20160104-00:40:29.195 : IO Error: Cannot seek to end of /tmp/FIX.4.4-xxxxxxxxxx.body
  20160104-00:40:29.195 : Initiated logon request
  20160104-00:40:39.539 : Timed out waiting for logon response
  20160104-00:40:39.539 : Disconnecting
  20160104-00:40:39.540 : IO Error: Unable to write to file /tmp/FIX.4.4-xxxxxxxxxx.body
  </code></pre>
  
  <p>This loop continues until the application is restarted. There is no shortage of hard disk space, there is obviously no file permission issue or the restart wouldn't help - yet for some reason quickfix very occasionally ends up unable to write to it's own log file.</p>
  
  <p><strong><em>EDIT</em></strong></p>
  
  <p>The only clue so far is that the last message in the log file, coincides with the IO error, to the same millisecond.  So far, moving the message log off /tmp seems to have solved it - though it doesn't explain why the IO error was thrown, or why quickfix is unable to recover from this. I'm guessing the messagestorefactory would need to be recreated if it can't recover from an IO error.</p>