LateNightHacking Louis Journal

Auth

I feel a bit frustrated today. We had our group meeting today and pretty much agreed that the focus of our next iteration has to be stability and performance. The annoyance factor of using our app has gotten to the point that one trader even threatened to request to go back to using Redi. The key things to fix are responsiveness, the GUI freeze, and price issues. The price issues sit squarely on my lap (or at least are due to code I wrote) and the GUI freeze is an issue I studied but never drove to a conclusion. (Java gets sulky when VNC is running. Yet, we need VNC.)

The frustrating thing is that it seems like very major chunk of code that I've written (and I've written a bunch in the last two years) needs to be rewritten. It's not that I think I wrote crappy stuff. It's that now that I understand the problems better, there are so many ways that the system could be made to work better. We are running into the fundamental limitations of the original designs. Most of the easy fixes have been done.

<sigh> Maybe I'm just too much of a perfectionist. For example, one problem we have is that the price service deals with disconnects too transparently. There is no notification path for someone wanting to observer some of the state transitions. Basically, the GUI would like to be able to have a little light indicating "disconnected" / "reconnecting" / "connected". Unfortunately, the actual state is manifold and keeps getting more complex. Not only does a price session automatically switch between many low-level sessions automatically, but now the GUI maintains multiple price sessions. This can make trying to track down what the price service is doing quite tricky. I guess the simplest solution would be to try to fire off a message on disconnect or reconnect. But, I'm not sure there's even a good place to send such a message from! The object that manages failover has exposes in interface that was designed to make failover behave the same as maintianing a single connection. It has no concept of failover notification, let alone any concept of price sources.

The other huge problem is that the price service has no way to send a message indicating "no price" which means we are very likely to get stuck data when the source we fail over to has no price for a particular instrument.

The price service data structures need reworking. The entire session stack needs reshuffling - the message interval needs to be at a higher level, there needs to be another state in the reconnection state diagram, more notifications need to be plumbed, commonalities in Instrument Service's and Price Service's use of sessions needs to be factored out, etc. The instrument service needs a new cache coherency model. And then there's all the smaller work items. The price service stream parsers also need to be worked on to handle the vagaries of the data feeds better. The back up instrument service needs to be written. I just realize today that one object that was supposed to isolate and deal with a bunch or race-condition sensitive events is handling them wrongly and needs to be redone. (At least the isolation part worked and I only have one isolated object to rewrite, though I think Nick cloned it for his RMDB bridge, so I'll have to pull that back together as well.) More UIs are needed to jimmy the internal session workings, like forcing a failover remotely, or booting a client off a server. And on top of all this, this is not the most important thing to be working on - I've got to find a good person to hire for the strategies developer position, and it ain't easy.

If I could just get a couple months work done between today and tomorrow, I'd feel much more on top of things.

˜ ™

Ooo! Lullabies!

˜ ™