Doing Lots of Good Work Today
Today I've been doing a lot of things that aren't really focused towards one goal as much as it's all about things that folks have been asking for recently, and it's been nice to be able to clear the decks of these things and pretty much bring the supporting things up to snuff.
The first thing I tackled was the request for rolling the logs. I've gotten a request that all apps at The Shop need to have daily logs, and roll them so they can be maintained/archived/etc. by simple shell commands, etc. It turns out that the log4cpp RollingFileAppender can do this, but it sets the rolling based on the size of the file. There's also a manual roll() method, but while this was a possibility, I wanted to see if I could do it a little cleaner.
So I went into the start-up scripts and saw that it really was easy to just copy the file with the addition of the date/time and then writing over the existing files with a simple message. This was really far simpler than adding the necessary code for the RollingFileAppender. So I did that. The result is something that works just wonderfully, and can be placed in a crontab to run anytime they want.
Mark one off the list.
The next item on my list was to make a simple pub/sub example in C++ using The Broker. This was a little harder as the natural mode of the code I have for The Broker is not to be this simplistic, and it took a little bit of work to expose the right things in a clean way to make it simple for others to make traditional pub/sub messaging work. The end result was very nice - you can simply choose to respond to all subscription requests with something, and then you have the ability to "publish" out data and all the registered clients will get it.
It's not reliable messaging and it's not going to take the place of JMS or Tibco, but given that their needs are at that level, this makes it very easy for people to use The Broker in a new and different mode. It really turned out nicely.
Two down.
The next issue was that when the finance model can't calculate the implied vols for an option trade, it's supposed to fall back to the last known good calculation for that instrument on that exchange. The idea being that the differences in the trade prices should be small, and therefore the implieds - if they can't be calculated, should be close.
Adding them wasn't hard, but it's adding a little more to the memory footprint of the app because we need a couple of doubles for each exchange for each instrument. Kind of unavoidable if we want to make access fast and lockless, but it's still got to be done.
Not bad, but not nearly as fun as the other two.
The final task was the creation of a 'flex queue' for the ZeroMQ transmitter. The problem was that there would be cases where I'd want to conflate the outgoing messages, and then other times, I'd want to queue them without conflation. I didn't want to make two versions of the class, so I made a simple pseudo-union of the two types of queues: conflating and non-conflating.
This was interesting in that the struct I made had all the interface elements the queue needed, and then I simply had a union for the pointers, of which I'd create one and then use it. This then allowed me to include a defaulted value in the constructor for whether or not we'd use a conflating queue. With this, it just drops into the existing code and works wonderfully.
In all, four nice additions to the codebase. Good day.