Есть ресурс, с которого надо тащить данные 10-ки тысяч http-страниц.
Пэйджинацию ресурс выдает крайне медленно (5-10сек и более, бывает по ходу и отваливается по таймауту, но это побороли пока). Итого, чтобы скачать допустим 30тыс страниц надо примерно 3-е суток. Все бы ничего, но это только одно направление, а таких порядка пятидесяти, т.е. чтобы достать все направления потребуется около 3-х! месяцев ))
Напрашивается работа в несколько потоков.
При этом задача не нагружать сервер приложений (развернуто в виде сервлета на GF, может и спорно, но пока так) ну и соотв. саму машину, на которой вся эта ботва будет крутиться )

В этой связи вопросы:
1. Сейчас использую HttpURLConnection, имеет ли смысл пытаться как-то асинхронно доставать страницы и есть ли такая возможность? Т.е. запрашивать как-то так, чтобы по минимуму держать процессор машины? Понятно, что можно создать отдельный поток в нем запустить запрос и ждать ответ, но это как бы немного не то - все равно же созданный поток будет задействовать проц.
Имею в виду так: кинул запрос и отпустил проц покурить, периодически заставляя его заглядывать, проверять не пришел ли ответ :)

2. По следам соседней темы: Многопоточность внутри сервлетов. Помогите что использовать
Предполагается использовать FixedThreadPool, насколько это нормально, учитывая контекст топика про утечки в многопоточных библиетаках? И можно ли как-то просто найти утечки при отладке того же сервлета?

Alexey TominМожет это переделать?
Не надо использовать средство не по назначению. Краулер- это отдельное приложение.
Ну сервлет и рассматривается как отдельное приложение, на сервере приложений, роль которого выполняет гласфиш )
Подобного рода приложений довольно много - держать и рулить каждым отдельно?... Все равно очень неплохо бы держать все в одном месте, пул коннектов опять же уже готовый. Хотя мне самому не очень нравится, что приложение оформляется в виде сервлета, т.е. должно давать ответ, который некто якобы может ждать, хотя реально ответ никто не ждет.
Какие есть альтернативы? Или можно использовать тот же GF, но приложение оформлять не как сервлет? )
Petro123ради интереса сравни скорость с
К сож. даже пытаться не буду - на страницах практически нет графики, канал нормальный - долго формируется именно ответ от запрашиваемого сервера и вполне понятно почему - редко когда задумываются над производительностью, когда делают пэйджинацию нескольких миллионов записей, надеясь на то, что все равно никто не будет лазить по десяткам тысяч страниц )
(даже просто: когда запрашиваешь направление, где всего тысяча страниц - все летает)

Atum1Напишите им письмо - пусть дадут доступ к базе на чтение, или договоритесь за деньги...
Это не наш метод (с) )