Возможно, это уже не актуально, но в свое время у hsqldb были проблемы с inmemory базами — данные оставалось в памяти даже при закрытии/открытии Connection. Из-за этого перешел на inmemory h2.
Вот так мапятся сервлеты: context.addServlet(new ServletHolder(new HelloServlet(«Buongiorno Mondo»)),"/it/*");
Отдельные функции замапить стандартными средствами Jetty нельзя, для этого нужно что-то вроде JAX-RS или спринговых маппингов.
Как вариант, вы можете написать свой загрузчик, который будет через reflection пробегать по всем методам и регистрировать их через обертку в качестве сервлетов.
Поговорил со своими сетевиками, они особой причины создания несколько сокетов не видят. Если в сети проблема, то все сокеты тоже будут терять пакеты. Я думаю, не нужно оптимизировать без нужды, сделайте, как проще, и потестируйте.
Количество каналов должно равняться количеству связей между сервисами. Если сервис1 общается с двумя другими и сервис2 с тремя другими, то всего должно быть 5 каналов.
Так я не понимаю — если он будет работать с исходниками, то зачем их прятать?))
Скопировать в любом случае можно, да тупо на телефон экран снимать, например, а потом распознавать.
Если такое недоверие, так, может, и не нужно его нанимать?
Не понял — в приведенном вами примере прямо написано, что реквест кодируется ( would be redirected internally to
index.php?show=C%2B%2B instead of index.php?show=C++ )
Мне кажется, вы не совсем верно выбираете инструмент. Если нужно писать терабайтные логи, то реляционная база данных — не лучшее решение. Лучше использовать Cassandra либо HDFS. Если же логи не сильно большие, то подойдет одна таблица; шардинг, в этом случае, ложится на плечи DBA.
ExecutorFarey же использует рекурсию. Запускается 4 потока, в каждом запускается рекурсия. Тут как раз помогает CountDownLatch.
Задача разбилась ровно на 4 куска по определению ряда Фарея :) Там любые степени двойки подходят. 3 процессора — это усложнение, у меня конкретная машина.