Блог

У меня есть приложение rest, в котором класс RootConfiguration определен как:

 public class RootContextConfiguration implements AsyncConfigurer,
        SchedulingConfigurer
  

Класс RootContextConfiguation содержит несколько компонентов кода, таких как:

 @Bean
@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public MyCustomBean myCustomBean() {
    MyCustomBean myCustomBean = new MyCustomBean();
    return myCustomBean;
}
  

RootContextConfiguration зарегистрирован в моем классе FrameworkBootstrap, который определяется как:

 public class FrameworkBootstrap implements WebApplicationInitializer
  

Способ, которым я регистрирую RootConfiguration:

 @Override
    public void onStartup(ServletContext container) throws ServletException {

// AnnotationConfigWebApplicationContext extends the AbstractRefreshableWebApplicationContext abstract class
        AnnotationConfigWebApplicationContext rootContext = new AnnotationConfigWebApplicationContext();
        rootContext.register(RootContextConfiguration.class);
        container.addListener(new ContextLoaderListener(rootContext));
  

Теперь, если компонент, такой как MyCustomBean, выходит из строя, приложение не
будет аварийно завершать работу, но этот компонент не будет работать. Поскольку я использую это в своем сервисном компоненте, который вызывается моей конечной точкой rest, у меня есть сервисный компонент
с плохим компонентом.

Есть ли способ автоматического восстановления после сбоя компонента?

Я использую Spring 4.2.3.RELEASE.

В принципе, мне интересно, если компонент имеет область видимости в качестве прототипа, но каким-то образом он выходит из строя в ApplicationContext, могу ли я перезагрузить компонент, который выходит из строя автоматически? Другими словами, это был бы какой-либо метод, который я мог бы использовать для автоматической перезагрузки ApplicationContext в случае сбоя?

Я хотел бы иметь приложение self healing. Возможно ли это?

Заранее благодарю вас,

C.

Ваш вопрос не имеет смысла. Может быть, почитайте об исключениях. Мы, разработчики, не говорим о «сбое», просто генерируются исключения. JVM никогда не должна «вылетать». Экземпляры класса также не работают, они просто генерируют исключения. Весной исключение, если оно не перехвачено, может быть передано обратно на контроллер с @ControllerAdvice аннотацией сверху, и соответствующее исключение может быть помещено в один из его методов : @ExceptionHandler(YourException.class) public String yourMethod() . Если бы вы знали, что ваш класс выдал определенное исключение, вы могли бы перехватить его там, а затем делать все, что хотите, возвращать страницу с ошибкой в распознаватель представлений или создавать новый экземпляр и передавать его куда угодно.

 @ControllerAdvice
public class ErrorHandler {

    @ExceptionHandler(DataAccessException.class)
    public String showDatabaseErrorPage()
    {
        return "dataBaseErrorPage";
    }
}
  

В общем, если вы хотите сделать свое приложение надежным, не должно быть возможности иметь компоненты в состоянии «сбой», как вы говорите. Приложение должно показать вам, что не так, а не просто сбой.

Редактировать Я думаю, что для ответа на этот вопрос просто недостаточно информации, но я сделаю все возможное. Во-первых, ConcurrentHashMap должен быть доступен только одному потоку. Убедитесь, что это так, это может быть ваша ошибка. Может быть, именно эта библиотека, о которой вы говорите, имеет эту карту, и вы не предполагаете использовать эту библиотеку более чем в 1 потоке, и вы, я понятия не имею.

Теперь для перезапуска этого «компонента». Если ваше приложение не имеет состояния, за исключением любых сеансовых компонентов, то вы можете использовать HttpSession.invalidate() его в своем @ControllerAdvice контроллере, я полагаю (хотя я никогда не пробовал). Ваше приложение должно быть без состояния, за исключением сеансовых компонентов. Любое другое состояние должно храниться в базе данных, а не в самом веб-приложении. Если вы сделали это, единственное, что вам нужно сделать, это завершить сеанс, поскольку сеансовые компоненты могут быть единственным компонентом, который может стать «поврежденным», поскольку это единственный компонент, в котором находится состояние.

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

Воссоздание одноэлементных компонентов — неприятное занятие, вы бы просто добавили гадость поверх своей гадости, и вы бы ничего не выиграли. С таким же успехом вы можете просто перезапустить все приложение.