[
https://issues.apache.org/jira/browse/QPIDJMS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPIDJMS-124.
------------------------------------
Resolution: Fixed
> 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: [email protected]
For additional commands, e-mail: [email protected]
