You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org> on 2008/06/25 13:21:45 UTC
[jira] Updated: (QPID-825) Intermittent failures in
ChannelCloseTest
[ https://issues.apache.org/jira/browse/QPID-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-825:
-------------------------------
Component/s: Java Client
Affects Version/s: M3
Fix Version/s: M3
Assignee: Rafael H. Schloming
This is probably still a problem, our exception handling sucks.
> Intermittent failures in ChannelCloseTest
> -----------------------------------------
>
> Key: QPID-825
> URL: https://issues.apache.org/jira/browse/QPID-825
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M3
> Reporter: Rafael H. Schloming
> Assignee: Rafael H. Schloming
> Fix For: M3
>
>
> I'm seeing intermittent failures for ChannelCloseTest. I believe this is due to a race condition in BlockingMethodFrameListener.java where one error notification can clobber another one. I believe this has been fixed on M2.1. This error is difficult to track down because BlockingMethodFrameListener.java rethrows the _error variable without taking any measures to log or otherwise indicate the stack trace in the blocking thread, and the resulting stack trace from the thread where the exception originated is of little use.
> It would be good to somehow address the latter issue by wrapping _error prior to throwing it, or at least logging the real stack trace.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.