Discussion in 'Automated Trading' started by nitro, Oct 23, 2010.
Has anyone ever used SSSB for Order Management persistence and Asynchronous messaging?
Yes I have thought about it, but I realized it was too slow and the architecture was too stupid demanding Sql Servers everywhere.
Are you developing in c#?
Well, it would not be for a high frequency system, which comprises maybe three people on ET. It makes zero difference that it takes an extra 50 milliseconds, if that, to process an order that is being updating less than say 200 times a day.
Yep, developing in C#.
I have used MSMQ but not SSSB but now I will look into it.
Are there C# libraries similar to R? What do you use for stats and data mining stuff In c#?
Iti s a great API to use, but it is not made for anything like order handling. I can see it for accounting etc. (backend). The main problems you face are along:
* Performance. It can be slow at times. In the timeframe of order submission.
* You need to handle outdated orders. Elements in service broker stay there until processed. Your order submitter crashes - half an hour it is up - it will continue woirking on orders in the queue.
As I said - great for stuff going to the backend (fills etc.) where both elements are not disadvantages.
If you are interested in a broker with transactional safety/ concurrency then consider a Service Broker in .NET for instance MassTransit or NServiceBus.
They are great frameworks and can handle a high throughput. I recommend such instead of going with SSSB that as previously mentioned is carrying a strange over-exposed enterprise soul.
Thank you! I also found this helpful
The problem with MSMQ is that there is a bunch of things that needs to be gotten just right, e.g., how transactions are handled, how exceptions cause rollbacks, how to stop rolling back endlessly (poison messages), how to integrate with long-running workflows so that the state management boundaries line up, etc. AFAIK, MSMQ is a lite messaging system.
Separate names with a comma.