Am 28.02.2012 um 17:23 schrieb Mariano Martinez Peck:
On Tue, Feb 28, 2012 at 5:03 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 28.02.2012 um 16:41 schrieb Mariano Martinez Peck:
Of course, not the fuel you use to go to work every day ;) I am talking about Fuel serializer. In particular, I wonder if our page deserves an update: rmod.lille.inria.fr/web/pier/software/Fuel/Software-using-Fuel
Let me know if there is something I should add.
We are using it in
http://www.2denker.de/product/apitester
I first used image persistence but the image grow to large. Then I added fuel as journal to be written before image save in order to be able to recover from an emergency.
I didn't undersantd this one. What is what you are serializing that you want to be able to recover in case of an emergency?
All of my data. An account can log in and configure the service. The service collects data. All of these modifications should be persisted. I experience image corruption with big images. Every week or so the vm just didn't start the images anymore because it stated "premature end of image file". So I write down all my objects via fuel to disk before I save the image. In case of an emergency (image corruption) I take a fresh image and load back the saved fuel graph. And within 2 minutes I'm once read to go. Now the big parts of the data are in mongo so I don't expect it to happen real soon again.
Now we redo the persistence part. An account object graph is dissected into configuration part and payload part. The payload is written directly to mongo db in a Json format. The configuration part will be written as fuel blob to mongo. Planned is that at startup a configured amount of account fuel blobs are loaded and started. Those configurations have their own processes that write back payload to mongo. Etc.
Just in case you want to know :)
Interested indeed :) I added it under "Custom applications"
thanks, Norbert