[
https://issues.apache.org/jira/browse/QPID-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536166
]
Rafael H. Schloming commented on QPID-653:
------------------------------------------
It might be nice to use a configurable parameter for all of our timeouts that
included the option to test with a blocking receive(). I was recently debugging
some issues with synchronous receive() and I ended up switching one or two
blocking receives() to non blocking receives() in order to avoid hangs on
failure. While this was quite helpful for my debugging, it also occurs to me
that the logical extension of this behavior is that we will never end up
testing the code paths for blocking receive(). In fact this may well be the
case now since I think those may have been the last few test cases where we
used blocking receive().
> Timeouts in tests causing spurious failures on slower machines
> --------------------------------------------------------------
>
> Key: QPID-653
> URL: https://issues.apache.org/jira/browse/QPID-653
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client, Java Tests
> Affects Versions: M2, M2.1
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: M2, M2.1
>
>
> Timeouts on receive expire on slower machine without message arriving,
> causing failure.
> These timeouts can be increased without slowing tests as the normal case is
> the message will be delivered rather than the timeout expiring.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
