I’d consider it a good sign that a good part of the CPU cycles are spend on XML serialization/deserialization. I’m a bit surprised by the method name (“fillBuffer” - I’d expected something like “processBytes”), but I’m not to worried about that. I’m not saying there is no room for improvement, but I’m quite happy to see the XML parsing being the most resource-intensive part of the server.
On top of serialization, Kraken performs a lot of protocol-to-protocol translation, as well as maintaining a lot of socket connections. The code base of Kraken could use a refactoring with concurrency/performance in mind (that wasn’t the primary goal of the current code base), but I’m not to surprised that it’s very CPU intensive (and will be, even after improving it).
As for Woodstox (or another replacement of the parser) - although I’m not unhappy with the pull parsing we do now, I believe the implementation is both outdated, and way to customized by us for it to be maintainable. I was already aiming at a replacement in the 4.x version of Openfire. For maintainability, I’d love to go with standard StAX - not sure which implementation, but I’m definitely not ruling out Woodstox.