http://fragmentation.fidessa.com
I have a feeling that this would be important to Aleri and Streambase. I welcome comments from both companies (Jon and Mark?) to explain if and how they might use it (Streambase with Smart Order Routing, Aleri with Liquidity Management).
In particular, would this affect any of the pragmatic work by Robert Almgren (who is an advisor to Streambase)?
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Monday, November 24, 2008
Wednesday, November 19, 2008
Do not mix RFA_String and std::string in Reuters RFA !!!!!!!
Some days, it's good to Always Be Coding. Today, it wasn't.
I just spent an entire day chasing down a problem, trying to merge the Reuters OMM API into our MarketFeed-based app. Thanks to Apurva, I was led to a small paragraph in a Readme file that said:
Known Deficiencies
- Mixing of RFA_String and std::string in application interface and implementation
As soon as I got rid of the std::string references in the code, everything magically worked!
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
I just spent an entire day chasing down a problem, trying to merge the Reuters OMM API into our MarketFeed-based app. Thanks to Apurva, I was led to a small paragraph in a Readme file that said:
Known Deficiencies
- Mixing of RFA_String and std::string in application interface and implementation
As soon as I got rid of the std::string references in the code, everything magically worked!
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Sunday, November 16, 2008
Reuters Market Data Performance Problems Under 64-bit Windows
Our CEP system has a process that reads market data from Reuters RDMS and publishes the ticks to Coral8. Everything runs fine when the market data reader is running on a 32-bit development machine. However, when we put the process onto our 64-bit Windows 2003 server, the market data process steadily consumes about 85% of one core.
We use the Reuters RFA API. This involves using the 32-bit C++ DLLs that RFA provides. Our market data process is mixed-mode between managed C++ and C#, and the unmanaged Reuters DLLs.
In order to get our market data process to run on 64-bit Windows, we need to use the CORFLAGS utility that Microsoft provides. The command-line argument to do this is:
CORFLAGS OurMarketDataReader.exe /32BIT+
The process runs under WOW64, which provides 32-bit emulation under 64-bit Windows systems.
The following MSDN article gives some warnings about WOW64 and performance:
WOW64 is important because it allows you to leverage most of your existing 32-bit code when performance and scalability are not a concern...... Another thing to keep in mind about WOW64 is that it is not designed for applications that require high-performance. At the very least, the WOW64 sub-system needs to extend 32-bit arguments to 64-bits, and truncate 64-bit return values to 32-bits. In the worst case, the WOW64 sub-system will need to make a kernel call, involving not only a transition to the kernel, but also a transition from the processor's 32-bit compatibility mode to its native 64-bit mode. Applications won't be able to scale very well when run under WOW64. For those applications that you would like to leave as 32-bit, test them under WOW64. If the performance is not meeting your expectations, you'll need to look at migrating the application to 64-bit.
Our market data process handles about 3000 ticks per second over about 8000 stocks and currency pairs. In the market data process, I put in 2 caches (it's actually a ring of caches) that the process switches between. Every tick that is read from RDMS is put into a cache (ticks are last-reliable), and every second, the cache is dumped to Coral8. While the cache is being dumped, the other cache takes over.
We are hoping that Reuters will provide either native 64-bit DLLs for RFA, or a native .NET version of RFA that does not involve wrapping the existing 32-bit RFA DLLs. This is the only way that we will be able to get decent performance on 64-bit Windows.
Fortunately, Brian Theodore is now head of the Reuters API group, and we have started to engage with him.
If Reuters can't deliver this to us, then we will probably need to requisition a 32-bit server that is simply devoted to running the market data process. That means a good amount of groveling by me to the Hardware group :-( It also means sending market data over the network to Coral8, which is an additional network hop that we can afford right now, but that we might not want to incur in the future.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
We use the Reuters RFA API. This involves using the 32-bit C++ DLLs that RFA provides. Our market data process is mixed-mode between managed C++ and C#, and the unmanaged Reuters DLLs.
In order to get our market data process to run on 64-bit Windows, we need to use the CORFLAGS utility that Microsoft provides. The command-line argument to do this is:
CORFLAGS OurMarketDataReader.exe /32BIT+
The process runs under WOW64, which provides 32-bit emulation under 64-bit Windows systems.
The following MSDN article gives some warnings about WOW64 and performance:
WOW64 is important because it allows you to leverage most of your existing 32-bit code when performance and scalability are not a concern...... Another thing to keep in mind about WOW64 is that it is not designed for applications that require high-performance. At the very least, the WOW64 sub-system needs to extend 32-bit arguments to 64-bits, and truncate 64-bit return values to 32-bits. In the worst case, the WOW64 sub-system will need to make a kernel call, involving not only a transition to the kernel, but also a transition from the processor's 32-bit compatibility mode to its native 64-bit mode. Applications won't be able to scale very well when run under WOW64. For those applications that you would like to leave as 32-bit, test them under WOW64. If the performance is not meeting your expectations, you'll need to look at migrating the application to 64-bit.
Our market data process handles about 3000 ticks per second over about 8000 stocks and currency pairs. In the market data process, I put in 2 caches (it's actually a ring of caches) that the process switches between. Every tick that is read from RDMS is put into a cache (ticks are last-reliable), and every second, the cache is dumped to Coral8. While the cache is being dumped, the other cache takes over.
We are hoping that Reuters will provide either native 64-bit DLLs for RFA, or a native .NET version of RFA that does not involve wrapping the existing 32-bit RFA DLLs. This is the only way that we will be able to get decent performance on 64-bit Windows.
Fortunately, Brian Theodore is now head of the Reuters API group, and we have started to engage with him.
If Reuters can't deliver this to us, then we will probably need to requisition a 32-bit server that is simply devoted to running the market data process. That means a good amount of groveling by me to the Hardware group :-( It also means sending market data over the network to Coral8, which is an additional network hop that we can afford right now, but that we might not want to incur in the future.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Saturday, November 15, 2008
Followup to "Do you need a Commercial CEP System?"
Richard Bentley of Apama has a great post in which he details the various uses of Apama in a number of financial companies. Richard's post and Tim Bass's companion post are two additional ways of thinking about the viability of commercial CEP engines.
My previous post concluded that
1) If I had a large team of developers, AND I had a number of pre-written frameworks that provided input and output adapters, AND I had a relatively easy use case (ie: simple aggregations, simple pricing, etc), AND if there was no existing vendor solution, then I would prefer to write everything ourselves. (All four conditions need to be satisfied.) I would choose this path because it gives us the maximum amount of control over the engine.
2) If I had a small team of developers, and money was no object, and if there was no existing vendor solution, then I would purchase a CEP engine from a vendor. If money was tight, I would probably opt for Esper. I would have to balance my budget with the lost opportunity cost. If the opportunity cost was a lot greater, then I might go for a vertical CEP application, if one existed.
If I needed an algo trading application and a generc CEPengine , why not use Apama?
Apama has been in a sweet spot for a long time, and Richard Bentley has seen the fruits of this. They have offered a generic CEP solution for a while, but their claim to fame is that people like John Bates and Mark Palmer helped to create a trading-solution-in-a-box. When I hear people at my firm talk about Apama, they talk about it as if it were its own class of applications, much in the way people refer to Ketchup now instead of Catsup. They don't even know that Apama is related to CEP.
Where do I think the future of CEP lies? In building blocks that you can choose from in order to create applications. A risk management block, an algo trading block, a pricing block, a FIX processing block, a market surveillance block. These might be sold like Legos. You choose an algo trading block, which comes with the engine, pre-written code, a market data adapter of your choice, and a FIX adapter. You can snap in a risk management block. You can snap in a P&L block. All of these blocks come with source code so that you can tune them.
These pre-written blocks will have been written, tuned, and verified by the vendor. There would be less of a chance of a developer struggling with Streaming SQL.
This is something that I always thought would be done by an enterprising third party. However, the vendors themselves are moving in this direction. They are all trying to catch up to Apama in the financial arena, while trying to maintain their excellence in their offering of a general purpose CEP engine.
So far, I have selfishly focused on financial applications. However, there are many CEP applications in other industries, like gaming, transportation, and defense. All of them share the same characteristics. Monitor a bunch of real-time actions and warn when a certain condition is true. So, a generic surveillance block would be great. The surveillance block might come with a choice of adapters for the most popular sensors . (Tim Bass can tell me if I have been smoking crack here.)
It may be very difficult to come up with an "application block" that will solve all facets of a domain correctly. Can you come up with a risk management app block that can be used right out of the box? Probably not. However, a thoughtful architecture, combined with lots of market research, and combined with lot of extensibility points in the application block, will probably go a long way. In that sense, the vendors should look at how Microsoft architected their Enterprise Application Blocks.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
My previous post concluded that
1) If I had a large team of developers, AND I had a number of pre-written frameworks that provided input and output adapters, AND I had a relatively easy use case (ie: simple aggregations, simple pricing, etc), AND if there was no existing vendor solution, then I would prefer to write everything ourselves. (All four conditions need to be satisfied.) I would choose this path because it gives us the maximum amount of control over the engine.
2) If I had a small team of developers, and money was no object, and if there was no existing vendor solution, then I would purchase a CEP engine from a vendor. If money was tight, I would probably opt for Esper. I would have to balance my budget with the lost opportunity cost. If the opportunity cost was a lot greater, then I might go for a vertical CEP application, if one existed.
If I needed an algo trading application and a generc CEPengine , why not use Apama?
Apama has been in a sweet spot for a long time, and Richard Bentley has seen the fruits of this. They have offered a generic CEP solution for a while, but their claim to fame is that people like John Bates and Mark Palmer helped to create a trading-solution-in-a-box. When I hear people at my firm talk about Apama, they talk about it as if it were its own class of applications, much in the way people refer to Ketchup now instead of Catsup. They don't even know that Apama is related to CEP.
Where do I think the future of CEP lies? In building blocks that you can choose from in order to create applications. A risk management block, an algo trading block, a pricing block, a FIX processing block, a market surveillance block. These might be sold like Legos. You choose an algo trading block, which comes with the engine, pre-written code, a market data adapter of your choice, and a FIX adapter. You can snap in a risk management block. You can snap in a P&L block. All of these blocks come with source code so that you can tune them.
These pre-written blocks will have been written, tuned, and verified by the vendor. There would be less of a chance of a developer struggling with Streaming SQL.
This is something that I always thought would be done by an enterprising third party. However, the vendors themselves are moving in this direction. They are all trying to catch up to Apama in the financial arena, while trying to maintain their excellence in their offering of a general purpose CEP engine.
So far, I have selfishly focused on financial applications. However, there are many CEP applications in other industries, like gaming, transportation, and defense. All of them share the same characteristics. Monitor a bunch of real-time actions and warn when a certain condition is true. So, a generic surveillance block would be great. The surveillance block might come with a choice of adapters for the most popular sensors . (Tim Bass can tell me if I have been smoking crack here.)
It may be very difficult to come up with an "application block" that will solve all facets of a domain correctly. Can you come up with a risk management app block that can be used right out of the box? Probably not. However, a thoughtful architecture, combined with lots of market research, and combined with lot of extensibility points in the application block, will probably go a long way. In that sense, the vendors should look at how Microsoft architected their Enterprise Application Blocks.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Blogging about Layoffs
The New York Times has an interesting article about companies preemptively blogging about layoffs that are about to occur. It seems that some companies want to have the first shot at controlling the message before it is distorted by other bloggers and the general media.
You don't get much information through blogs when layoffs happen in Wall Street and The City. Sometimes, you will read a snippet or two on Here Is The City. But, there is not much.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
You don't get much information through blogs when layoffs happen in Wall Street and The City. Sometimes, you will read a snippet or two on Here Is The City. But, there is not much.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Do You Really Need a Commercial CEP System?
Almost every day, we ask ourselves if making the decision to use a commercial CEP system was worth it. If you have been following my blog for the past 14 months, you have traced my thought processes around choosing whether to build vs. buy, and my choice of vendor. And, almost every day, when doing my 30 minutes of elliptical, my mind wanders and I start reflecting on my decision and wondering if it was correct to buy a commercial CEP system.
Our system does not do any sophisticated pattern matching yet. Right now, we are doing a lot of aggregations, groupings, rollups, and simple comparison testing in order to generate alerts and real-time dashboard information.
As long-time blog readers know, we were able to get a working prototype of a very early version of our system up and running in a few days with hand-crafted C# code. But, that’s just us. We had a lot of the elements already in place that the commercial CEP systems offer. But, what if we didn’t have that framework to leverage?
Let’s say that I recently got laid off from my Wall Street company (a very real situation nowadays), and I and a few friends decided to start a small prop trading shop out of my basement. We are a 3 traders and a developer. We need to build ourselves a small algo or high-frequency trading system. What do we need?
We need real-time market data from Reuters or Bloomberg, or if I am interested in something really fast, I might try Activ. We need to persist ticks and results into a database, so we will need both a tick database (something like KDB or Vhayu) and a standard database like SQL Server or MySQL. We need feed handlers that can talk to the engine that maintains our models. We need a GUI so the traders can monitor the market and the orders. We need a FIX engine so that we can send orders out to the markets.
I give my developer explicit orders to get it done as fast as possible. I don’t want him spending time writing a beautifully crafted framework that solves a general problem. I want him to write the simplest thing possible. If we are using Bloomberg, I want him to use the BBAPI to get the market data and put it into the trading engine in the fastest possible way and with the lowest latency. If we have to aggregate something, I want him to take the data, sum it up, and stick it into some hash table that is indexed by symbol.
With all of my requirements in place, I know that it would take my tech guy 6 months to get us up and trading on this new system. It would cost us roughly $100K in development costs. However, our opportunity cost is huge, as we have not been able to put on some of the trades that we would have liked to.
What does it cost to purchase a commercial CEP system? Coral8 charges $15K per core for the primary machine. There are discounts for the HA (high availability) machines. Aleri charges $26K per core. When we met with Streambase in early 2007, they told us that is would take $500K to get us up and running (I don’t know if they have reduced their price.) If I have a 4 CPU dual-core machine, then it would cost $120K for Coral8 and $208K for Aleri. Plus, most companies charge a 15-20% annual maintenance fee.
What do I get for that amount?
I get basically a real-time matching engine. I get a high-level language that, if my traders bother to learn and don’t get themselves into trouble with, will let my traders “tweak” their models. I get a bunch of input and output adapters that will let me get information in and out of the engine. (I might have to pay a lot more for a Reuters or Bloomberg adapter, and that is only if my vendor has one.) I get an IDE that, along with the high-level language, I can use to develop the models.
What do I give up if I buy a commercial CEP engine? I give up the right to fix the internals of the engine if I find a bug. I am at the mercy of the vendor’s release cycle. If I find a bug, and the vendor tells me that it will be fixed in 3 months, when the next release comes out, I won’t be happy. 3 months is really 4 months, because initial major releases always have problems with them. I give up the right to add new features when I need them. I am living in fear that, in this fiscal environment, the VC’s might decide to pull all funding out from under the vendor’s feet.
On the plus side, I get to tap into the vendor’s customer support staff, thus freeing my programmer to do other things. I might get to interface with other users of the CEP system so I could learn best practices.
Now that I have my commercial CEP system, what now? I have to get my tech guy to learn a new language (the Streaming SQL variants that are offered by the CEP vendors are easy to learn, but as we have come to discover, if you don’t use it properly, you can get yourself into a big mess). If we don’t have a specific input adapter (Bloomberg) or output adapter (FIX) that the vendor provides, then my developer has to write it himself. My developer still has to program the models, but now we have to worry if the vendor’s language is powerful and flexible enough to support the programming of the model.
If we find a blocking bug in the CEP engine, or if we find a language feature that we desperately need, then we are at the mercy of the vendor.
On the other hand, the vendor has a highly tuned multi-threaded engine, so that’s a big chunk of development that we don’t have to do. The CEP engine has cool things that we need, like sliding windows and nested pattern matching.
It’s a big decision to make. If I work at a large company, and I have several different frameworks available to me, and I have 5 full-time developers, then I could see writing everything from scratch. If I was a small startup, and I could not afford the market data fees AND the CEP engine, then I might look to a free solution like Esper. If I was a 5-20 person shop, then my decision is tougher.
What would make the decision easier would be to see if a commercial CEP vendor has a vertical application that solved our needs. A trading system in a box. That's the direction that Apama has taken, and that Mark Palmer is trying to pursue with Streambase. Coral8 will follow that path with the hiring of Colin, and Aleri has its eyes on that direction too.,
Our system does not do any sophisticated pattern matching yet. Right now, we are doing a lot of aggregations, groupings, rollups, and simple comparison testing in order to generate alerts and real-time dashboard information.
As long-time blog readers know, we were able to get a working prototype of a very early version of our system up and running in a few days with hand-crafted C# code. But, that’s just us. We had a lot of the elements already in place that the commercial CEP systems offer. But, what if we didn’t have that framework to leverage?
Let’s say that I recently got laid off from my Wall Street company (a very real situation nowadays), and I and a few friends decided to start a small prop trading shop out of my basement. We are a 3 traders and a developer. We need to build ourselves a small algo or high-frequency trading system. What do we need?
We need real-time market data from Reuters or Bloomberg, or if I am interested in something really fast, I might try Activ. We need to persist ticks and results into a database, so we will need both a tick database (something like KDB or Vhayu) and a standard database like SQL Server or MySQL. We need feed handlers that can talk to the engine that maintains our models. We need a GUI so the traders can monitor the market and the orders. We need a FIX engine so that we can send orders out to the markets.
I give my developer explicit orders to get it done as fast as possible. I don’t want him spending time writing a beautifully crafted framework that solves a general problem. I want him to write the simplest thing possible. If we are using Bloomberg, I want him to use the BBAPI to get the market data and put it into the trading engine in the fastest possible way and with the lowest latency. If we have to aggregate something, I want him to take the data, sum it up, and stick it into some hash table that is indexed by symbol.
With all of my requirements in place, I know that it would take my tech guy 6 months to get us up and trading on this new system. It would cost us roughly $100K in development costs. However, our opportunity cost is huge, as we have not been able to put on some of the trades that we would have liked to.
What does it cost to purchase a commercial CEP system? Coral8 charges $15K per core for the primary machine. There are discounts for the HA (high availability) machines. Aleri charges $26K per core. When we met with Streambase in early 2007, they told us that is would take $500K to get us up and running (I don’t know if they have reduced their price.) If I have a 4 CPU dual-core machine, then it would cost $120K for Coral8 and $208K for Aleri. Plus, most companies charge a 15-20% annual maintenance fee.
What do I get for that amount?
I get basically a real-time matching engine. I get a high-level language that, if my traders bother to learn and don’t get themselves into trouble with, will let my traders “tweak” their models. I get a bunch of input and output adapters that will let me get information in and out of the engine. (I might have to pay a lot more for a Reuters or Bloomberg adapter, and that is only if my vendor has one.) I get an IDE that, along with the high-level language, I can use to develop the models.
What do I give up if I buy a commercial CEP engine? I give up the right to fix the internals of the engine if I find a bug. I am at the mercy of the vendor’s release cycle. If I find a bug, and the vendor tells me that it will be fixed in 3 months, when the next release comes out, I won’t be happy. 3 months is really 4 months, because initial major releases always have problems with them. I give up the right to add new features when I need them. I am living in fear that, in this fiscal environment, the VC’s might decide to pull all funding out from under the vendor’s feet.
On the plus side, I get to tap into the vendor’s customer support staff, thus freeing my programmer to do other things. I might get to interface with other users of the CEP system so I could learn best practices.
Now that I have my commercial CEP system, what now? I have to get my tech guy to learn a new language (the Streaming SQL variants that are offered by the CEP vendors are easy to learn, but as we have come to discover, if you don’t use it properly, you can get yourself into a big mess). If we don’t have a specific input adapter (Bloomberg) or output adapter (FIX) that the vendor provides, then my developer has to write it himself. My developer still has to program the models, but now we have to worry if the vendor’s language is powerful and flexible enough to support the programming of the model.
If we find a blocking bug in the CEP engine, or if we find a language feature that we desperately need, then we are at the mercy of the vendor.
On the other hand, the vendor has a highly tuned multi-threaded engine, so that’s a big chunk of development that we don’t have to do. The CEP engine has cool things that we need, like sliding windows and nested pattern matching.
It’s a big decision to make. If I work at a large company, and I have several different frameworks available to me, and I have 5 full-time developers, then I could see writing everything from scratch. If I was a small startup, and I could not afford the market data fees AND the CEP engine, then I might look to a free solution like Esper. If I was a 5-20 person shop, then my decision is tougher.
What would make the decision easier would be to see if a commercial CEP vendor has a vertical application that solved our needs. A trading system in a box. That's the direction that Apama has taken, and that Mark Palmer is trying to pursue with Streambase. Coral8 will follow that path with the hiring of Colin, and Aleri has its eyes on that direction too.,
Friday, November 14, 2008
Reuters Config Files - Where do they go?
If you are using the Reuters RFA 6.x APIs to consume market data, you know that there are three config files that RFA needs to find. These configuration files are
Usually, if you are running a console or WinForms application, you put these config files in the same directory as your executable.
However, what if you are running a Windows Service that uses RFA?
After some experimentation, we found that you need to store the files in these places:
A service or an executable that uses RFA (the Marketfeed API, not the OMM API) uses 32-bit DLLs. This is because Reuters does not yet have 64-bit DLLs for RFA. Therefore, you need to use CorFlags.exe on a 64-bit Windows 2003 server in order to get your application to run.
Thanks to the wonderful Procmon utility from SysInternals for helping us out with this issue.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
- RFA.CFG
- appendix_a
- enumtype.def
Usually, if you are running a console or WinForms application, you put these config files in the same directory as your executable.
However, what if you are running a Windows Service that uses RFA?
After some experimentation, we found that you need to store the files in these places:
- Windows 32 - Put the files in c:\WINNT\system32
- Windows 64 - Put the files in c:\WINNT\SysWow64
A service or an executable that uses RFA (the Marketfeed API, not the OMM API) uses 32-bit DLLs. This is because Reuters does not yet have 64-bit DLLs for RFA. Therefore, you need to use CorFlags.exe on a 64-bit Windows 2003 server in order to get your application to run.
- corflags mydll /32BIT+
Thanks to the wonderful Procmon utility from SysInternals for helping us out with this issue.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Tuesday, November 11, 2008
Random Notes
Two new blogs:
The News Before The News
Rodrick Brown
Rodrick is one of the few people that mention his ex-employers by name (Lehman and Bank of America), and describes the experiences of working in those places as an Infrastructure Architect for Equities.
Here is a screencast that contrasts Java vs K. I have a resolution that, before I fade away, I will teach myself K. (The creator of the screencast went to Stuyvesant High School. Go Stuy!)
By the way, I hear that Niall Dalton has left Kx Systems. Good luck to Niall, our favorite stunt programmer.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
The News Before The News
Rodrick Brown
Rodrick is one of the few people that mention his ex-employers by name (Lehman and Bank of America), and describes the experiences of working in those places as an Infrastructure Architect for Equities.
Here is a screencast that contrasts Java vs K. I have a resolution that, before I fade away, I will teach myself K. (The creator of the screencast went to Stuyvesant High School. Go Stuy!)
By the way, I hear that Niall Dalton has left Kx Systems. Good luck to Niall, our favorite stunt programmer.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Monday, November 10, 2008
My Five Minutes of Musical Fame
While working out on the elliptical the other day, I was thinking about my musical career and my former bandmates. I never became a professional musician, but I have certainly had some mild touches with great players who went on to become pro musicians.
I first learned to play the drum set as a sophomore in high school. My very first band was based in a town called Forest Hills Gardens in Queens, New York. We were best friends with another band, and all of us used to jam with each other. The lead guitarist of the other band was guy by the name of Chieli Minucci (http://www.chielimusic.com/). Chieli went on to be a world-known guitarist in the smooth jazz circles as the leader of a band called SFX.
As a junior, I played with a progressive rock group from Long Island called Heresy. We played some pretty sophisticated covers of songs by ELP (we played the entire Karn Evil 9 suite), King Crimson, Gentle Giant, and Jethro Tull (the entire Thick as a Brick). The bassist, Tony Garone (http://www.garone.net/tony) has gone on to play with Jethro Tull at some of the Tull conventions.
As a senior in high school, I played with an experimental free-jazz-rock-space band called Third Sun. Although the sax/flute/synth play, Douglass Walker, went on to become one of the early pioneers of the American Space Rock scene, the player who had the most success was Pablo “Coca” Calagero (http://www.myspace.com/pablocalogero). He went on to play sax with people like Tito Puente, Eddie Palmieri, and other famous people in the Latin Jazz scene. He also had a part in the movie The Mambo Kings.
When I went to college, within the first few weeks, I hooked up with a free jazz group. The trumpet player was Richard Edson. He went on to fame as the first drummer of the noise group Sonic Youth. Richard went on to be an actor, and had significant roles in movies like Good Morning Vietnam and Do the Right Thing. Most recently, he has been on a series of commercials for the Travelers Insurance Company as the human embodiment of risk.
After my sophomore year of college, I pretty much gave up on playing with small groups. I dove into the world of classical music, and from then on, the only groups I cared to play with were orchestras and wind ensembles, in addition to playing solo percussion and marimba. But, by association, I have had my five minutes of fame.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
I first learned to play the drum set as a sophomore in high school. My very first band was based in a town called Forest Hills Gardens in Queens, New York. We were best friends with another band, and all of us used to jam with each other. The lead guitarist of the other band was guy by the name of Chieli Minucci (http://www.chielimusic.com/). Chieli went on to be a world-known guitarist in the smooth jazz circles as the leader of a band called SFX.
As a junior, I played with a progressive rock group from Long Island called Heresy. We played some pretty sophisticated covers of songs by ELP (we played the entire Karn Evil 9 suite), King Crimson, Gentle Giant, and Jethro Tull (the entire Thick as a Brick). The bassist, Tony Garone (http://www.garone.net/tony) has gone on to play with Jethro Tull at some of the Tull conventions.
As a senior in high school, I played with an experimental free-jazz-rock-space band called Third Sun. Although the sax/flute/synth play, Douglass Walker, went on to become one of the early pioneers of the American Space Rock scene, the player who had the most success was Pablo “Coca” Calagero (http://www.myspace.com/pablocalogero). He went on to play sax with people like Tito Puente, Eddie Palmieri, and other famous people in the Latin Jazz scene. He also had a part in the movie The Mambo Kings.
When I went to college, within the first few weeks, I hooked up with a free jazz group. The trumpet player was Richard Edson. He went on to fame as the first drummer of the noise group Sonic Youth. Richard went on to be an actor, and had significant roles in movies like Good Morning Vietnam and Do the Right Thing. Most recently, he has been on a series of commercials for the Travelers Insurance Company as the human embodiment of risk.
After my sophomore year of college, I pretty much gave up on playing with small groups. I dove into the world of classical music, and from then on, the only groups I cared to play with were orchestras and wind ensembles, in addition to playing solo percussion and marimba. But, by association, I have had my five minutes of fame.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Sunday, November 09, 2008
Welcome to Jeff
Jeff joins the Complex Event Processing team next week. He was recently with Oracle, and he will be helping us out as we start to take our system across different asset classes and will help us roll out CEP on a global basis.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Monday, November 03, 2008
Microsoft Oslo SDK Setup Failure
It looks like you need SQL Server 2008 installed in order to use Oslo. Microsoft does not state this anywhere, nor does its installation program warn you of this. Here is my experience in trying to install Oslo on my laptop.
1) I downloaded the Oslo SDK CTP from the Microsoft site.
2) I extracted the files, and ran the setup. The setup completed without any warnings and error messages. So far so good.
3) I have Windows Vista SP1 with both SQL Server 2005 and SQL Server Express 2005 installed. I opened up SQL Server Management Studio and searched both servers for any trace of the Oslo repositories. No luck.
4) In the directory C:\Users\Marc\AppData\Local\Temp, I found a file called Oslo_Repository_Setup.log. I opened this file in Notepad and found the following lines:
Property(C): ExecuteSilentCmd = "C:\Program Files\Microsoft Repository\CreateRepository.exe" /v+
Property(C): WIXUI_EXITDIALOGOPTIONALTEXT = Warning: repository database creation failed. Please see %temp%\RepositorySetup.log for more details.
However, at the very end of the file, I found the following lines:
MSI (c) (B0:48) [06:51:33:985]: Product: Microsoft Codename "Oslo" Repository -- Installation completed successfully.
MSI (c) (B0:48) [06:51:33:987]: Windows Installer installed the product. Product Name: Microsoft Codename "Oslo" Repository. Product Version: 3.0.1342.0. Product Language: 1033. Installation success or error status: 0.
So, it looks like the installer considered the installation to be a success, even though the repository could not be created.
5) In the file RepositorySetup.log, I found the following lines:
message: Creating repository database ...
error: Cannot assign a default value to a local variable.
Must declare the scalar variable "@login".
[11/3/2008 - 6:51:24]Completed execution of: "C:\Program Files\Microsoft Repository\CreateRepository.exe" /v+
6) We see other users who have reported this. Microsoft says that this is not a bug. It is "By Design".
7) At this link, we find a comment by Carlos Gomez of Microsoft:
We do not support Sql Server 2005 at all, because some of the repository features depend on Sql Server Katmai.
In other words, you need to have SQL Server 2008 installed. Well, my company is still on SS 2005, so I guess that means that Oslo will be just for my personal experimentation for the forseeable future.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
1) I downloaded the Oslo SDK CTP from the Microsoft site.
2) I extracted the files, and ran the setup. The setup completed without any warnings and error messages. So far so good.
3) I have Windows Vista SP1 with both SQL Server 2005 and SQL Server Express 2005 installed. I opened up SQL Server Management Studio and searched both servers for any trace of the Oslo repositories. No luck.
4) In the directory C:\Users\Marc\AppData\Local\Temp, I found a file called Oslo_Repository_Setup.log. I opened this file in Notepad and found the following lines:
Property(C): ExecuteSilentCmd = "C:\Program Files\Microsoft Repository\CreateRepository.exe" /v+
Property(C): WIXUI_EXITDIALOGOPTIONALTEXT = Warning: repository database creation failed. Please see %temp%\RepositorySetup.log for more details.
However, at the very end of the file, I found the following lines:
MSI (c) (B0:48) [06:51:33:985]: Product: Microsoft Codename "Oslo" Repository -- Installation completed successfully.
MSI (c) (B0:48) [06:51:33:987]: Windows Installer installed the product. Product Name: Microsoft Codename "Oslo" Repository. Product Version: 3.0.1342.0. Product Language: 1033. Installation success or error status: 0.
So, it looks like the installer considered the installation to be a success, even though the repository could not be created.
5) In the file RepositorySetup.log, I found the following lines:
message: Creating repository database ...
error: Cannot assign a default value to a local variable.
Must declare the scalar variable "@login".
[11/3/2008 - 6:51:24]Completed execution of: "C:\Program Files\Microsoft Repository\CreateRepository.exe" /v+
6) We see other users who have reported this. Microsoft says that this is not a bug. It is "By Design".
7) At this link, we find a comment by Carlos Gomez of Microsoft:
We do not support Sql Server 2005 at all, because some of the repository features depend on Sql Server Katmai.
In other words, you need to have SQL Server 2008 installed. Well, my company is still on SS 2005, so I guess that means that Oslo will be just for my personal experimentation for the forseeable future.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Sunday, November 02, 2008
Colin Clark - The New Head of FinServ at Coral8
Colin told me that I can post the good news .... he just accepted the job of Executive Vice President of Financial Services at Coral8, reporting directly to the CEO.
This is a great thing for Coral8.
As I have written here before, I feel that financial services domain knowledge was not one of Coral8's strong points, and I think that they would be the first to admit this. I personally think that it is difficult to target Wall Street firms from the dry air of Silicon Valley. I would venture to say that not one of the people who we interact with at Coral8 comes from a financial services background, and although they tried very hard, they were never able to give us a full-time support person in New York, let alone someone who knew anything about trading apps.
Now in the space of a few weeks, Coral8 bagged Mike DiStefano of Gemstone and Colin Clark, the ex-CEO of Kaskad. And, just when I thought that Coral8 was going to de-emphasize their efforts in financial services (not that I would have blamed them!).
Colin will be building up a financial services organization in the US and in continental Europe and the UK. Coral8 has no current sales organization on the right side of the pond, and when we go global with our CEP system, it is nice to have local support from the vendor.
What is great for us is that Colin actually cares about what we, as a capital markets firm, do with Coral8. And, let me tell you ... we have a laundry list for Colin that will keep him busy for many months. We have requests in the areas of real-time OLAP, entitled subscriptions, persistence, object cache connectivity, performance improvements with ad-hoc queries in the Coral8 public windows, better .NET support (which we have been promised already), better profiling and performance monitoring, better documentation, and more.
And, did I mention that Colin is a pilot? (My goal is to have our vendors stocked with pilots and percussionists.)
Welcome to Coral8, Colin. I hope you are ready for us, cause we are coming at you like one of those planes that you see in the Reno Air Races.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
This is a great thing for Coral8.
As I have written here before, I feel that financial services domain knowledge was not one of Coral8's strong points, and I think that they would be the first to admit this. I personally think that it is difficult to target Wall Street firms from the dry air of Silicon Valley. I would venture to say that not one of the people who we interact with at Coral8 comes from a financial services background, and although they tried very hard, they were never able to give us a full-time support person in New York, let alone someone who knew anything about trading apps.
Now in the space of a few weeks, Coral8 bagged Mike DiStefano of Gemstone and Colin Clark, the ex-CEO of Kaskad. And, just when I thought that Coral8 was going to de-emphasize their efforts in financial services (not that I would have blamed them!).
Colin will be building up a financial services organization in the US and in continental Europe and the UK. Coral8 has no current sales organization on the right side of the pond, and when we go global with our CEP system, it is nice to have local support from the vendor.
What is great for us is that Colin actually cares about what we, as a capital markets firm, do with Coral8. And, let me tell you ... we have a laundry list for Colin that will keep him busy for many months. We have requests in the areas of real-time OLAP, entitled subscriptions, persistence, object cache connectivity, performance improvements with ad-hoc queries in the Coral8 public windows, better .NET support (which we have been promised already), better profiling and performance monitoring, better documentation, and more.
And, did I mention that Colin is a pilot? (My goal is to have our vendors stocked with pilots and percussionists.)
Welcome to Coral8, Colin. I hope you are ready for us, cause we are coming at you like one of those planes that you see in the Reno Air Races.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Subscribe to:
Posts (Atom)
