RE: IKVMing the Java client for .Net
Robert Greig wrote: Finally, there are performance issue with managed/non-managed heap copies in Java that makes JNI unattractive (I don't know if this applies to .NET too - although I did ask the question on this mailing list some time ago without receiving any answer). I'll take a stab at it now. This can be mitigated somewhat by asking the garbage collector to pin a managed memory location for a brief amount of time, but there are housekeeping costs associated with that too. In the current WCF implementation, there is a single copy between the binary message content in managed space and the individual AMQP message body frames in native space. A purely native Visual C++ application would have to make that same copy. But it would be spared the costs of the pinning and the numerous managed to native transitions used to monitor and control the Qpid objects that control connections, sessions, subscriptions etc. For very large messages, the overhead is small. For 100 byte sized ones it is certainly significant. Cliff -Original Message- From: Robert Greig [mailto:robert.j.gr...@gmail.com] Sent: Wednesday, January 28, 2009 12:05 PM To: dev@qpid.apache.org; cctriel...@redhat.com Subject: Re: IKVMing the Java client for .Net 2009/1/23 Carl Trieloff cctriel...@redhat.com: In a discussion with the Microsoft guys, I they where thinking of using the C++ client, with WCF on top of that. They seem to have thought about that quite a bit, so it would be good to get those comments onto the list also around this topic. Is this not going to suffer the same performance issues that Java has with JNI? (I ask that as a question, not an assertion, but I had always assumed this would apply across both platforms). In Java there is a non-trivial performance penalty copying data from the C heap to the Java heap and vice versa. This is one reason why some JDBC drivers built on top of native code perform and scale much worse than pure Java drivers (the example often benchmarked is the Oracle driver). RG - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Only supporting 0-10 means it won't talk to the current Java broker or any of the other AMQP implementations such as OpenAMQ or RabbitMQ. Does that really matter, we already have an 0-8 client for .NET and others exist. We need to look forward. I would say the target is Windows where dll's will work fine Mono for which I have no idea the limitations. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff cctriel...@redhat.com wrote: Only supporting 0-10 means it won't talk to the current Java broker or any of the other AMQP implementations such as OpenAMQ or RabbitMQ. Does that really matter, we already have an 0-8 client for .NET and others exist. We need to look I think having a client which can interoperate with 3 of the 4 AMQP brokers I know of is quite important. The existing 0-8 .Net client is somewhat suboptimal and doesn't support any standard API. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
On Wed, Jan 28, 2009 at 8:01 PM, Robert Greig robert.j.gr...@gmail.com wrote: 2009/1/23 Aidan Skinner ai...@apache.org: Traditionally, the approach to writing the .Net client has been to transliterate the Java client by hand and slap a random API on top of that. That seems like a bit of a waste of effort to me. I was thinking about using IKVM to load the Java client as a library for the AMQP-level bits and write a native C# implementations of WCF etc. that used that. This has the benefit of using an existing, tested client implementation, reducing the amount of work that needs done and would help us seperate the AMQP specific bits of the Java client out from the JMS specific bits. It also means that the whole client is running in managed code, which is good. What do people think? This is something we considered a while ago when pondering the very first .NET client. At the time it was scuppered because IKVM did not support NIO. I definitely think it's worth looking at again if IKVM now supports enough API to make it feasible. IKVM should support all of the JDK 6 API now, it uses OpenJDK (nee GNU Classpath), and ships java.nio in it's core package, so we might be able to get away without too many extra bits and pieces. I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. Totally. Having something which feels natural is really important. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Aidan Skinner wrote: On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff cctriel...@redhat.com wrote: Only supporting 0-10 means it won't talk to the current Java broker or any of the other AMQP implementations such as OpenAMQ or RabbitMQ. Does that really matter, we already have an 0-8 client for .NET and others exist. We need to look I think having a client which can interoperate with 3 of the 4 AMQP brokers I know of is quite important. The existing 0-8 .Net client is somewhat suboptimal and doesn't support any standard API. I believe that should drive our technology selection. That is something that will change with the political landscape. What does not change is that we will need to maintain the client for many years. I think we should work out the optimal solution for .NET (Windows) as the top criteria for technology selection. Carl.
Re: IKVMing the Java client for .Net
On Fri, Jan 30, 2009 at 6:11 AM, David Ingham david.ing...@microsoft.com wrote: Carl's right, we have been investigating the idea of layering a WCF channel implementation on top of the C++ client library. That is, the managed code channel implementation would pinvoke down to the native C++ code. This is the approach that we used for the MSMQ channel that ships in the .NET framework today and it works pretty well. We're drawn to this approach primarily because of the maturity of the C++ code base. The pure .NET approach clearly has merit too; one of the key advantages being that it offers the potential to factor the code in a way that's more in line with WCF best practice, i.e., as a set of layered channels rather than as a monolithic block. Doing it on top of the C++ client has two current disadvantages over the Java client that I can see: not 100% managed code only supports 0-10 Not having all managed code reduces portability (since you're now limited to the platforms that the C++ client supports) and limits the security profiles that the client will run under. Only supporting 0-10 means it won't talk to the current Java broker or any of the other AMQP implementations such as OpenAMQ or RabbitMQ. Related to this, it seems likely that the Java client will support AMQP 1-0 before the C++ client does, if only because the Java client already supports multiple protocols. On an unrelated note, what do you mean by the the maturity of the C++ code base? What about that client made it a better choice from your PoV than the Java client? - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Dave, that sounds like a great list to start on. Carl. David Ingham wrote: Hi all, Just a quick intro for the list since I've been quiet to date. I work on messaging technologies in the Connected Systems Division at Microsoft. I've been tracking AMQP since early 2005 when John Davies first announced its existence at the Web Services on Wall Street Conference. In a previous life I architected HP's JMS implementation and chunks of transaction processing and messaging middleware for HP, Arjuna and Bluestone. Carl's right, we have been investigating the idea of layering a WCF channel implementation on top of the C++ client library. That is, the managed code channel implementation would pinvoke down to the native C++ code. This is the approach that we used for the MSMQ channel that ships in the .NET framework today and it works pretty well. We're drawn to this approach primarily because of the maturity of the C++ code base. The pure .NET approach clearly has merit too; one of the key advantages being that it offers the potential to factor the code in a way that's more in line with WCF best practice, i.e., as a set of layered channels rather than as a monolithic block. We're planning on putting in some effort in on this task but I think there are a few more pressing tasks on the Windows side of the house that we'll try to help out with first. Cliff has already commented on the build system issues; I think it'd be great if we could get the equivalent of the make/make check functionality that exists today on Linux up and running on Windows. As people have already mentioned, it would be a big improvement if we can get the builds running of the same input files so that we can avoid these sync issues that have been causing problems recently. Then there's the packaging work that folks have been discussing, adding DLL support and building some form of installer to make the end-user experience as slick as possible. Does this sound like a reasonable set of things? Anyway, it's great to be here and I look forward to working with you all. Cheers, Dave. -Original Message- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: Wednesday, January 28, 2009 12:25 PM To: dev@qpid.apache.org Subject: Re: IKVMing the Java client for .Net Joshua Kramer wrote: I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. Has anybody investigated the possibility of creating a .NET assembly from the C++ client, instead of trying to use IKVM and the Java client? When speaking to the Microsoft guys that had mentioned trying this approach with me. Cliff, any comments on the topic? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
2009/1/30 David Ingham david.ing...@microsoft.com: We're planning on putting in some effort in on this task but I think there are a few more pressing tasks on the Windows side of the house that we'll try to help out with first. Cliff has already commented on the build system issues; I think it'd be great if we could get the equivalent of the make/make check functionality that exists today on Linux up and running on Windows. As people have already mentioned, it would be a big improvement if we can get the builds running of the same input files so that we can avoid these sync issues that have been causing problems recently. Then there's the packaging work that folks have been discussing, adding DLL support and building some form of installer to make the end-user experience as slick as possible. Does this sound like a reasonable set of things? Anyway, it's great to be here and I look forward to working with you all. Dave, welcome aboard. It's great to have focus on the Windows platform. I agree that improving the end user Windows experience with the C++ broker is the most important thing right now. RG - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: IKVMing the Java client for .Net
Hi all, Just a quick intro for the list since I've been quiet to date. I work on messaging technologies in the Connected Systems Division at Microsoft. I've been tracking AMQP since early 2005 when John Davies first announced its existence at the Web Services on Wall Street Conference. In a previous life I architected HP's JMS implementation and chunks of transaction processing and messaging middleware for HP, Arjuna and Bluestone. Carl's right, we have been investigating the idea of layering a WCF channel implementation on top of the C++ client library. That is, the managed code channel implementation would pinvoke down to the native C++ code. This is the approach that we used for the MSMQ channel that ships in the .NET framework today and it works pretty well. We're drawn to this approach primarily because of the maturity of the C++ code base. The pure .NET approach clearly has merit too; one of the key advantages being that it offers the potential to factor the code in a way that's more in line with WCF best practice, i.e., as a set of layered channels rather than as a monolithic block. We're planning on putting in some effort in on this task but I think there are a few more pressing tasks on the Windows side of the house that we'll try to help out with first. Cliff has already commented on the build system issues; I think it'd be great if we could get the equivalent of the make/make check functionality that exists today on Linux up and running on Windows. As people have already mentioned, it would be a big improvement if we can get the builds running of the same input files so that we can avoid these sync issues that have been causing problems recently. Then there's the packaging work that folks have been discussing, adding DLL support and building some form of installer to make the end-user experience as slick as possible. Does this sound like a reasonable set of things? Anyway, it's great to be here and I look forward to working with you all. Cheers, Dave. -Original Message- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: Wednesday, January 28, 2009 12:25 PM To: dev@qpid.apache.org Subject: Re: IKVMing the Java client for .Net Joshua Kramer wrote: I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. Has anybody investigated the possibility of creating a .NET assembly from the C++ client, instead of trying to use IKVM and the Java client? When speaking to the Microsoft guys that had mentioned trying this approach with me. Cliff, any comments on the topic? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
2009/1/23 Carl Trieloff cctriel...@redhat.com: In a discussion with the Microsoft guys, I they where thinking of using the C++ client, with WCF on top of that. They seem to have thought about that quite a bit, so it would be good to get those comments onto the list also around this topic. Is this not going to suffer the same performance issues that Java has with JNI? (I ask that as a question, not an assertion, but I had always assumed this would apply across both platforms). In Java there is a non-trivial performance penalty copying data from the C heap to the Java heap and vice versa. This is one reason why some JDBC drivers built on top of native code perform and scale much worse than pure Java drivers (the example often benchmarked is the Oracle driver). RG - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. Has anybody investigated the possibility of creating a .NET assembly from the C++ client, instead of trying to use IKVM and the Java client? -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Joshua Kramer wrote: I tend to agree that we'd need to build .NET stuff by hand on top since in a raw Java API there will be things that are not idiomatic in .NET - e.g. no use of events, or capitalisation of method names etc. Has anybody investigated the possibility of creating a .NET assembly from the C++ client, instead of trying to use IKVM and the Java client? When speaking to the Microsoft guys that had mentioned trying this approach with me. Cliff, any comments on the topic? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Aidan Skinner wrote: I'm about to head off for a week, and thought I'd give this topic a bit of a poke with a stick before I did so there's a bit of discussion on the topic before we're deep into M5 territory. Traditionally, the approach to writing the .Net client has been to transliterate the Java client by hand and slap a random API on top of that. That seems like a bit of a waste of effort to me. I was thinking about using IKVM to load the Java client as a library for the AMQP-level bits and write a native C# implementations of WCF etc. that used that. This has the benefit of using an existing, tested client implementation, reducing the amount of work that needs done and would help us seperate the AMQP specific bits of the Java client out from the JMS specific bits. It also means that the whole client is running in managed code, which is good. What do people think? I definitely think this is worthy of investigation. I know nothing about IKVM, but if it works, it would be a significantly preferable to the current approach which is IMHO unsustainable. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IKVMing the Java client for .Net
Rafael Schloming wrote: Aidan Skinner wrote: I'm about to head off for a week, and thought I'd give this topic a bit of a poke with a stick before I did so there's a bit of discussion on the topic before we're deep into M5 territory. Traditionally, the approach to writing the .Net client has been to transliterate the Java client by hand and slap a random API on top of that. That seems like a bit of a waste of effort to me. I was thinking about using IKVM to load the Java client as a library for the AMQP-level bits and write a native C# implementations of WCF etc. that used that. This has the benefit of using an existing, tested client implementation, reducing the amount of work that needs done and would help us seperate the AMQP specific bits of the Java client out from the JMS specific bits. It also means that the whole client is running in managed code, which is good. What do people think? I definitely think this is worthy of investigation. I know nothing about IKVM, but if it works, it would be a significantly preferable to the current approach which is IMHO unsustainable. In a discussion with the Microsoft guys, I they where thinking of using the C++ client, with WCF on top of that. They seem to have thought about that quite a bit, so it would be good to get those comments onto the list also around this topic. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
