[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879897#action_12879897
]
Chuck Rolke commented on QPID-2589:
---
> If I add the following to the map example:
>
> byte[] myBytes = new byte[3] { 102, 111, 111};
> content["myBytes"] = byBytes;
>
> I get a NotImplementedException. Is this a known todo item?
In today's code the following mapping is in place:
amqp/map - Dictionary
amqp/list - Collection
The syntax you are trying to use is not yet supported. To get your data into
the map try:
byte[] myBytes = new byte[3] { 102, 111, 111};
Collection cBytes = new Collection();
for (int i=0; i, where object
items are supported primitive types, gets converted into a C++ Variant::List,
and then into an amqp/list to the broker.
The syntax you are trying is a fluent way of expressing a list at least for
data going into a message and should be considered for inclusion in the message
encoder. For received messages, though, the Collection works better as
items in an amqp/list may be of mixed types.
> Add a .NET binding to QPID Messaging API
>
>
> Key: QPID-2589
> URL: https://issues.apache.org/jira/browse/QPID-2589
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Client
>Affects Versions: 0.7
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.7
>
> Attachments: cpp_binding_dotnet.patch,
> cpp_bindings_qpid_dotnet__cleanup.patch,
> cpp_bindings_qpid_dotnet_update.patch,
> cpp_bindings_qpid_dotnet_vb-helloworld-uuid.patch, map_receiver_update.patch,
> qpid_add_x86_platform.patch, qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging
> interface. It exposes the Messaging interface through a series of managed
> code classes that may be used by any .NET language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879834#action_12879834
]
Cliff Jansen commented on QPID-2589:
If I add the following to the map example:
byte[] myBytes = new byte[3] { 102, 111, 111};
content["myBytes"] = byBytes;
I get a NotImplementedException. Is this a known todo item?
Presumably the dotnet map implementation is intended to interoperate with the
Java MapMessage, including distinguishing between getBytes(), getString() [ and
setBytes(), setString()].
> Add a .NET binding to QPID Messaging API
>
>
> Key: QPID-2589
> URL: https://issues.apache.org/jira/browse/QPID-2589
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Client
>Affects Versions: 0.7
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.7
>
> Attachments: cpp_binding_dotnet.patch,
> cpp_bindings_qpid_dotnet__cleanup.patch,
> cpp_bindings_qpid_dotnet_update.patch,
> cpp_bindings_qpid_dotnet_vb-helloworld-uuid.patch, map_receiver_update.patch,
> qpid_add_x86_platform.patch, qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging
> interface. It exposes the Messaging interface through a series of managed
> code classes that may be used by any .NET language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868631#action_12868631 ] Gordon Sim commented on QPID-2589: -- > A better pattern for high performance WCF would be to be able to register for > notification of various events, such as message arrival, command completion > (for message send and dtxFoo) that arrive in the context of the > Windows IO completion port thread that the socket implementation manages. > This may matter much less on Linux, but I expect there would still be a class > of developers who would appreciate some form of event > notification. Agreed; better integration into event loops is certainly important and the API will be extended for that. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: cpp_binding_dotnet.patch, map_receiver_update.patch, > qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868362#action_12868362 ] Cliff Jansen commented on QPID-2589: Thank-you Gordon for turning your mind to this. > You would still want a way to wait for changes to the unsettled list. Much better would be an event notification, see below. But otherwise, that plus "sender.getUnsettled() > x" should do the trick. > However I don't think the messaging API is any worse in this respect > than the old 0-10 API which required either busy-polling or syncing. Well, the WCF channel uses Future.wait() which is better than either of those options. Even that strategy was criticized during WCF design meetings at Microsoft as "wasting" a thread resource for each session that witnessed async writes (imagining an application that might simultaneously be servicing 100's or thousands of sessions). A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event notification. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: cpp_binding_dotnet.patch, map_receiver_update.patch, > qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868317#action_12868317 ] Gordon Sim commented on QPID-2589: -- Re implementing "WCF's BeginSend for asynchronous writes", one suggestion for that is to maintain a counter for each sender tracking the messages sent. The AsyncResult for a BeginSend would then include the value of the counter for that send, lets call it x. If for any given send, counter - sender.getUnsettled() > x, that send has completed. Does that sound workable? You would still want a way to wait for changes to the unsettled list. The desire to improve the general threading by adding some generic mechanisms like this has been discussed and should be a future focus for the messaging API. However I don't think the messaging API is any worse in this respect than the old 0-10 API which required either busy-polling or syncing. Note also that with the messaging API the replaying of messages would be part of the underlying functionality. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: cpp_binding_dotnet.patch, map_receiver_update.patch, > qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867271#action_12867271 ] Ted Ross commented on QPID-2589: Expanding on my last comment... The .net code in this binding should never add any "messaging" value to the API. If we want to add new features, they should first be added to the C++ messaging API and then reflected through this binding. Also, with regard to the location of this code... The "bindings" directory under qpid/cpp is intended to hold other-language bindings to C++ interfaces. We might want to eventually supply messaging bindings for Python, Ruby, Perl, PHP, etc. so that these interfaces can be more easily supported and can benefit from the features and performance of the C++ API. -Ted > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: cpp_binding_dotnet.patch, qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867268#action_12867268 ] Ted Ross commented on QPID-2589: >> I noticed that the binding lives inside the cpp dir. >> I would assume this is temporary and that it will eventually be moved out to >> a suitable location? Actually, I claim that this is where it belongs. This contribution is simply a .NET binding to the C++ messaging API. It allows .net applications in C#, VB, etc. to access the messaging API. No more, no less. The advantage of this contribution is that it is very supportable because it leverages the C++ client and adds very little logic. It is not in the same category as the WCF code which is adding a large amount of useful functionality on top of messaging. It will, hopefully, make the qpid/dotnet API obsolete. -Ted > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: cpp_binding_dotnet.patch, qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867237#action_12867237 ] Cliff Jansen commented on QPID-2589: > Dictionary content = new Dictionary(); [...] > List colors = new List(); [...] > Do you think Dictionary and List objects are the best choices? The C++ implementation is more stringent. To match it more closely in semantics, I wonder whether you mean to use AmqpType instead of "object" above, or create a new Class named Variant to match the C++ implementation. I think AmqpType is the more descriptive name, but consistent naming across clients may be the more important goal here. Otherwise I think you definitely want to use Dictionaries and Lists. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867223#action_12867223 ] Gordon Sim commented on QPID-2589: -- > I see the nextReceiver() call, but as I see it, this requires a dedicated > thread per Session to poll for the client's next message, whereas the 0-10 > allowed a single thread or small pool to service the handed off message from > all sessions. Actually I don't think that is correct, the old 0-10 API also required a thread per session, at least at the c++ level. However going forward we do want to change that. One of the problems was the lack of support from the old client (in those parts on which the new client was built). I'll work through your examples on async send above, thanks for posting them! > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867219#action_12867219 ] Cliff Jansen commented on QPID-2589: A timeout for send() (to match get() and fetch()) would be useful to WCF since the call can block. Does this seem useful in general? Is there an async receive existing or planned like the older MessageListener? I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867218#action_12867218 ] Cliff Jansen commented on QPID-2589: One problem is implementing WCF's BeginSend for asynchronous writes. There are three ways of using them, two shown here: // nothing blocks IOutputChannel myChannel; AsyncCallback sendCallback = new AsyncCallback(this.MyCallback); // ... for (i=0; isend(mtcmd, *framesetp)); If there is exception or connection drop, the Future preserves information to know which messages succeeded and which ones failed. WcfPerftest with a million messages and a million separate thread instances would not be pretty, even if they come from a thread pool. Looking through the existing WCF implementation, the only other Futures that are used are for XaResults from the various dtx commands. It would be nice to be able to preserve the async nature for these in the new API going forward. I think any resource manager would want to have this capability. > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866533#action_12866533 ] Gordon Sim commented on QPID-2589: -- > The major outages are dtx support and message body content optimizations (one > time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not > uncommon scenario). These are certainly gaps we would want to address in the messaging API and its implementation. > Off the top of my head, I also worry about the limited async functionality. > The current WCF implementation relies heavily on async related classes in the > old API, such as Future and Completion. I'd be keen to explore these worries in some more detail. Could we tackle one or two concrete cases to begin with? > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866530#action_12866530
]
Cliff Jansen commented on QPID-2589:
> Would it be possible to build the WCF (channel and service
> interfaces) on top of this API?
Well, no. But that is the same answer for the old 0-10 client code and,
nevertheless, the WCF channel uses that for 95% of its work and sneaks around
it for some additional functionality.
In the end, this new API is *much* less rich, which means the WCF channel may
have to work much harder behind the scenes to get its work done. But that
still may be the right balance. The API should be true to the target developer
base first - how many need to be transaction resource managers or perftest
stars?
The major outages are dtx support and message body content optimizations (one
time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not
uncommon scenario).
Off the top of my head, I also worry about the limited async functionality.
The current WCF implementation relies heavily on async related classes in the
old API, such as Future and Completion. Their absence in this API is not fatal
("just" run another thread to block on a session.sync(true)), but reduces
options for performance optimizations. The current WCF implementation is
impressively speedy and it would be sad to handicap it.
I would be most happy to see things evolve so that the messaging API becomes a
libc-ish entity that can work in an application that simultaneously uses
kernel-ish functionality for finer grained capabilities (without pulling the
rug out from under libc). I am all for keeping the "Advanced" in AMQP.
> Add a .NET binding to QPID Messaging API
>
>
> Key: QPID-2589
> URL: https://issues.apache.org/jira/browse/QPID-2589
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Client
>Affects Versions: 0.7
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.7
>
> Attachments: qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging
> interface. It exposes the Messaging interface through a series of managed
> code classes that may be used by any .NET language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866422#action_12866422 ] Rajith Attapattu commented on QPID-2589: I noticed that the binding lives inside the cpp dir. I would assume this is temporary and that it will eventually be moved out to a suitable location? > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866303#action_12866303 ] Gordon Sim commented on QPID-2589: -- Would it be possible to build the WCF (channel and service interfaces) on top of this API? > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865937#action_12865937
]
Chuck Rolke commented on QPID-2589:
---
Thanks for the comments.
* Raw byte[] interface - will do
* .Net naming/use of properties - will do
* defensive code/memory leaks - hadn't gotten to that yet, but you're right
and will do.
The up-and-coming interface to Variant::List and Variant::Map will probably
look like the following pseudo-code:
//
// Create structured content for the message. This example builds a
// map of items including a nested map and a list of values.
//
Dictionary content = new Dictionary();
Dictionary subMap = new Dictionary();
List colors = new List();
content["id"] = 987654321;
content["name"] = "Widget";
content["percent"] = 0.99;
submap["name"] = "Smith";
submap["number"] = 354;
content["nested"] = submap;
colors.Add("red");
colors.Add("green");
colors.Add("white");
content["colors"] = colors;
//
// Construct a message with the map content and send it
synchronously
// via the sender.
//
Message message = new Message(content);
sender.send(message, true);
Do you think Dictionary and List objects are the best choices?
> Add a .NET binding to QPID Messaging API
>
>
> Key: QPID-2589
> URL: https://issues.apache.org/jira/browse/QPID-2589
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Client
>Affects Versions: 0.7
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.7
>
> Attachments: qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging
> interface. It exposes the Messaging interface through a series of managed
> code classes that may be used by any .NET language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865861#action_12865861
]
Cliff Jansen commented on QPID-2589:
This new C# API has good potential. I worry though about the choice of
System.String as your starting point. Perhaps you meant to add eventually new
constructors and methods to also match the existing C++:
QPID_CLIENT_EXTERN Message(const char*, size_t);
QPID_CLIENT_EXTERN void setContent(const char* chars, size_t count);
in which case I think .NET folks would appreciate two options for each:
Message(byte[] bytes);
Message(byte[] bytes, int index, int count);
SetContent(byte[] bytes)
SetContent(byte[] bytes, int index, int count);
In any event, it makes more sense that the System.String content be accessed or
set via an encoder, as you probably intend to do for maps and other complex
things. Keep in mind that std::string are a reasonable choice for manipulating
binary content in C++. Trying to do the same thing with *immutable* Strings of
16 bit data is likely to cause severe brain strain during your implementation
and .NET users won't thank you for your trouble.
You might also want to tone down the C++-ness of the API, for example by using
.NET naming conventions (i.e. case for methods), and using properties instead
of methods for things like getMilliseconds() or setSubject().
As a C++/CLI tip, be more defensive when passing responsibility for cleanup of
native objects. I added the try block to your code
Sender ^ Session::createSender (System::String ^ address)
{
// allocate a native sender
::qpid::messaging::Sender * senderp = new ::qpid::messaging::Sender;
try {
// create the sender
*senderp =
sessionp->::qpid::messaging::Session::createSender(QpidMarshal::ToNative(address));
// create a managed sender
Sender ^ newSender = gcnew Sender(senderp, this);
senderp = NULL;
}
finally {
if (senderp !=NULL) {
delete senderp
}
}
return newSender;
}
Otherwise, if there is an exception in createSender() there is a memory leak.
If there is an exception in the Sender() constructor, it is worse. There will
be no finalizer call since the constructor didn't complete, so you wonder did
it catch the exception and delete the native resource? The solution is for the
receiver of the native object, Sender in this case, to take responsibility for
cleanup only as the last thing before returning when an exception is no longer
possible. In this particular case it works out that way because there are only
memory assignments to existing memory. You should look at all the other cases
where you do a similar handoff.
> Add a .NET binding to QPID Messaging API
>
>
> Key: QPID-2589
> URL: https://issues.apache.org/jira/browse/QPID-2589
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Client
>Affects Versions: 0.7
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.7
>
> Attachments: qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging
> interface. It exposes the Messaging interface through a series of managed
> code classes that may be used by any .NET language.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
