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?
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