Возможные причины для тайм-аута при попытке получить доступ к экземпляру EC2
Вы можете настроить источник данных на любом сервере приложений, на котором развертывается WAR, и получить ссылку на него с помощью JNDI. Или вы можете упаковать свою WAR в EAR и определить источник данных в файле data-sources.xml EAR (и получить ссылку на него с помощью JNDI).
3 ответа
Установили ли вы соответствующую группу безопасности для экземпляра? То есть такую, которая разрешает доступ из вашей сети к порту 22 на экземпляре. (По умолчанию весь трафик запрещен.)
Обновление: Хорошо, проблема не в группе безопасности. Но сохраняется ли проблема, если запустить другой экземпляр из того же AMI и попытаться получить доступ к нему? Может быть, этот конкретный экземпляр EC2 просто случайно вышел из строя - это лишь вопрос времени, когда произойдет что-то подобное. (Рекомендуемая литература: Архитектура для облака: Best Practices (PDF), статья Джинеша Вариа, который является евангелистом веб-сервисов в Amazon. Особенно обратите внимание на раздел под названием "Проектируйте с расчетом на неудачу, и ничто не потерпит неудачу")
.Если Вы только что создали новый экземпляр и не можете соединиться с ним, я смог решить проблему путем завершения что один и создание нового. Конечно, это будет только работать, если это будет новый экземпляр, и Вы больше не делали работы над ним.
Вы просматривали вывод консоли из экземпляра? Это можно сделать через консоль AWS (Экземпляры -> Щелкните правой кнопкой мыши экземпляр -> Получить системный журнал). У меня были случаи, когда сетевые службы на экземпляре EC2 не запускались правильно, что приводило к превышению времени ожидания соединений SSH; перезапуск экземпляра обычно исправлял ситуацию.