You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (Updated) (JIRA)" <ji...@apache.org> on 2011/12/16 21:50:30 UTC

[jira] [Updated] (QPID-3193) .NET Binding for Messaging classes need a test to check that binding is still in effect

     [ https://issues.apache.org/jira/browse/QPID-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chuck Rolke updated QPID-3193:
------------------------------

    Attachment: QPID-3694_lock-and-throw-preview.patch

This patch, soon to be on Review Board, is what I suggest makes sense for a single class in the .NET Binding. It fixes the 'Message' class as that has most of the variations. The highlights are:

1. A common file with a macro in it. This macro blocks entry into disposed objects.

2. An IsDisposed property to tell if your underlying object is still there. Consider it a diagnostic.

3. A mess of THROW_IF_DISPOSED calls to block access to disposed objects.

4. Some changes to object destructor and finalizer. Destructors called (C# Dispose, C++ delete) deliberately suppress GC finalization. 

WRT lock(this), I think it is the best choice. The entire Message class storage consists of a single pointer into unmanaged space. There is no finer-grained object on which to lock than 'this'.

This patch and the Review Board show one class. The intent is to do the same to all the binding classes.
                
> .NET Binding for Messaging classes need a test to check that binding is still in effect
> ---------------------------------------------------------------------------------------
>
>                 Key: QPID-3193
>                 URL: https://issues.apache.org/jira/browse/QPID-3193
>             Project: Qpid
>          Issue Type: Improvement
>    Affects Versions: 0.11
>            Reporter: Chuck Rolke
>            Assignee: Chuck Rolke
>         Attachments: QPID-3694_lock-and-throw-preview.patch
>
>
> The .NET Binding for Messaging could be made more user-friendly with the addition of a property that indicates whether or not the underlying binding is still available. A C# coder may innocently write:
> (1)  Message mA = new Message("a");
> (2)  Message mB = mA;
>      ...
> (N)  mB.Dispose();
> After disposing of message mB then message mA is clobbered. 'Message' is a 'ref class' type and messages mA and mB refer to the same object on managed heap. When message mB is disposed then the bound C++ Messaging object is deleted [1]. Any reference to the bound message part of mA will result in an illegal memory reference (to 0) and a process exit. The .NET runtime can't catch this fault.
> The obvious answer is not to do that. If the second line of code was 'Message mB = new Message(mA)' then mA and mB would have been completely separate and disposing of either would have no effect on the other.
> Another answer is to have the binding check for a null binding reference on each and every access and then to throw if the underlying binding is gone. This is not very appealing from a performance standpoint.
> As a compromise I would like to add a property isBound to each class. Users then have a fighting chance to check that the binding is still in effect and that function calls on the object shouldn't blow up. This property would be useful in Assert statements or in debugging.
> [1] If anyone knows how to have my binding library intercept example code line (2) and create reference counts, please let me know.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org