Community
Participate
Working Groups
Since Job configuration and job runtime information is stored in the same ZK node, we often encounter ZK write errors through concurrent write access on this ZK job nodes To solve this problem, we need to do: 1. summarize the current job information stored in ZK 2. propose a ZK tree/node structure to store job configuration and job runtime information in seperate nodes 3. consider the option to remove unnecessary information from ZK, if possible
I'm currently working on a concept on how to address this. General ideas are: * A consequent separation between configurational data, job history and runtime information * Less ZK-Writes through removing of Jobs-Preferences and Active-Jobs node * Using of interface layers on all parts for really adding the possibillity to add alternative implementations * More Handy JobQueue-Implementation However, this might take some time, especially since we might need to integrate JGroups into Gyrex. I don't think that I can spare that much time on it, to complete this prior to the upcoming luna release.
