Опечатался, имел ввиду JMS. Просто когда будут появляться новые требования, то, скорее всего с jms будет жить проще. Например, делать повторные попытки доставить сообщения, если получатель недоступен (упал/перезагружается).
Просто если решать задачу через mysqlproxy не будет ли проблем с надёжностью/корректностью данных? Если архивный сервер будет недоступен, то будет ли работать запись в основной сервер? И если будет, то как будет решаться задача корректности данных в архивном? Более правильный путь imho это репликация. Может быть даже с настройкой прав (запрет на удаление таблицы например), но в этом случае репликация будет останавливаться с ошибкой (и нужно будет вручную её перезапускать с sql_slave_skip_counter). Как иначе сделать частичную репликацию я не знаю. Надо гуглить.
А с какой целью вы хотите это сделать? Иметь второй сервер как backup сервер? Если так, то может лучше делать резервные копии с бинлогом? Насколько критично вам потерять данные если кто-то сделает update table set x = 1 where 1=1 или truncate table?
Вероятно сертификат vk самоподписанный или подписан центром сертификат которого java не знает. Варианты могут быть разные, импортировать сертификат в java, сделать свой keystore с сертификатом vk, отключить проверку сертификатов.
А если погуглить хеш коды? Может у кого-то есть подобная проблема с руткитом или же найдётся репозиторий откуда взяты были файлы (если вдруг они сами собой обновились).
1) Просто 1-й запуск связан с загрузкой классов, а также с инициализацией FJP, как написали ниже. Второй и последующие запуски будут быстрее. А после JIT компиляции ещё быстрее. Если вам нужен только 1 запуск задачи для не очень большого ряда, то лучше использовать рекурсивную функцию. Как пример, для небольших массивов сортировка пузырьком будет работать быстрее чем quicksort. Так и здесь. Попробуйте увеличить объём вычислений, так чтобы рекурсивная функция выполнялась несколько минут, и сравните результаты.
2) С Fork/Join тоже не обязательно делить задачу пока делится, имеет смысл делить на N подзадач (надо подобрать, N > С * количество ядер и пробовать с C = 5, 10....). Преимущество FJP по сравнению с ExecutorService это более оптимальное переиспользование потоков. Рекомендую также прислушаться к комментарию TheShade ниже и поменять порядок fork/compute/join.
If you specify ON DUPLICATE KEY UPDATE, and a row is inserted that would cause a duplicate value in a UNIQUE index or PRIMARY KEY, an UPDATE of the old row is performed.
переменную окружения вставить в rc-скрипт или в inetd скрипт, в зависимости от того, как запускаете. В крайнем случае можно сделать два шелл скрипта, вида:
У меня этот роутер, долго жил со стандартной прошивкой, время от времени обновляя её. Роутер иногда подвисает, возможно это проблема не роутера, а стабильности напряжения 220V. Недавно прошил dd-wrt, чтобы настроить vpn-сервер. По ощущениям с dd-wrt работать стал лучше, но всё равно иногда виснет (при копировании больших объёмов через wi-fi).
Поискал насчёт поддержки invoke dynamic, нашел информацию о том что поддержка появилась в groovy 2.0 beta: пруф.
По поводу такой разницы в производительности не могу ничего сказать, но я бы посоветовал перед запуском теста «прогреть код» — хотя бы 1 раз прогнать тест, но не замерять время, чтобы нивелировать задержки связанные с подгрузкой классов.
