You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org> on 2008/02/29 16:08:51 UTC
[jira] Created: (QPID-825) Intermittent failures in
ChannelCloseTest
Intermittent failures in ChannelCloseTest
-----------------------------------------
Key: QPID-825
URL: https://issues.apache.org/jira/browse/QPID-825
Project: Qpid
Issue Type: Bug
Reporter: Rafael H. Schloming
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.
[jira] Updated: (QPID-825) Intermittent failures in
ChannelCloseTest
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ 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.
[jira] Commented: (QPID-825) Intermittent failures in
ChannelCloseTest
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574417#action_12574417 ]
Arnaud Simon commented on QPID-825:
-----------------------------------
I believe this is fixed with M2.1. So I suggest we complete the merge and check that this issue is fixed (the merge should be completed very soon, I hope).
> Intermittent failures in ChannelCloseTest
> -----------------------------------------
>
> Key: QPID-825
> URL: https://issues.apache.org/jira/browse/QPID-825
> Project: Qpid
> Issue Type: Bug
> Reporter: Rafael H. Schloming
>
> 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.
[jira] Resolved: (QPID-825) Intermittent failures in
ChannelCloseTest
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-825.
---------------------------------
Resolution: Fixed
This has been addressed as part of the recent QPID-940 fixes.
> 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.