[jira] [Created] (QPIDJMS-124) improve error handling when using the test peer

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

Robbie Gemmell created QPIDJMS-124:
--------------------------------------

             Summary: improve error handling when using the test peer
                 Key: QPIDJMS-124
                 URL: https://issues.apache.org/jira/browse/QPIDJMS-124
             Project: Qpid JMS
          Issue Type: Test
          Components: qpid-jms-client
    Affects Versions: 0.6.0
            Reporter: Robbie Gemmell
            Assignee: Robbie Gemmell
             Fix For: 0.7.0


We have a test peer that can be used to run the client against for integration tests without a broker. There are improvements that could be made to the test output in various error scenarios:

- If an unexpected type of frame is encountered, the peer logs out what frame it expected next and the descriptor etc of what it actually received. This is typically the ulong code descriptor, so it would be useful if the matching symbolic descriptor was also logged to avoid developers having to look it up or know all the descriptor codes.
- In scenarios such as the above, or other general exceptions, the peers read loop exits. If the client is performing a synchronous op this typically means the test times out and that will be the test issue reported, and It is then necessary to loog at the logs to identify the underlying cause. This can be problematic in some CI environments, e.g. those running via the GitHub mirror. If the peer sent a Close frame in this sccenario with the error details, then in many cases a client exception would result and be reported instead (also avoiding the wait for the test to timeout), providing more detail and hopefully reducing/removing the need for the logs.
- In some cases, within a test, we want to wait for the peer to finish all its current handlers before proceeding to a further set of operations. If an issue occurs that prevents this happening, only the fact that they werent completed in time will currently be reported, requiring the lgos for further analysis. If the peers processing loop has caught an exception, this should be reported as a possible reason for the failure, providing potential cause details without needing to go to the logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org