Nate On The Net

Just a little note that if you need to prevent near-plane clipping while moving the camera into your volume, there seems to be a simple way to achieve this effect (in OpenGL): simply enable GL_DEPTH_CLAMP while rendering the front and back faces of the bounding volume you are casting from. There may be a better way to do this, but this seems to work and with no noticeable performance loss.

Just a minor site update – I’ve tested this layout in Chrome, Firefox, and the latest IE, but it might break on older browsers.:) In any case, welcome to the new front page! I’ve also pulled my Twitter/Plurk feed in, which I update a good bit more frequently than this, so hopefully that helps things stay more current.

As always, I’m working on a billion projects. OpenGL and direct volume rendering of procedural volumes via shaders is my current primary project:

I’m also still slowly pounding away at a third novel, more science fiction. I’ve tweaked my existing novels to be available as PDFs using a more readable layout – see my writing for that. Haven’t done much music lately, besides tinkering with dubstep.

And I’ve been running and doing a bit of TKD, so that about sums it up.:)

This is more a case of posting here to remind myself, but maybe it will help someone out. I just ran into a case where QuickFIX/J seemed to be stacking up endless messages in a LinkedHashMap object (messageQueue) in SessionState.java (discovered using a heap dump and the helpful Memory Analysis Tool from Eclipse) and spent a few hours banging my head on the wall trying to figure out why. After I bothered to read the QFJ code, I understood why, but it’s non-obvious.

Essentially, QFJ’s Session class parses each incoming message, and then attempts to parse any “queued” messages from the aforementioned LinkedHashMap before doing it all again. The contents of the LinkedHashMap (in my case, built up to 500+ megabytes before bringing the JVM to flaming ruin) are only messages that result from a “sequence number too high” error. So if your QFJ application throws, for example, a repeated NPE while handling FIX messages, in certain cases this can trigger a “sequence number too high” problem and will result in FIX messages stacking up in that QFJ-side queue.

I’m not sure if this is really a bug in QFJ or not — I should have checked the QFJ event log sooner, and I might have solved this without noticing the pileup. I suspect that’s why there isn’t a lot of information to be easily found online about the issue – other people just debug their applications correctly.;) That said, it’s non-obvious to me that anything I do in my QFJ application should result in some map inside QFJ’s core classes growing out of control. Hence, noted for myself and anyone else who may care/be curious.:)