Apache Nutch İncelemesi: Çalışıp Çalışmayacağını ve Neleri Bulacağını Belirleyen Dört Sınır

Apache Nutch, geliştirilmesine 2004 yılında başlanan bir Apache Software Foundation tarayıcısıdır. Hadoop üzerinde çalışan bir JVM sistemidir ve tek parça bir akış komutu gibi değil, döngüsel bir yapı içinde çalışır: başlangıç URL’leri kalıcı bir veritabanına inject edilir, ardından generate → fetch → parse → updatedb turları gelir; protokol, ayrıştırıcı, URL filtresi ve puanlama için eklenti yuvaları bulunur. Çıktı genellikle CSV yerine Solr veya Elasticsearch gibi bir arama indeksine aktarılır.

Test edilen Nutch 1.22 sürümünü, sunucu tarafında gelen her isteği kaydeden kontrollü bir yerel test sitesine karşı çalıştırdım; böylece sonuçları tarayıcının iddiasına göre değil, sunucunun gerçekten gördüklerine göre değerlendirdim. Koşuyu dört sınır şekillendirdi: JDK sürümü, http.agent.name, tarama kapsamı ve plugin.includes içinde parse-js olup olmaması. Test edilen yapılandırmayla tam döngü tekrar tekrar çalıştı; JDK’yı değiştirin ya da agent kimliğini boş bırakın, faydalı sayfalara erişmeden duruyor.

JDK sınırı herhangi bir tarama başlamadan önce karşınıza çıkıyor. Nutch 1.22, varsayılan JDK olan 26.0.1 üzerinde burada başlamadı: ilk Hadoop işi, Java SecurityManager yolu kaldırıldığı için Subject.getSubject() içinde çöktü. Nutch, Hadoop 3.4.2 ile geliyor; düzeltme ise Nutch 1.22 yayınlandıktan yedi gün sonra Hadoop 3.4.3’e geldi. Ayrı olarak, parse-js, bir tarayıcı çalıştırmadan iki JavaScript dosyası literali kurtarma oranını 0/2’den 2/2’ye çıkardı.

Nutch ne için, ne için değil

Nutch bir scraper değildir. Yapılandırılmış alan çıkarma onun işi değildir: URL’leri büyük ölçekte keşfeder ve indirir, bu URL’lerin ve durumlarının (crawldb) kalıcı bir veritabanını tutar ve sana başka bir aracın indekse dönüştüreceği segmentler bırakır. Bir katalogu isim ve fiyat tablosu bekleyerek ona yöneltirsen, eline tablo yerine crawldb geçer.

Bu mimari, bundan sonra anlatılacakların çoğunu açıklar. Nutch, tek ikili dosyalı tarayıcı döneminden yaklaşık yirmi yıl önce doğdu ve Hadoop’un çözmek için üretildiği probleme göre tasarlandı: tek bir makineye sığandan daha fazla sayfa taramak. 12 sayfalık bir test seti üzerinde dizüstü bilgisayarda çalıştırmak, bir kitaplık taşımak için yük treni kiralamaya benzer — tren hakkında bilgi verir, ama bisiklet ergonomisi beklemek haksızlık olur.

Mevcut sürüm 1.22’dir ve 17 Şubat 2026’da duyurulmuştur. Apache-2.0 lisanslıdır; 27 Temmuz 2026’da kontrol ettiğimde depo 3.272 yıldız ve 8 açık sorun gösteriyordu, ayrıca master dalına o tarihten dört gün önce push yapılmıştı. Bu proje terk edilmiş değil, aktif olarak sürdürülen bir projedir — JDK problemine bakarken de doğru çerçeve budur: ihmalkârlık değil, bir hafta erken kapanmış bir paketleme penceresi.

Sürüm matrisi: JDK 24+, Hadoop 3.4.2 ve iki satırlık düzeltme

Engel, üçlü bir sürüm etkileşiminden kaynaklanıyor; bunun içinde kontrol edebildiğin tek şey Nutch’un hangi JDK ile çalıştığıdır. Varsayılan JDK üzerinde ilk Hadoop işi başlatma sırasında öldü:

java.lang.UnsupportedOperationException: getSubject is not supported
    at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
    at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:588)
    at org.apache.nutch.crawl.Injector.inject(Injector.java:473)

Dönüş kodu 255. Hiç sayfa alınmadı. bin/nutch inject, ağ katmanına bile ulaşmıyor — önce bir Hadoop LocalJobRunner başlatıyor; bu, geçerli kullanıcıyı soruyor, o da Subject.getSubject() çağırıyor; JEP 486 ise SecurityManager yolu JDK 24 ile kalıcı olarak kaldırıldığında bunu koşulsuz bir istisnaya dönüştürdü. Kullandığım host JDK’si OpenJDK 26.0.1 idi; yani bu çizginin çok ötesinde.

Geleneksel kaçış yolu da işe yaramıyor. Eskiden eski davranışı geri açan -Djava.security.manager=allow bayrağı, Nutch’un kodu yüklenmeden önce VM tarafından reddediliyor:

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security
Manager. Enabling a Security Manager is not supported.

Bu dönüş kodu 1’dir ve bilerek çıkmaz sokak olarak tasarlanmıştır — bayrak, özellikle kaldırılan özellikle birlikte silinmiştir.

Kök neden, Nutch 1.22 ile paketlenen Hadoop sürümündedir. getSubject sorunu HADOOP-19212 olarak takip ediliyor ve Hadoop 3.4.3 ile 3.5.0’da düzeltilmiş durumda; Nutch 1.22 ise hadoop-common-3.4.2 ile geliyor. Nutch 1.22, 17 Şubat 2026’da yayımlandı ve Hadoop 3.4.3 yaklaşık bir hafta sonra geldi.

Bu bir Solr ya da Hadoop cluster bağımlılığı sorunu da değil. Sık duyulan varsayım, Nutch’un bir şey yapabilmesi için Hadoop cluster’ı ve çalışan bir Solr gerektiği yönündedir. Gerekmiyor. Local mode, Hadoop’un süreç içi LocalJobRunner’ını çalıştırır — HDFS daemon yok, YARN yok, cluster yok. Tüm inject → generate → fetch → parse → updatedb döngüsü tek bir makinede, başka hiçbir şey kurulu olmadan çalışır. JDK duvarı tamamen paketlenmiş kütüphane sürümüyle ilgilidir ve altyapı sorusuna gelmeden sizi durdurur.

Pratik sürüm matrisi, üç satırı da ölçülmüş halde:

Çözüm iki komuttur. Bir LTS JDK kurun ve Nutch’u ona yönlendirin:

brew install openjdk@17
export NUTCH_JAVA_HOME=/opt/homebrew/opt/openjdk@17

Keg-only olduğu için sistem varsayılanını değiştirmez. Nutch’un kendi CI süreci Java 17’yi hedefliyor ve proje açıkça duyurdu ki 1.22, Java 11 üzerinde çalışan son sürüm olacak ve 1.23 Java 17 gerektirecek. Yani LTS JDK bir geçici çözüm değil, desteklenen yapılandırmadır. Uyuşmazlık, Nutch’un desteklediği şey ile brew install openjdk’nin 2026’da sana verdiği şey arasında; ve bunlar ilk komutta çakışan iki ayrı konudur.

Bundan sonrası OpenJDK 17.0.20 üzerinde çalıştı ve tüm döngü sorunsuzdu.

Kurulum, ölçülmüş halde: 396 MB ve her şeyi kilitleyen tek özellik

“Hantal” sıfatı herkesin kullandığı bir kelimedir ama terazi olmadan pek bir anlamı yoktur. Nutch 1.22 ikili dağıtımının açılmış halindeki gerçek içerik şudur:

Ölçek için: katana gibi modern bir Go tarayıcı tek bir ~50 MB’lık binary olarak gelir; JVM ve dış jar’lar yoktur.

Sonra kimsenin seni uyarmadığı o kapı var. Paketle gelen nutch-site.xml boştur ve http.agent.name varsayılan olarak boş dizedir. Bu alanı doldurmadan yaptığım ilk tarama sıfır yol aldı ve şu hatayı kaydetti:

ERROR Fetcher: No agents listed in 'http.agent.name' property.

Sadece bu tek özelliği ayarlamak — başka hiçbir şey değil — taramayı çalışır hale getirdi. Özellik boşken komut sayfa çekmeden tamamlandı ve günlükte yukarıdaki agent adı hatası vardı; sessizce başarısız olmadı.

Çalışır asgari yapılandırma üç unsurdan oluştu: conf/nutch-site.xml (agent adı, eklenti kümesi, kapsam), conf/regex-urlfilter.txt (host kapsamı) ve bir seed URL dosyası. Bu kötü bir sayı değil. Sadece crawler run <url> komutundan üç dosya fazla.

Neleri buldu: önemli olan eklenti anahtarı

Test sitesinde kasıtlı olarak farklı üç uç nokta sınıfı vardı ve Nutch’un davranışı bunlar arasında net şekilde ayrıldı:

• Sınıf A — sıradan HTML bağlantıları (4 sayfa, artı 3 bağlantı derinliğinde bir zincir)
• Sınıf B — yalnızca bağlı bir JavaScript dosyasındaki string literaller içinde var olan uç noktalar: biri çağrı argümanı olarak, fetch('/api/js-endpoint-7'), diğeri atama olarak, const other = "/api/js-endpoint-8"
• Sınıf C — yalnızca JavaScript çalıştıktan sonra DOM’a enjekte edilen bir uç nokta

Sunucu tarafı istek günlüklerinden alınan sonuçlar, üç kez tekrarlandığında şu şekildeydi:

Üç tekrarın hepsinde birebir aynı. Deterministik.

Sınıf B’deki sıçrama, genellikle hafife alınan kısım. Nutch, JavaScript içine gömülü iki uç noktayı bir tarayıcı çalıştırmadan, parse-js eklentisinin JavaScript içeriğinde regex tabanlı taramasıyla buldu. app.js dosyasının kendisi iki yapılandırmada da indirildi — Nutch <script src> öğesini, içeriğine bakmaksızın bir outlink olarak ele alır — bu yüzden tüm fark, dosyanın içeriğini URL benzeri dizeleri aramak için bir şeyin okuyup okumamasıdır. Eklentiyi açınca her iki literal biçimini de yakalıyor.

Bu test setinde Nutch’un varsayılan modu ve katana’nın standart modu aynı Sınıf A kümesine ulaştı; Nutch parse-js ile ve katana -jc ile ise tarayıcı olmadan A ve B sınıflarını yakaladı. Katana sürümü ve tam komut bu makalede verilmediği için bu sonuç bağlam bilgisi niteliğindedir, katı bir ürün karşılaştırması değildir.

Sınıf C ise dürüst tavanın adı. Hiçbir statik eklenti yapılandırması oraya ulaşmadı; bu beklenen bir şeydir: yalnızca script çalıştıktan sonra var olan bir uç noktayı kurtarmak için script’in gerçekten çalıştırılması gerekir. Nutch’un saf Java ile JavaScript çalıştıran protokolü protocol-htmlunit ile değiştirmeyi de denedim. Yüklendi ve çökmeden çalıştı, ancak aynı dört turlu düzende yalnızca bir tur tamamladı, sadece seed sayfasını ve app.js’yi aldı, A/B/C’nin hiçbirine ulaşamadı ve ikinci turda 0 records selected for fetching yazdı. Bu, HtmlUnit’in kapasitesine dair bir hüküm değil, yetersiz yapılandırılmış bir denemedir. Ortaya koyduğu daha dar sonuç şudur: JavaScript çalıştıran bir protokole geçmek tak-çalıştır bir değişim değildir ve test ettiğim hiçbir yapılandırmada Sınıf C’ye ulaşılamadı.

Tarama kontrolü ve hata davranışı

Derinlik bir bayrak değildir. Nutch’ta --depth 3 diye bir şey yoktur; derinlik, çalıştırdığınız generate → fetch → parse → updatedb tur sayısıdır; çünkü R turu, R-1 turunda keşfedilen sınırı çeker. Derinlik zincirim bunu net biçimde doğruladı:

Temiz ve mekanik, ama derinliğin bir parametre değil, betiğindeki bir döngü sayısı olduğu anlamına geliyor.

Şimdi tuzak. Nutch’un paketle gelen varsayılan ayarı db.ignore.external.links=false ve buna eşlik eden izin verici +. URL filtresidir — yani varsayılan bir Nutch taraması seed host’unun dışındaki bağlantıları da takip eder. Bir sayfaya, kapsam içindeki bir yol ile farklı bir host’a giden bağlantıyı seed olarak verdim ve tarama yabancı host’u da çekti. Birbirinden bağımsız iki sinyal aynı şeyi doğruladı: Nutch’un kendi crawldb’si bunu db_fetched olarak işaretledi ve diğer host’un sunucu sayacı isteği kaydetti.

Kapsam içinde kalmak isteğe bağlıdır ve iki çözüm de doğrulanabilir biçimde işe yarar:

Tek bir siteyi tarıyorsan, ilk gerçek koşudan önce bunlardan birini ayarla. Bir metodoloji notu: bu test, yerel sunucudaki yüke duyarlıdır; bu nedenle bu üç satır, test setine başka hiçbir şey dokunmazken yapılan bir koşudan geliyor. Davranış mekanik olarak nettir ve iki bağımsız sinyalle desteklenmektedir; belirtilen satır değerleri çok sayıda koşunun ortalaması değil, tek temiz bir koşunun sonucudur.

Site haritaları ayrı bir adımdır. Nezaket ayarı açıktır — normal bir tarama /robots.txt dosyasını aldı — ancak site haritası için ayrı bir komut gerekir:

Bilinen dosyaları satır içinde çeken tarayıcılardan farklı bir modeldir ve sana ek bir komut maliyeti çıkarır, ama işi eksiksiz yapar.

Daha küçük iki davranış da iyi sonuç verdi.

Hata yönetimi: 500 ve 404 bağlantısı olan bir sayfa üzerinden yapılan tarama, tüm turları sorunsuz tamamladı, yine de dört Sınıf A sayfasının hepsini çekti ve her hatayı ayrı ayrı kaydetti:

Hiçbir şey raydan çıkmadı.

Nezaket: kuyruk başına bir iş parçacığı ile, aynı host’taki çekimler arasındaki boşluk ayarla uyumlu ilerledi:

Kayıt tam da dediğini yapıyor. Paketle gelen varsayılan 5.0 saniyedir; bu muhafazakâr bir değerdir ve yine, yabancı sunucuları taramak için tasarlanmış bir araç için muhtemelen doğrudur.

Sekme vergisi, saniye cinsinden

Nutch’taki her komut yeni bir JVM başlatır. Tek bir gerçek bu zaman profilini, çekimden daha fazla belirler.

Gerçekçi iş başlatma tabanı — JVM başlangıcı artı Hadoop başlatması; en ucuz, önemsiz iş aşaması olarak ölçüldü — yaklaşık 1.77 saniye. Bunu tur başına dört komutla çarpın, başlangıçtaki inject’i ekleyin; tam tarama resmi şu hale geliyor:

Bu fark çekim hızından kaynaklanmıyor; iki araç da aynı birkaç sayfayı istiyor. Bu bir mimari fark. Nutch, her aşama için sabit bir süreç maliyeti ödüyor çünkü bu aşamalar MapReduce işleri olarak tasarlanmış. Küçük bir yerel taramada kurulum baskın olur. Sabit maliyet daha uzun bir işte daha küçük bir paya dönüşmelidir, ama bu test Nutch ile katana’nın hangi ölçekte başa baş geldiğini ya da oranlarının tersine dönüp dönmediğini ölçmedi.

Artılar ve eksiler

Artılar

• Deterministik statik keşif: 4/4 HTML sınıfı, 3/3 derinlik zinciri, üç tekrarlı koşuda da aynı sonuç.
• parse-js, JavaScript dosyası literali uç noktalarını (2/2) tarayıcı olmadan kurtarır; hem çağrı argümanı hem atama biçimini yakalar.
• Bir taramayı tamamen kapsayan doğrulanmış iki kapsam kontrolü (db.ignore.external.links ve host regex-urlfilter).
• bin/nutch sitemap ile site haritası içe aktarma, normal taramanın tamamen kaçırdığı uç noktalar için tam 2/2 geri çağırım sağladı.
• Hatalara karşı dayanıklı: 500 ve 404 ayrı crawldb durumlarıyla işlendi, tarama devam etti.
• Bu yerel koşuda gözlenen aynı host aralığı, ayarlanmış 1.0 saniyelik gecikmeyle uyumluydu; paketle gelen varsayılan 5.0 saniyedir.
• Apache-2.0, aktif olarak bakımı yapılıyor, 78 eklenti ve turdan tura URL durumunu izleyen kalıcı bir crawldb var.
• Cluster, HDFS ve Solr gerektirmeden local mode’da çalışır.

Eksiler

• JDK 24 ve üzeri üzerinde çalışmaz; SecurityManager kaldırıldığı için (başarısızlığı 26.0.1 üzerinde ölçtüm) paketlenmiş Hadoop 3.4.2 yukarı akış düzeltmesinden önce kalır ve kaçış bayrağı da kaldırılmıştır; dolayısıyla bir LTS JDK sabitlemek tercih değil, zorunlu ön koşuldur.
• Açılmış halde yaklaşık 396 MB, 188 kütüphane jar’ı, 78 eklenti dizini, 35 yapılandırma dosyası.
• Her komut için yeni JVM, her aşamada yaklaşık 1.77 s sabit yük; 12 sayfalık derinlik-4 tarama için ~45 s, aynı zeminde tek ikili bir tarayıcı için ~13 s.
• Paketle gelen varsayılan, bağlantıları dış host’lara da takip eder; tek sitede kalmak isteğe bağlıdır.
• http.agent.name boş gelir ve sen ayarlayana kadar fetcher çalışmayı reddeder.
• Derinlik bayrağı yok — derinlik, senin yönettiğin bir döngü sayısıdır.
• Çalışma zamanı DOM uç noktaları test edilen her yapılandırmada ulaşılamadı ve JS çalıştıran protokolü tak-çalıştır şekilde değiştirmek mümkün olmadı.
• Yerel modda, tek host üzerinde küçük bir test setiyle çalıştım. Dağıtık/HDFS modu, Solr indeksleme, hostdb, resume ve artımlı yeniden tarama zamanlaması bu denemenin dışında kaldı — burada test edilmemiştir, onaylanmış sayılmamalıdır.

Kim kullanmalı, kim uzak durmalı

Nutch, taramanın kendisi zor olduğunda değerini gösterir. Eğer bir arama indeksi oluşturuyorsan, geniş çok alanlı bir tarama yapıyorsan, URL başına durum ve yeniden deneme semantiği olan kalıcı bir URL veritabanına ihtiyaç duyuyorsan veya işi zamanla makineler arasında dağıtmayı planlıyorsan, bu, çoğu alternatif ortaya çıkmadan önce de bu spesifik işi yapan altyapıdır. Eklenti sistemi, protokol, ayrıştırıcı, filtre ve puanlama davranışını hiçbir şeyi çatallamadan değiştirmenize izin verir. Nezaket varsayılanları, bakımcıların iyi bir internet vatandaşı olmayı ciddiye aldığını düşündürecek kadar temkinlidir.

Birkaç sayfadan yapılandırılmış veri çıkarmak istiyorsan uzak dur. Nutch onları çeker ve ayrıştırır, ardından sana bir crawldb ve segmentler verir; senden bir indeksleyici getirmeni bekler. Hedeflerin istemci tarafında render edilen tek sayfalık uygulamalarsa uzak dur — test ettiğim her şeyde Sınıf C’ye ulaşılamadı. Ekibin JVM çalıştırmıyorsa da uzak dur; çünkü Java araç zinciri, LTS JDK sabitlemesi ve 396 MB jar eklemiş olursun. İş yükü “bir siteyi, dört seviye derinliğinde, haftada bir tarayın” ise, döngü ve yapılandırma dosyalarına taramanın hak ettiğinden daha fazla zaman harcarsın.

Scraper arayan çoğu kişi için, son örnek aslında gerçek durumdur. Bu Nutch’a eleştiri değil — araç ile işin uyuşmaması. Daha geniş alanı görmek istersen, açık kaynak scraper’lar derlememiz ve en iyi web scraping GitHub projeleri daha hafif uçları daha ayrıntılı kapsıyor.

Alternatifler ve kendi yığınının nerede durduğu

Önce adil çerçeve: Nutch ücretsizdir, Apache lisanslıdır, kendi sunucunda çalışır ve her zaman, istek başına maliyet olmadan senindir. Bu gerçek bir avantajdır ve aşağıdakilerin hiçbiri bunu ortadan kaldırmaz.

İlgili inceleme: Browsertrix Crawler incelemesi.

Açık kaynak dünyasında karşılaştırma, neyi optimize ettiğine bağlıdır. Tarama kontrolü ve istek-öncelikli bir felsefe ile Python tabanlı bir çerçeve istiyorsan, Scrapy birçok proje için daha yakın bir analojidir; bu makale onun kurulum boyutunu aynı ölçekte ölçmedi. Tarayıcı olmadan kompakt bir Go tarayıcı istiyorsan, Colly değerlendirebileceğin başka bir şekildir. Sorunun URL keşfetmekten çok sayfaları LLM’ye hazır içeriğe dönüştürmekse, Crawl4AI farklı bir katmanı hedefler.

Thunderbit gibi yönetilen bir hizmet, çekme, render etme ve çıkarma işlemlerini bir API arkasına taşır; Nutch ise tarama durumunu ve altyapıyı senin kontrolünde tutar. Thunderbit bu test setinde çalıştırılmadı; bu nedenle bu, eşleşen geri çağırım ya da dinamik sayfa performansı hakkında bir iddia değil, sahiplik modeli karşılaştırmasıdır.

Takas, sahiplik ile ek yük arasındadır ve pek de ince değildir. Nutch sana tam kontrol, kalıcı crawldb, tasarım gereği cluster ölçeklenebilirliği ve sıfır marjinal maliyet verir — karşılığında bir JVM, LTS JDK sabitlemesi, 396 MB jar, bir tur döngüsü ve kendi indeksleme katmanını ister. Yönetilen bir API ise ilk çağrıda yapılandırılmış çıktı ve altyapısız kullanım sağlar — karşılığında çağrı başı fiyatlandırma ve tarama sınırı üzerinde daha az kontrol verir. İşin “50 milyon sayfayı indekslemek” ise Nutch’un modeli doğrudur ve bir API saçma olur. İşin “Perşembe’ye kadar 200 ürün sayfasından yapılandırılmış kayıt çıkarmak” ise tersi geçerlidir.

Web Veri Çıkarma için Thunderbit’i Dene

Karar

Apache Nutch, devam eden çok alanlı bir tarama yürütüyorsan ve zaten JVM altyapısı işletiyorsan değerlendirmeye değerdir. Bu test setinde statik keşfi tekrarlar boyunca deterministikti, parse-js her iki literalli JavaScript uç noktasını buldu, hatalar crawldb’de temsil edilmeye devam etti ve gözlenen istek aralığı yapılandırılan gecikmeyle uyumluydu.

Giriş maliyetini dürüstçe ölç. Nutch 1.22 burada JDK 26.0.1 üzerinde başarısız oldu; bu incelemede gerçekten doğrulanan LTS yapılandırması OpenJDK 17.0.20’dir, Java 21 ise test edilmedi. Ardından http.agent.name’i ayarlayın, kapsamınızı açıkça belirleyin ve bu küçük yerel koşuda gözlenen aşama başına yaklaşık 1.77 saniyelik sabit tabanı hesaba katın. Bu takasın mantıklı olup olmadığı, taramanın süresine, genişliğine ve kalıcı duruma duyulan ihtiyaca bağlıdır.

Web Veri Çıkarma için Thunderbit’i Dene Get Started Free

SSS

Apache Nutch neden "getSubject is not supported" hatası veriyor? JDK 24 ve sonrasında JEP 486, Subject.getSubject() çağrısının koşulsuz olarak istisna fırlatmasına neden oldu; paketle gelen Hadoop 3.4.2 ise hâlâ bu çağrıyı yapıyordu. Bu yüzden ilk Hadoop işi herhangi bir sayfa alınmadan çöküyor ve eski -Djava.security.manager=allow kaçış yolu da VM’i artık başlatmıyor. Doğrulanmış Java 17 yapılandırmasını kullan ve NUTCH_JAVA_HOME ayarla; Java 21 destekleniyor olabilir, ancak bu inceleme tam döngüyü onun üzerinde çalıştırmadı.

Nutch 1.22’yi hangi Java sürümünde çalıştırmalıyım? En güvenli cevap Java 17’dir — Nutch’un kendi CI süreci bunu hedefler ve benim testimde OpenJDK 17.0.20 üzerinde sorunsuz çalıştı. Java 11 de 1.22 için desteklenmeye devam eder; ancak proje 1.23’ün Java 17 gerektireceğini duyurdu. JDK 24 ve üzeri hiçbir şekilde çalışmaz. Keg-only Homebrew kurulumu (brew install openjdk@17) ve NUTCH_JAVA_HOME, sistem varsayılan JDK’nı değiştirmeden kullanmanı sağlar.

Nutch JavaScript ağırlıklı siteleri tarayabilir mi? Kısmen, ve fark önemlidir. parse-js eklentisi etkinleştirildiğinde, Nutch yalnızca bağlı bir JavaScript dosyası içindeki string literali olarak var olan iki uç noktayı buldu — 2/2, tarayıcı olmadan. Varsayılan eklenti kümesiyle ikisini de bulamadı. Ancak JavaScript çalışıp DOM’u değiştirdikten sonra ortaya çıkan bir uç nokta, test ettiğim tüm statik yapılandırmalarda ulaşılamaz kaldı ve HtmlUnit protokolünü takmak benim koşumda tak-çalıştır bir değişim olmadı. İstemci tarafında render edilen uygulamalar için JS çalıştıran bir protokol + gerçek yapılandırma çalışması ya da başka bir araç planla.

Nutch’un Hadoop ve Solr kurulu olmasına ihtiyacı var mı? Hayır. Local mode, Hadoop’un süreç içi LocalJobRunner’ını çalıştırır — cluster yok, HDFS daemon yok, YARN yok — ve tüm inject → generate → fetch → parse → updatedb döngüsü tek makinede, başka bir şey kurulu olmadan çalışır. Solr genellikle indeksleme hedefidir, fakat taramanın kendisi onu gerektirmez. Bununla birlikte, Hadoop jar’ları paket içine dahildir (13 adet, 3.4.2 sürümü); JDK uyumluluk sorununun var olma nedeni de tam olarak budur.

Nutch’un başka web sitelerini taramasını nasıl engellerim? Bunu açıkça ayarla, çünkü paketle gelen varsayılan bunu yapmıyor. Nutch 1.22, db.ignore.external.links=false ve izin verici bir URL filtresiyle geliyor; testimde varsayılan tarama farklı bir host’a giden bağlantıyı takip edip onu da aldı. Ya nutch-site.xml içinde db.ignore.external.links=true ayarla ya da conf/regex-urlfilter.txt içine bir host kuralı ekle (örneğin +^https://example\.com/ ardından -.). Her iki yöntem de taramayı tamamen sınırlandırdı; bu, hem Nutch’un kendi crawldb’siyle hem de diğer sunucunun istek kaydıyla doğrulandı.