SwiftMQ 6.0 is offered in two different versions: the SwiftMQ Router, which has been in the market for six years, and the SwiftMQ HA Router with high and continuous availability support.

SwiftMQ HA Router 6.0 features:

• High Availability JMS Router with ACTIVE/STANDBY deployment and active replication.
• Continuous Availability through versioned protocols - uprade SwiftMQ during operation without interruption.
• Transparent JMS and JNDI failover, no extra reconnect code required.
• Automatic and transparent resolve of all open transactions in transit, including XA transactions, as well as any non-transacted acknowledge mode.
• Full inbound and outbound duplicate message detection. Messages are never delivered twice.
• No persistent messages lost during failover. Message sequence is guaranteed.
• Choice of 3 different store types: Replicated File Store, Shared File Store, Shared JDBC Store.
• Transparent reconnect from SwiftMQ Explorer, CLI, CLI Admin API.
• Easy conversion to High Availability by HA Wizard. Turns any existing configuration into High Availability.
• High Availability test suite included. Test your JMS applications under a continuous failover scenario.
• Includes all Swiftlets of SwiftMQ Router Standard.
• Additional Swiftlets included at no extra cost: JMS XA/ASF Swiftlet, Routing/Unlimted Swiftlet, Standard File Store Swiftlet, JDBC Store Swiftlet.

The HA test suite included in the product is suitable for automatic tests of JMS applications under ongoing failover conditions. Per default it is configured to kill one HA instance every 2 minutes. The test suite is generic and can be used against other JMS providers, too.

SwiftMQ Router 6.0 (non-HA) supports transparent JMS/JNDI reconnect to the same SwiftMQ Router with duplicate message detection and transaction recovery.

Both products are based on SwiftMQ's unique Federated Router Network.

Prices and Availability

The price for a single SwiftMQ Router license is EUR 990.00 / USD 1,386.00. The price for a SwiftMQ HA Router consisting of 2 HA instances is EUR 2,490.00 / USD 3,486.00. These prices refer to router instances. We do not charge CPU-based prices. Volume discounts are granted from 10 licenses on. Additionally, we offer various upgrade options.

I just want to say, for startups who cannot afford expensive licenses, anyone now can build a jms server with active replication as well as strict ordering guarantees by using EVS4J, my implementation of the totem single-ring protocol, which provides real-time totally ordered replication.

A user recently reported achieving 30MB/s replication throughput among 4 nodes (240Mbps).

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

I just want to say, for startups who cannot afford expensive licenses, anyone now can build a jms server

... and if you are lazy, there are also free JMS implementations like ActiveMQ...

I mean, time is generally money; buying a license is probably cheaper than rolling one's own, even if using a good framework as the base. And there aren't that many developers around that I would trust with implementing a MQ for any company I would work for.

I just want to say, for startups who cannot afford expensive licenses, anyone now can build a jms server

... and if you are lazy, there are also free JMS implementations like ActiveMQ...I mean, time is generally money; buying a license is probably cheaper than rolling one's own, even if using a good framework as the base. And there aren't that many developers around that I would trust with implementing a MQ for any company I would work for.

I believe that rolling out a jms server is not that difficult, but of course, I am speaking to people who don't have a problem writing some system-level software. I am not suggesting that anyone who knows ejb can do it.

Anyhow, what evs4j brings to the table is that anyone who can write a basic jms server can use evs4j to implement a jms server which has the highest throughput as well as lowest latency in the industry. That's because evs4j makes it very simple to implement 100%, multi-master, ordered replication in any application.

With full replication you get 2 benefits:

1. Built-in horizontal scalability.

2. Lowest latency in the industry due to XA transactions being committed to multiple memory banks before being saved to disk.

If it sounds too good to be true, it may be. The totem protocol is a very cpu-intensive protocol designed for 100% data sharing.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

I just want to say, for startups who cannot afford expensive licenses, anyone now can build a jms server with active replication as well as strict ordering guarantees by using EVS4J, my implementation of the totem single-ring protocol, which provides real-time totally ordered replication.

A user recently reported achieving 30MB/s replication throughput among 4 nodes (240Mbps).

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

don't know about others, but writing a full featured robust and scalable JMS provider is quite hard. If it was easy, companies wouldn't be able to charge a premium for JMS software. There's plenty of JMS providers out there that are free and performant. There's no need to write your own JMS provider using EVS4J, unless someone is into writing JMS providers. In that case, I would think it's better to start OpenJMS, Joram or ActiveMQ.

peter

There's plenty of JMS providers out there that are free and performant. There's no need to write your own JMS provider using EVS4J, unless someone is into writing JMS providers. In that case, I would think it's better to start OpenJMS, Joram or ActiveMQ.peter

I was referring specifically to real-time, active replication.

Are you claiming that the above do active replication?

Guglielmo

There's plenty of JMS providers out there that are free and performant. There's no need to write your own JMS provider using EVS4J, unless someone is into writing JMS providers. In that case, I would think it's better to start OpenJMS, Joram or ActiveMQ.
peter

I was referring specifically to real-time, active replication.Are you claiming that the above do active replication?

Guglielmo

I'm not claiming OpenJMS, Joram or ActiveMQ support full real-time replication. I know ActiveMQ has some clustering features, but I don't know what the latest version supports. My point is that I doubt writing a "basic" or "simple" JMS provider + home grown replication is going to be sufficient. I think the problem is far more complicated that just implementing a few interfaces and hook it up to a replication library. I'm no expert, and likely totally wrong. I would think replication is just the tip of the iceberg. One thing I have learned the last few years it that fault tolerant + horizontally scalable is very hard to achieve.

I think James Strachan and Cameron know far more about what it really takes to build something at that level.

peter

My point is that I doubt writing a "basic" or "simple" JMS provider + home grown replication is going to be sufficient. I think the problem is far more complicated that just implementing a few interfaces and hook it up to a replication library. I'm no expert, and likely totally wrong.

I would say that you are right, but in a different context. If all you have to rely on is UDP or TCP, then I agree. But with totally ordered broadcast as a foundation the situation is very different. You can replicate any state machine. In this case the state machines would be the message queues.

I would think replication is just the tip of the iceberg. One thing I have learned the last few years it that fault tolerant + horizontally scalable is very hard to achieve.

Well, what I can tell you is that the original purpose of using a totally-ordered protocol was to make it simple to write replicated applications. I didn't design it. I just wrote a java implementation. The protocol itself was designed at USCB by people who study this type of problem.

Guglielmo

One thing I have learned the last few years it that fault tolerant + horizontally scalable is very hard to achieve.

I agree, and not only is it difficult to do, but if it's not in the core interest of the given business, why bother? The licensing fees seem high, but when compared with the cost involved in rolling your own and then babysitting it for all eternity, I'd argue the price is quite reasonable.

Tom

One thing I have learned the last few years it that fault tolerant + horizontally scalable is very hard to achieve.

I agree, and not only is it difficult to do, but if it's not in the core interest of the given business, why bother? The licensing fees seem high, but when compared with the cost involved in rolling your own and then babysitting it for all eternity, I'd argue the price is quite reasonable.Tom

In my last job the company did write a lot of its own software, so it's possible I am being overly optimistic. I do know that most shops don't have high-volume requirements, but I was specifically referring to the fact that the tss article mentions active replication. The point I was trying to make is that active replication is easily achieved using the totem protocol.

Guglielmo

I just want to say, for startups who cannot afford expensive licenses, anyone now can build a jms server with active replication as well as strict ordering guarantees by using EVS4J, my implementation of the totem single-ring protocol ..

I've spoken with some large banks that have done some extensive benchmarking, and SwiftMQ is considered to be very good when it comes to reliable, high-speed messaging. It is certainly not expensive as far as HA software goes (e.g. Oracle RAC runs about $80k/CPU), unless you are paying for it with lunch money.

You really do a dis-service to your open source project by suggesting it for inappropriate uses. Paying engineers to roll a custom JMS implementation is a huge waste of money. (On the other hand, perhaps doing it to learn something could be an interesting project.)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

You really do a dis-service to your open source project by suggesting it for inappropriate uses.

The use is quite appropriate. You may not know appreciate why it is an appropriate use if you do not have a background in process groups.

That said, it is not for the faint of heart. Most people do not need to use the totem protocol. In the past it - or similar token-based protocols - has been used to build air traffic control systems and stock exchanges. Most people are not building air traffic control systems. But a person with imagination can see why you can build a state-of-the-art jms server on top of this protocol.

Anyhow, the protocol should speak for itself. At the tune of 30MB/s.

Guglielmo

or you could use infiniband for 10x the throughput ...

There are more facets to writing a JMS system than just fast reliable distribution of messages - that's the easy bit :)

Things start to get a little tricker when processing acknowledgements of messages from clients (which you generally don't have to do for real-time feeds) - and keeping all the distributed state machines in step, across node failures and power outages, long lived inactive consumers (durable subscribers), implementing queue semantics, dealing with slow consumers, fast producers etc. etc.

cheers,

Rob

or you could use infiniband for 10x the throughput ...There are more facets to writing a JMS system than just fast reliable distribution of messages - that's the easy bit :)

You seem to think that I was pushing multicast as a way to get the data to the clients.

:)

That's not the case. Atomic broadcast in this case would be used among 3-4 nodes in the data center to do in-memory replication of queues. Clients connect using tcp connections. This design scales well. If you have to add clients, you add a node to the server cluster, which results in slightly higher latency for all messages (but you just added throuhgput to the system by adding a server node.)

Things start to get a little tricker when processing acknowledgements of messages from clients (which you generally don't have to do for real-time feeds)

I was not addressing real-time feeds. I was talking about transactional, XA, message transactions. The real-time part is the latency of the token among the server nodes. It's very well behaved.

- and keeping all the distributed state machines in step, across node failures and power outages

That's what Extended Virtual Synchrony is for. EVS4J provides totally ordered reliable multicast with membership changes.

, long lived inactive consumers (durable subscribers), implementing queue semantics, dealing with slow consumers, fast producers etc. etc. cheers,Rob

Obviously if a producer is really fast and a consumer really slow then you have an unbalanced system and all bets are off. Then your throughput is gone anyhow, so it doesn't really matter what you use.

Guglielmo

I agree with the other comments here. JMS is not just about speed of data transmission.
Before starting your own implementation I suggest you take a look at the issues in designing and implemeting:

1. your own XA (such as rollback, replay and guaranteed transaction logging)
2. message selector algorithms for long lived/high volume clients (see the research papers for IBM's gryphon JMS implementation)
3. message acknowledgement and delivery strategies
4. durable messages
5. administration capabilities
6. secure messaging

And these are only a few among many aspects of such of a product.

Implementing something like SwiftMQ this is not a trivial matter, and the group membership and reliable transmission functions are only a small part of this.

cheers,

Steve Woodcock
Jofti- Indexing for Java Caches.

Does anyone else feel like the pure JMS plays (throw in the current buzz word to extend the marketing ;-), are experiencing to some degree the same types of things the appserver vendors experienced when there are dozens available (remember unify, etc)? It seems like with enough good and maturing open source jms products that do 80%+ of what most people need, that the number of vendors providing the high end capabilities is solidifying into a relativel small group.

I agree with the other comments here. JMS is not just about speed of data transmission.

I was specifically focusing on the problem of throughput, latency and availability. Admittedly, it is a small subset of applications which require both high throughput, low latency, and five-9 availability. But there are some.

Before starting your own implementation I suggest you take a look at the issues in designing and implemeting:1. your own XA (such as rollback, replay and guaranteed transaction logging)

I don't consider XA much of a challenge any more.

As far as logging, as I said, what the totem protocol brings to the table is that since it does replication so well, you can create multiple copies of data in different machines, and thus take disk forces out of the critical path. In fact, there are some systems where the disk will just not be used.

Most people don't realize how fast the totem protocol is. A user reported 30MB/s. That's 240Mbps reliable, totally ordered multicast.

I think that short of making the switch to infiniband and a userland network stack you would have difficulty defining a protocol that does better than totem. Again, this is assuming 100% replication.

2. message selector algorithms for long lived/high volume clients (see the research papers for IBM's gryphon JMS implementation)

If you have to keep messages around for a day then the system is unbalanced. I think these are regular systems that need to use a traditional jms server with the database in the critical path.

3. message acknowledgement and delivery strategies4. durable messages

I was only thinking of durable messages. I am talking of using the totem protocol for server replication, not for publish-subscribe. For that totem it's not appropriate. There you need to use reliable multicast with fifo ordering. Totem is token-based.

I am talking about using totem to run servers in lock-step.

5. administration capabilities

It depends how sophisticated you need to make it, I guess. Maybe a startup writing the next online auction system can put up with a basic administration tool?

6. secure messaging

Again, this depends on why you need encryption.

And these are only a few among many aspects of such of a product.Implementing something like SwiftMQ this is not a trivial matter, and the group membership and reliable transmission functions are only a small part of this. cheers,Steve WoodcockJofti- Indexing for Java Caches.

Definitely, I was not trying to say that a finished product doesn't take a long time. But a product you only use internally doesn't cost nearly as much to build as a product that you have to sell. And there are many other ways that you can save money on development.

Guglielmo

Sure, if someone only needs in memory replication with the exact requirements you stated, but I argue those purchasing a license of JMS server are interested in a lot more than "just high throughput & low latency replication."

To suggest someone roll their own replication thinking it's a sufficient substitute for messaging middleware is inaccurate and poor advice in my bias opinion. I know someone that built a couple traffic control systems and they do have some very specific requirements. Without a doubt, there are plenty of other cases where a system needs superfast replication, but are those mainstream cases?

peter

Without a doubt, there are plenty of other cases where a system needs superfast replication, but are those mainstream cases?peter

No, they are not mainstream. But do I only have to talk about mainstream cases, or can I focus on things that haven't been completely solved yet? I post about what I am interested in.

In addition, we are conditioned to assume things about what systems are buildable and what systems are not.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

I don't consider XA much of a challenge any more.

As far as logging, as I said, what the totem protocol brings to the table is that since it does replication so well, you can create multiple copies of data in different machines, and thus take disk forces out of the critical path. In fact, there are some systems where the disk will just not be used.

err... are you sure you mean this? Have you ever tried to write a fully fleged transaction manager? Why do you think JBoss bought one and many other organisations leverage something like Tuxedo or JOTM rather than write their own.

I think you seem to keep mistaking throughput of data somehow with other problems - speed is not a solution to the problems solved by transaction managers- they are not there just because the designers thought ethernet was a bit slow.

If you have to keep messages around for a day then the system is unbalanced. I think these are regular systems that need to use a traditional jms server with the database in the critical path.

I think you also might at least have read the papers at the IBm site - they are not about long lived messages - but about the complexities in the algorithms to perform real time processing of large numbers of client message selectors against high volume message throughput, again not a problem that can be addressed by protocol speed(in fact faster throughput is a degrading factor in this problem).

There is no sense advocating building your own JMS server based on some arbitrary quick protocol - really it is a an option for most companies that should be slightly above writing your own JVM.

I work for a company that builds software to index cache data - but it doesn't mean that I would recommend writing a database server based on it.

The reality, in my own experience, is that infrastructure software built like this in companies rapidly ends up situation where you are struggling to develop a product that has even a tenth of the functionality of a decent commercial/open source product, you can't really support it well after the original developers have left, produces massive headaches for integration with other systems as there are no off the shelf integration libraries available. At the same time the business would really like you to do some stuff that meets a business need, rather than demonstrate how clever it is to spend three months project time writing something you can license for $2k.

cheers
Steve Woodcock
Jofti- Indexing for Java Caches.

I don't consider XA much of a challenge any more.As far as logging, as I said, what the totem protocol brings to the table is that since it does replication so well, you can create multiple copies of data in different machines, and thus take disk forces out of the critical path. In fact, there are some systems where the disk will just not be used.

err... are you sure you mean this?

Yes, I mean it. You can store the transaction log in memory and keep 3-4 replicas. This provides enough availability (fabulous availability, in fact) and you can still sync your resource manager to disk or to a relational database when you need to shut the cluster down.

Have you ever tried to write a fully fleged transaction manager? Why do you think JBoss bought one and many other organisations leverage something like Tuxedo or JOTM rather than write their own.

I don't know what happens at JBoss, but Geronimo wrote their own on top of HOWL. And I remember Mike Spille documented the problem very well.

But in his he used the disk.

I think you seem to keep mistaking throughput of data somehow with other problems - speed is not a solution to the problems solved by transaction managers- they are not there just because the designers thought ethernet was a bit slow.

No, I am not mistaking it. I have no idea how you came up with this comment.

BTW, using in-memory replication to take the disk out of the critical path is not my idea. I just advocate it because it's brilliant.

If you have to keep messages around for a day then the system is unbalanced. I think these are regular systems that need to use a traditional jms server with the database in the critical path.

I think you also might at least have read the papers at the IBm site - they are not about long lived messages - but about the complexities in the algorithms to perform real time processing of large numbers of client message selectors against high volume message throughput,
I'll read the articles if I get a chance. I am not specifically interested in message selection though. However, I suspect that since with 100% multi-master server replication you can spread the load horizontally, the problem becomes more tractable. Or perhaps it's a problem of computability and not resources?

There is no sense advocating building your own JMS server based on some arbitrary quick protocol - really it is a an option for most companies that should be slightly above writing your own JVM.

So let it be an option for a small minority who need to be stellar systems.

I work for a company that builds software to index cache data - but it doesn't mean that I would recommend writing a database server based on it.The reality, in my own experience, is that infrastructure software built like this in companies rapidly ends up situation where you are struggling to develop a product that has even a tenth of the functionality of a decent commercial/open source product, you can't really support it well after the original developers have left, produces massive headaches for integration with other systems as there are no off the shelf integration libraries available. At the same time the business would really like you to do some stuff that meets a business need, rather than demonstrate how clever it is to spend three months project time writing something you can license for $2k.cheersSteve WoodcockJofti- Indexing for Java Caches.

Again, those people do not have a hard problem to solve.

BTW, check out EVS4J. You never know, you may be able to use it in your product.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

Just because a system has fast in-memory replication, it doesn't mean one can take the disk out. From the little that I know of air control systems, they do log everything because the government requires it. What happens if a plane crashes? The investigators must be able to reply the events to determine what caused the crash. In the case of air control systems and radar data, the systems have to filter out data. For example, the military requires that all air control system filter out data that might expose sensitive top secret projects. So doing things like filtering real-time data is absolutely critical.

Totem protocols have been for over a decade right, so it's not new. For example, a quick google turns up some interesting results.

http://citeseer.ist.psu.edu/agarwal92totem.html
http://citeseer.ist.psu.edu/ciarfella93totem.html
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/euromicro/1998/8646/01/8646toc.xml&DOI=10.1109/EURMIC.1998.711841

I think you're overstating the benefit of your library and simplifying complex real-time systems too much. Of the large distributed systems I know, non of them would be sufficient with just "fast replication".

my bias 2 bits

peter

Just because a system has fast in-memory replication, it doesn't mean one can take the disk out.

It depends on the system. If by the time you recover from disk the data is useless, for example ...

 From the little that I know of air control systems, they do log everything because the government requires it.

But that is a different kind of logging. It's not in the critical path. Not having to log synchronously makes log record batching much simpler than it otherwise would be. You do have to wait up to the token rotation time (between 0 and 20ms, depending on the size of the ring,) but the throughput is on the order of 10-20,000 messages per second. That you cannot do with a disk. And failover time is really small.

What happens if a plane crashes? The investigators must be able to reply the events to determine what caused the crash.

So you can log record batches asynchronously.

In the case of air control systems and radar data, the systems have to filter out data. For example, the military requires that all air control system filter out data that might expose sensitive top secret projects. So doing things like filtering real-time data is absolutely critical.

Interesting problem. I will take a look at the IBM articles if I get a chance. I didn't understand if the filtering problem is one of computability or scalability. In the latter case, a totem-based system with 100% replication is horizontally scalable. You add a box to the ring, and the average latency for all messages goes up slightly.

Totem protocols have been for over a decade right, so it's not new. For example, a quick google turns up some interesting results.http://citeseer.ist.psu.edu/agarwal92totem.htmlhttp://citeseer.ist.psu.edu/ciarfella93totem.htmlhttp://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/euromicro/1998/8646/01/8646toc.xml&DOI=10.1109/EURMIC.1998.711841I think you're overstating the benefit of your library and simplifying complex real-time systems too much. Of the large distributed systems I know, non of them would be sufficient with just "fast replication".my bias 2 bitspeter

You are confirming what I said, namely that I did not invent it. I think this protocol is a valuable tool. Unfortunately there are only a few people who know enough both about oltp and about process groups to see how to leverage this. But nothing needs to be invented. The literature is out there.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

Geronimo did write their own - but then HOWL is a disk transaction logger.

I think that I am trying to say, and I seem to be failing to get across, is that there are lots of problems in a decent JMS systems many of which are orthogonal to the actual message replication problem.

Now.. how does that song go...

If I had a hammer...

cheers
steve

I think you also might at least have read the papers at the IBm site - they are not about long lived messages - but about the complexities in the algorithms to perform real time processing of large numbers of client message selectors against high volume message throughput, again not a problem that can be addressed by protocol speed(in fact faster throughput is a degrading factor in this problem).

I went ahead and looked over an article at the IBM site that talks about the matching problem:

"Matching Events in a Content-based Subscription System"

It appears that the problem is one of computability. However, the problem only presents itself if an application insists on searching by attribute ("content") instead of topic. The authors explain that with topics there is no computability problem.

So you do make a fair point, although companies that use TIBCO for example do use topics, in which case there is no problem. Filtering on the client is another options also. Perhaps a combination of topics and client-side filtering might provide an acceptable solution in some applications.

I also got the impression that the architecture of this gryphon system is a network of brokers. If I had to solve this problem using totem I would start with a single fully replicated broker, with jms connections load balancing among the cluster nodes.

The nice thing about totem is that you can compute a pretty good estimate of the maximum throughput and minimum latency. With 100% replication the maximum throughput is the throughput of a single node. On a pc these days this means close to 20,000 messages per second (it's easy to test if you care to take it for a spin - pardon the pun.) The latency would the tcp round-trip latency plus the internal delivery time for a totally-ordered message. The latter depends on the number of nodes. I would guess 20ms for a normal systems - it also depends on whether one entire cpu core is available to run the totem protocol or not.

I guess the IBM system will process more messages - the article mentions 100,000/s. On the other hand since evs4j is free and has the added benefit of simplicity I would say 20,000 messages per sec is nothing to sneeze at.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

I don't know if you've ever worked on financial OMS systems where there are dozens to thousands of clients all sending and recieving bids to buy/sell securities. In this type of scenario, inbound transactions have to be filtered and matched against other transactions.

For example, say I put out a buy for ticker BLAH between 23.00 and 27.00. The messaging system needs to replicate the data for redundancy, but it also needs to perform filtering to figure out if there are sell orders that match my buy order. Now say at T1, my buy order enters the OMS system, and there are no matching sell orders. At T2, 5 orders match my buy criteria, so the messaging system needs to route those 5 order to my trading client. At T3, my trading client recieves the sell orders. At T4, a new order enters the system and has the best price. Should the messaging system wait and batch the message or send it immediately.

In a real production system, it may be handling a constant stream of 1K messages a second, so the JMS needs to batch things for efficiency. When one considers these kinds of factors, is it possible to reach the theoritical throughput for replication? Chances are no, because there's a constant load on the network IO. A scalable and performant JMS has to balance all these different processes. Sometimes a JMS powered application can use topic to filter, but other times it has to filter the content. Totem protocols serve a purpose, but saying that it provides a good model for predicting throughput and latency is much too simplistic.

peter

I don't know if you've ever worked on financial OMS systems where there are dozens to thousands of clients all sending and recieving bids to buy/sell securities.

I have worked in such an environment.

In this type of scenario, inbound transactions have to be filtered and matched against other transactions.For example, say I put out a buy for ticker BLAH between 23.00 and 27.00. The messaging system needs to replicate the data for redundancy, but it also needs to perform filtering to figure out if there are sell orders that match my buy order. Now say at T1, my buy order enters the OMS system, and there are no matching sell orders. At T2, 5 orders match my buy criteria, so the messaging system needs to route those 5 order to my trading client. At T3, my trading client recieves the sell orders. At T4, a new order enters the system and has the best price. Should the messaging system wait and batch the message or send it immediately.

Immediately, of course.

In a real production system, it may be handling a constant stream of 1K messages a second,

In the production system I was familiar with most recently, the system used extremely short messages.

so the JMS needs to batch things for efficiency.

The system I know about does not batch. You cannot wait because 1ms == money. Latency is everything. In fact, it was because this system was so simple and had such low latency that it was able to take over such a very large part of the market.

I would not re-write this system using totem because the latency is so low that adding active replication to the system would add latency also. In fact, this system _is_ replicated using multicast but with fifo ordering, I believe.

When one considers these kinds of factors, is it possible to reach the theoritical throughput for replication? Chances are no, because there's a constant load on the network IO. A scalable and performant JMS has to balance all these different processes. Sometimes a JMS powered application can use topic to filter, but other times it has to filter the content. Totem protocols serve a purpose, but saying that it provides a good model for predicting throughput and latency is much too simplistic.peter

I was only predicting the minimum latency, not the actual latency. If you want to increase the latency by batching on the tcp connection with the clients, you are free to do that, but I would't. It's not needed. And totem can happily send 200-byte messages just as it sends 1500-byte messages.

Guglielmo

I have worked in such an environment.

In this type of scenario, inbound transactions have to be filtered and matched against other transactions.

For example, say I put out a buy for ticker BLAH between 23.00 and 27.00. The messaging system needs to replicate the data for redundancy, but it also needs to perform filtering to figure out if there are sell orders that match my buy order. Now say at T1, my buy order enters the OMS system, and there are no matching sell orders. At T2, 5 orders match my buy criteria, so the messaging system needs to route those 5 order to my trading client. At T3, my trading client recieves the sell orders. At T4, a new order enters the system and has the best price. Should the messaging system wait and batch the message or send it immediately.

Immediately, of course.

Guglielmo

That might be true of some cases, but it's not true for many. If one were to add in pre-trade compliance, sending the message immediately has very little meaning, because the order must pass validation. That validation logic might have to calculate aggregates along with other arbitrary rules. How one implements pre-trade compliance varies greatly, so the picture isn't simple at all. Each process an order must go through may be simple by itself, but once you add it all up, it's a different story.

I've primarily worked with Mutual fund and institutional trading scenarios, but very few shops require 1ms latency. For retail trading it probably makes sense to reduce the latency as much as possible, but for institutional trading things are handled quite differently. Often times small orders are grouped to larger orders, or large orders are broken into smaller orders. All of things could affect how one handles replication and message filtering.

peter

By the way, after I answered your last message I realized that by 1K you meant the number of messages per second, not 1-kilobyte messages. Sorry about that.

However 1,000 messages per second is nothing earth-shattering. I guess you were saying that as an order of magnitude. It reminds me of the old article "The C10K problem", which shows that if you write your code properly and if your OS scales properly a PC can serve 10,000 concurrent tcp connections. It must be at least five years old.

Should the messaging system wait and batch the message or send it immediately.

Immediately, of course.GuglielmoThat might be true of some cases, but it's not true for many.
This one is definitely _not_ what I would call an average system. And it deliberately matches only very simple executions. The idea basically was to do something simple but to match asap. It's also institutional.

If one were to add in pre-trade compliance, sending the message immediately has very little meaning, because the order must pass validation. That validation logic might have to calculate aggregates along with other arbitrary rules. How one implements pre-trade compliance varies greatly, so the picture isn't simple at all.

Are you referring to compliance rules checked by broker/dealers or by the matching _engine_ ?

Each process an order must go through may be simple by itself, but once you add it all up, it's a different story.I've primarily worked with Mutual fund and institutional trading scenarios, but very few shops require 1ms latency.

I didn't mean to say that the latency is 1ms or less. I meant to say that each millisecond is money. Because it gives a competitive advantage to the traders. Probably trading programs.

A few months back I became aware of the K database, made by Kx Systems. It's designed to take in hundreds of thousands of ticks per second and spit out trades according to algorithms. The wrong latency can probably mean the difference between a profitable trading algorithm and unprofitable one.

For retail trading it probably makes sense to reduce the latency as much as possible, but for institutional trading things are handled quite differently. Often times small orders are grouped to larger orders, or large orders are broken into smaller orders. All of things could affect how one handles replication and message filtering.peter

That's true. As I said, in this case the design was not impressive, except for its utter simplicity.

Guglielmo

This news item is a professional product announcement, not a news per se. Shouldn't TSS have a separate section for product announcements like other profile websites do?
I'm sorry if I'm off base here, and rest assured I have no hidden interests in any JMS or messaging product. This is not directed to the SwiftMQ announcement in particular, I've seen many like it in the past, even 3-4 on the main news page at a time.

Prices and AvailabilityThe price for a single SwiftMQ Router license is EUR 990.00 / USD 1,386.00. The price for a SwiftMQ HA Router consisting of 2 HA instances is EUR 2,490.00 / USD 3,486.00.

Andreas - why the 1.4 EUR/USD exchange rate? Considering the current going rate is ~1.21, I'd definitely purchase using Euro currency ...

Andreas - why the 1.4 EUR/USD exchange rate? Considering the current going rate is ~1.21, I'd definitely purchase using Euro currency ...

You can, of course. It's for the banking fees we usually pay for wire transfers/checks/CC payments from outside Europe.