apkotelnikov: Я вижу, что все запросы идут по портам, которые не используются приложениями. Может быть, может помочь настройка блока входящих соединений на уровне Firewall?
Ту же Groovy и Scala можно запустить и на Tomcat 8, для любителей bleeding edge :)
В Java 8 очень хочу писать с лямбдами и подобным, надоело на клавиатуре как на рояле строчить inner классы.
Переход на Spring 4 рассматриваем в ближайшие месяцы. У нас хорошое покрытие кода тестами, думаю особых проблем быть не должно.
@anyd3v то есть мне вопросы здесь лучше не задавать и гулять до гугла, вы это сказать хотите? Знаете, все вопросы хороши, даже простые. Посмотрите на stackoverflow, где 100 топиков про конкатенацию строк. Тем не менее, теперь гугл уже в первой строке результатов именно туда и оправляет народ, который ищет.
@anyd3v тестовый сервер это 2-4 часа тестов, если по-нормальному, а вопрос в сообществе - 5 минут. Если народ знает о чем-то большом и незакрытом оно сразу всплывет здесь.
Все зависит от изначального опыта к моменту выхода на одеск. Если у вас уже есть пятилетний опыт работы - индусы совсем не конкуренты.
Работа с трекингом - не такая уж и боль, как вы представили. Вполне нормально, просто не надо предполагать, что ты в офисе сидишь. Ты высококвалифицированный консультант, с большим рейтом за час. В день на заказчиков работаете 4 часа.
Все это говорю исходя из своего опыта: http://habrahabr.ru/post/186700/
Скорее, будь я публичным человеком, меня бы интересовала идея автопредложения шаблонного ответа по содержимому письма (т.е. плагин для браузера, к примеру).
Или сервис ответа от моего имени наподобие описанного в вопросе, в который я сам могу форвардить почту, на которую надо ответить по вашим хитрым правилам.
PS. Кстати, для отправки ответа на письмо доступ к ящику вообще не нужен. Доступ к ящику нужен только для правильной подписи письма почтовым сервером, что в данном случае не нужно.
1. У ActiveMQ поддержка XA реализована в полной мере, а про MySQL 5.x слышал в интернетах, что XA в MySQL сломан… Поэтому и вопрос, для уточнения.
2. Подход, предложенный вами можно использовать для систем, где целостность данных не критична. В первую очередь я бы ожидал проблем, когда попрет очень сильная нагрузка, а сервер еще пару раз ляжет под ней…
«абсолютно надежных транзакций не существует» — откуда такие данные? Можно логическое обоснование или ссылки?
3. Работал с со связкой IBM Webshere MQ и Oracle несколько лет, используя XA. Все работает, на проде полет нормальный.
4. Для «обхода» проблемы XA одного из ресурсов, люди используют Last Resource Commit.
Возможны также проблемы с целостностью данных, но вероятность траблов меньше, чем если вязать полностью не-XA транзакции.
Это интересный вопрос, который я задаю себе до сих пор.
Вначале про подход. Надо понимать, что писать тесты это непросто, и с первого раза не получится даже на тройку. Быть готовым к тому, что мало что будет получаться хорошо протестить сначала, из-за недостатка опыта. В голове держать мысль «а как я покрыл эту часть тестами? где она слаба?». Это будет мотивировать что-то делать постоянно, и стесняться выкатывать не покрытый автотестами код.
Я иду к тестам уже два года и к TDD все еще не пришел по уровню понимания. Тем не менее, я делаю гораздо более серьезный код, чем раньше и качество растет не просто в моем самомнении, а я вижу, что багов выплывает меньше, код разделен четче, нового человека в проект запускать проще и т.п.
Еще про время — написание и поддержка тестов добавляет около 60% к времени разработки. Но при этом снимает головняки с команды поддержки наполовину, а с команды тестирования на 80%. Вот и считайте командные трудозатраты. С тестами дешевле. Если их правильно писать.
Как начинать тестировать? Ну вот вам пример частей, которые подлежат тестированию в первую очередь:
1. Утилиты манипуляции строками, датами, числами. Все, что у вас в проекте называется *Utils.java обычно. Есть метод манипуляции — на вход ему даем данные, ждем на выходе результат (assertEquals и подобное из JUnit).
2. Парсеры. Надо разобрать HTML и забрать из него данные — это можно хорошо потестить. Берем пример HTML, сохраняем в файл, начитываем в строку, кормим парсеру, ждем результат.
3. Слой БД. Уже сложнее, но тоже можно. Выделяем сущности через паттерн DTO (на примере блога: User, BlogPost, Comment). Выделяем интерфейс БД с ее операциями. Там будут методы типа findLastNComments(), findUserById(), addCommentToPost() и т.п.
Делаем так, чтобы Unit-тесты поднимали как-то реальную БД на время тестов. Пишем тесты про логику работы БД слоя. К примеру, слой БД всегда обновляет поле lastUpdated при сохранении сущности. Вот и напишите для этого тест — ожидаем обновления lastUpdated после сохранения. Еще пример: ожидаем, что после обновления имени пользователя его можно найти по новому имени, а по старому уже нельзя.
Сколько тестов готовить?
Несколько разнородных валидных примеров, несколько corner-case примеров (null, пустая строка и т.п.), несколько невалидных примеров. В каждом из них код под тестом должен давать верный результат. Это мы по сути документация контракта кода, через тесты.
Постепенно вы заметите, что архитектура ваших систем стала не такая горбатая и путаная как раньше. Все потому, что вы начали делать на слои, выделять отдельные компоненты, интерфейсы и т.п. И все из-за тестов — они мешают делать макаронный код.
Практика на PROD показала, что описанный вами баг появляется в полной мере.
Поддержка XA в MySQL 5.x сломана. Пришлось перейти на Last Resource Commit.
Попытался повторить ваш опыт с отваливающейся транзакцией:
В одной транзакции происходят:
1) чтение из БД,
2) запись в БД
Между 1 и 2 поставил Thread.sleep(10000) и дернул операцию дважды одновременно через два вызова веб-сервиса.
Это возможно, что в OS не хватило памяти в один прекрасный момент, и были убиты процессы пользователя… Где может отражать этот факт — что было убито, в какой момент и т.п.?
Воспользуюсь вашим советом, переведу велосипед на нормальное решение…
