Community
Participate
Working Groups
The jobs history is currently stored together with jobs definition in ZooKeeper using cloud preferences. This seems to be a scalability issue especially with growing number of jobs executed repeatably. We should look at abstracting the job history storage so that alternate implementations could be provided.
As part of this we should also investigate if moving job definitions out of the preferences into the alternate storage is also an option. Another question that needs to be answered is whether scheduling and execution coordination should stay in ZooKeeper or if the alternate storage provides atomic ways of dealing with job states. FWIW, the ephemeral nodes in ZooKeeper are great for detected failing workers and lost jobs. However, it's not trivial to manage states in parallel with an underlying store. One system should be preferred.
FWIW, the commit initially targeted at this bug actually fixed bug 391401. http://git.eclipse.org/c/gyrex/gyrex-platform.git/commit/?id=6421cb3d15a5a8948d5aa2a58600e72603727357 Now we have to think about what we should do with this one.
No alternate storage will be provided in Gyrex. The storage provider interface created in bug 391401 is all for now. It allows to plug-in custom storage providers.