Please see inline:
Tim Quinn wrote:
> Hi, Ashish.
>
> Ashish Sahni wrote:
>> Hi Tim,
>> I'm glad you bring serialization up. Please see my comment inline:
>>
>> Tim Quinn wrote:
>>> Hi, Jan.
>>>
>>> Really great detective work on this. I probably should have
>>> followed this more closely given that the serialization logic I
>>> added was involved.
>>>
>>> In your research into this, did you see any place that the
>>> serialization code could have protected better against something
>>> like this?
>>>
>>> Because the serialization (and deserialization) of descriptors was a
>>> performance-only enhancement, I wrote the SerializedDescriptorHelper
>>> class to catch all Throwables that emerge from the attempt to
>>> serialize. (Although without the serialized descriptor the next
>>> reload of the app would take longer, an exception during
>>> serialization would cause no functional problem.)
>> The exception thrown during redployment does render the webapp
>> unusable. So in that ir does cause the functional problem. Thoughts ?
> Did your original message include all of the stack trace information?
> Was there a second trace that looked identical (but might not have
> been) that you didn't include?
I'm pretty sure that's all there was. The bug has the entire server log
and a reproducible test case so you can try it out ...
Thanks
Ashish
>
> Based on Jan's nice explanation, there might have been a second error
> very similar to the first one. If the attempt to serialize the app's
> descriptor fails the logic tries to write an Exception object to the
> serialized file for that app instead. (This is a performance
> optimization.) This second attempt to serialize might have
> encountered the same sort of problem but is not protected by a
> try/catch block. This could have allowed the JRuby error to cause the
> deployment to fail, but the information in the original note didn't
> suggest that.
>
> - Tim