I have just added support for the asynchronous parts of the System.Messaging API for Mono, i.e. BeginPeek(), BeginReceive(), EndPeek(), EndReceive() and the associated events. There is a follow up patch waiting for review the ensures that exceptions are properly propagated back to the caller when EndPeek() or EndReceive() is called.
I have made support for these methods generic, i.e. it does not rely on the RabbitMQ implementation, thereby reducing the amount of work required to integrate another messaging implemenation. Just extend MessageQueueBase from the Mono.Messaging namespace.
Misadventures in Concurrent and Parallel programming, plus random comments on software performance and various OSS contributions.
Showing posts with label Mono. Show all posts
Showing posts with label Mono. Show all posts
Saturday, 3 January 2009
Tuesday, 9 December 2008
More Mono, AMQP and System.Messaging
I've spent the last couple of months continuing on an implementation of the System.Messaging library for Mono. I have since ditched the QPid client libraries (yes there are multiple, about 6 in fact) in favour of the single dll supplied by RabbitMQ messaging server. I am also using RabbitMQ as the main server for dev and testing. It great bit of software, really easy to install (on Ubuntu anyway) and interestingly built using Erlang.
Progress has gone really well, I have implemented all of the Receive, Send and Peek methods of MessageQueue including methods that select by Id/CorrelationId, use transactions and timeouts. MessageEnumerators are currently supported although it is not possible to implement the transactional version RemoveCurrent, due to the way the AMQP handles transactions. Well maybe not impossible, just an enormous, ineffient hack if I managed to get it to work.
The code has now be shifted into the mono trunk, which suggests I should really make sure I get it complete (or as complete as possible). One nice side effect of the implementation is that I have added an SPI that can be used by other potential implementations.
In similar news, a couple of weeks ago MS announced that they are joining the AMQP working group it will be interesting to see where they go with it.
Progress has gone really well, I have implemented all of the Receive, Send and Peek methods of MessageQueue including methods that select by Id/CorrelationId, use transactions and timeouts. MessageEnumerators are currently supported although it is not possible to implement the transactional version RemoveCurrent, due to the way the AMQP handles transactions. Well maybe not impossible, just an enormous, ineffient hack if I managed to get it to work.
The code has now be shifted into the mono trunk, which suggests I should really make sure I get it complete (or as complete as possible). One nice side effect of the implementation is that I have added an SPI that can be used by other potential implementations.
In similar news, a couple of weeks ago MS announced that they are joining the AMQP working group it will be interesting to see where they go with it.
Friday, 18 April 2008
System.Messaging for Mono
Currently there is no implementation for the System.Messaging namespace in Mono. Judging from the mailing lists there appears to be couple of attempts to add an implementation, but no results as yet, so I decided to have a go myself.
I have just released on Google Code a 0.0.1 release of a bridge between Mono's System.Messaging and Apache QPid. Apache QPid is an implementation of the AMQP protocol. AMQP is an open protocol designed to provide a standard wire protocol for asynchronous messaging buses. There are a number of other open source implementations of AMQP floating about too. RabbitMQ looks like another interesting implementation, built on Erlang.
I used the QPid client libraries to provide the client-side networking implementation. Unfortunately that requires linking to 8 different assemblies. Forcing users of Mono's System.Messaging to link to these at compile time seemed excessive, so I wanted to decouple the QPid implementation from System.Messaging. Unlike JMS, Microsoft's System.Messaging API was never designed to have multiple implementations. Therefore, in order to decouple the 2 I had to add a provider layer into the Mono code base. This is available in the form of a patch on the same Google code site.
The current version only provide basic sending and receiving. XML and Binary message formatting are also supported, however that is implemented inside of the Mono code base. I haven't looked into performance yet. It currently runs all requests over a single socket connection (multiplexing using AMQP's channel feature), which probably not the optimal approach.
I'll see how far I get before I head off on my big trip.
I have just released on Google Code a 0.0.1 release of a bridge between Mono's System.Messaging and Apache QPid. Apache QPid is an implementation of the AMQP protocol. AMQP is an open protocol designed to provide a standard wire protocol for asynchronous messaging buses. There are a number of other open source implementations of AMQP floating about too. RabbitMQ looks like another interesting implementation, built on Erlang.
I used the QPid client libraries to provide the client-side networking implementation. Unfortunately that requires linking to 8 different assemblies. Forcing users of Mono's System.Messaging to link to these at compile time seemed excessive, so I wanted to decouple the QPid implementation from System.Messaging. Unlike JMS, Microsoft's System.Messaging API was never designed to have multiple implementations. Therefore, in order to decouple the 2 I had to add a provider layer into the Mono code base. This is available in the form of a patch on the same Google code site.
The current version only provide basic sending and receiving. XML and Binary message formatting are also supported, however that is implemented inside of the Mono code base. I haven't looked into performance yet. It currently runs all requests over a single socket connection (multiplexing using AMQP's channel feature), which probably not the optimal approach.
I'll see how far I get before I head off on my big trip.
Subscribe to:
Posts (Atom)