On Wed, Feb 26, 2014 at 5:30 PM, Norbert Hartl <[email protected]> wrote:
> > Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck < > [email protected]>: > > > > > On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <[email protected]> wrote: > >> >> Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck < >> [email protected]>: >> >> Just be careful 2: "I switched one of my servers to dump to stack with >> fuel to disk if an exception occurs. " >> Once it happened to me the stack I was taking for serializing an error >> was too big. Too big because it even reached the UI. The UI has lots of >> sensible objects that change quite frequently. So my graph to serialize was >> big and the graph changed quite frequently. Result: Fuel throwing error >> because the graph to serialize changed while being serialized. >> Oh...exception? Fuel out exception! exception. Oh exception? ... >> >> Good point, thanks! >> >> So yeah..the fact that Fuel was throwing an error causes a loop so be >> careful of that as well. >> >> If the serialization fails I just consider it an unrecoverable error and >> proceed. I will add a logging message for that case so I can at least so >> when something does not working while fueling out the stack. >> >> > Forgot... "just be careful 3": it may happen that you cannot correctly > *materialize > (not serialization)* the graph: a method has changed, a class is > missing..whatever... So what I did in the fuel out of failure tests is to > add to the serializer header all the info (as plain strings) that we > normally have in the PharoDebug.log. This "header" will always be able to > be materialized.... this way, I don't have the risk of not being able to > materialize and hence loose info, and yet I don't need PharoDebug.log as > well. If you don't do what I did, then you likely need also pharoDebug.log > just in case... > > That is unlikely to happen. My workflow is that every deployed image goes > through the CI server. If a problem arises I download that same image from > the CI server and load the stacks back into this. Everything is else is > IMHO asking for trouble because contexts won't map properly. > > +9999. That's the safest thing to do: use an image with the same "code" as the one that failed. > I recommend everyone interested in this topic to take a look to: > #serializeTestFailureContext:toFileNamed: > > That is what I am using because it does what I want to happen. It is only > the selector that doesn't fit that well :) > > thanks a lot for this information Mariano. This is highly appreciated to > get infos from someone that knows the stuff. > > No problem. Just be careful 4: do not trust 100% of the ability to debug a post morten. It should be considered "just as another extra tool to the PharoDebug.log". But debugging a stack with Fuel could even be different than the scenario that caused the error. Imagine class variables that changed value, files/socktets or something that depended on external resources, etc etc etc. What I mean is...the debug of a materialized fuel stack may not be the same as debugging the error at the exact time it was produced in the very same image it happened. But it is a great addition to PharoDebug.log for several use cases where it helps anyway. Best, > Norbert > > Cheers, > > > >> thanks, >> >> Norbert >> >> >> >> On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <[email protected]>wrote: >> >>> >>> Am 26.02.2014 um 14:19 schrieb Max Leske <[email protected]>: >>> >>> > Cool! :) >>> > >>> > Just be careful: if you're using a large model the stack can blow up >>> your image with a low space warning / make it inresponsive (because the >>> stack referenes your model and boom, pretty much all of your instances will >>> becom serialized). >>> > >>> Yes, I know. But that would be a problem anyway. I think I have time. In >>> the fuel files are 8 (!) contexts. :) >>> >>> Norbert >>> >>> > FYI we're actively working on pruning of the serialization graph to >>> solve this. >>> > >>> > Max >>> > >>> > >>> > On 26.02.2014, at 14:01, Norbert Hartl <[email protected]> wrote: >>> > >>> >> The best smalltalk/pharo moments you get if you try things you want >>> to have just in order to see they are already there. >>> >> >>> >> Today FileBrowser. >>> >> I switched one of my servers to dump to stack with fuel to disk if an >>> exception occurs. Today I copied the files from the server to my local >>> machine and opened a workspace starting to write an expression to open >>> them. Then I thought it would be cool if I could use the file browser for >>> it. So I opened it and navigated to the directory with the fuel files...et >>> voilà...as soon as I clicked on a fuel file a button "materialize" appeared >>> which showed the stack from the server right away. >>> >> >>> >> Just brilliant! Well done! >>> >> >>> >> Norbert >>> > >>> > >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com
