This release fixes several bugs found since the 1.3.0 release and also adds some great new features.
- Improved URI handling in all NMS clients.
- Improved handling of Request Timeout settings. When a request times out now you will see a RequestTimedOutException thrown.
- Added a new SetBytes method to IMapMessage.
- Added a new MessageTransformer API, you can now intercept a Message as its sent or received and add / update / or replace that message.
- NMS.ActiveMQ will now handle transforming foreign NMS Messages into its own internal format when they are sent so you can easy route Messages from one NMS provider to another.
- Many new Unit Tests added to the Test Suite.
5 comments:
Very good
Today, XA transaction are not supported by NMS.
Is there any date for this support?
As XA is supported by JAVA and JMS, it becomes urgent to have also this implementation in NMS.
Thanks
What are your thoughts on how this would be implemented? As far as I know there aren't any libraries available that allow a .NET client to interact with a JTA Transaction Manager. Maybe you know of something I don't though.
The goal is not necessarily to interact with JTA Transaction Manager.
We have a project in which we read from a queue with a .Net program and then the program is in charge to insert data in MS SQL Server.
The goal is to have a transaction between the queue (read message) and insertion in DB.
A good transaction manager for that could be MSDTC as we use MS SQL Server.
pe
So far the MS Transaction model doesn't make a whole lot of sense to me, at least in regards to its use with NMS/JMS style messaging. Would be nice if they stuck to the standard X/Open model.
The problem so far is that in order to really take advantage of ActiveMQ distributed transactions you need to use an XA transaction manager so that you can properly handle all the various cases including transaction recovery. The .NET System.Transaction namespace doesn't seem to make any of the MSDTC XA support visible to the .NET code so its pretty difficult to make that work. To compound things further the Transactions in .NET can be either local or distributed without much indication of with it is. We could code up something that checks for an ambient transaction and enlist using the EnlistVolatile option and just use the LocalTransaction model of JMS client's but this will be less robust then a full on XA style distributed transaction. Unless I'm missing something, we welcome input and patches :)
Post a Comment