SystemStackError локализован, но приводит к остановке производственного сервера

Question

Я работаю над проектом Ruby, где мне нужно преобразовать необработанный XML-документ с помощью таблицы стилей xsl от моего пользователя.

Недавно я понял, что некоторые стили моего пользователя имеют бесконечные циклы, из-за которых мое приложение разбилось, поэтому я добавил некоторые ошибки для предотвращения такого события.

rescue SystemStackError, NoMemoryError => e 
    puts "error caught #{e.inspect}" 

я смог успешно спасти эту ошибку, когда я бегала приложение локально, но когда я развернуть его к моему примеру AWS, используя ту же таблицу стилей, эта ошибка была поймана только для небольших файлов (например, , ~ 200 КБ xml).

С большим размером xmls (скажем, 4 МБ) приложение кажется застрявшим (он никогда не завершит текущую задачу и не перейдет к следующему).

Я думал, что у меня недостаточно памяти на моем экземпляре aws, но даже после его изменения с t2.micro на t2.large (у которого такой же объем памяти, что и у моей локальной машины) мое приложение все равно застряло бы без причина.

Я сравнил все драгоценные камни как на моей локальной машине, так и на моем экземпляре aws, и все они имеют одинаковые версии. Я использую Nokorigi (1.6.7).

Может кто-нибудь, пожалуйста, дайте мне несколько советов относительно того, где я должен выглядеть? Любая помощь будет оценена!

PS: Я должен отметить, что, от отчаяния, я даже добавил заявление как этот

rescue Exception => e 
    #log exception here 

в конце всей моей другой обработки ошибок коды, в надежде уловить проблемы ... но, увы, призрак остается анонимным и смертельным. :(

Answer 1

Я нашел причину этой проблемы и думал, что я хотел бы поделиться, что я узнал:

• даже когда я спасая SystemStackError, сборщик мусора не было очистки памяти и утечка памяти в конечном итоге привела к тому, что производственный экземпляр прекратил работать
• такая же утечка памяти происходила и локально, но из-за того, что у моей локальной машины было намного больше памяти, чем у нашего производственного экземпляра, потребовалось намного больше времени для сбоя (так это появился для правильной работы в начале локально)
• «Исправление» должно было использовать как драгоценности Нокигири, так и Ruby-xslt. Нокигири прекрасно обрабатывает большинство преобразований xsl, но когда это не удается, драгоценный камень Ruby-xslt, похоже, справляется со странными случаями в порядке. Таким образом, в моем коде я вначале пытался преобразовать с помощью Nokogiri, и если он терпит неудачу, то при преобразовании с xslt.

Надеюсь, это поможет. :)