क्लाइंट/सर्वर को लागू करना

Bazel सिस्टम को लंबे समय तक चलने वाली सर्वर प्रोसेस के तौर पर लागू किया जाता है. इससे कई तरह के ऑप्टिमाइज़ेशन किए जा सकते हैं. बैच-ओरिएंटेड तरीके से लागू करने पर, ये ऑप्टिमाइज़ेशन नहीं किए जा सकते. जैसे, BUILD फ़ाइलों, डिपेंडेंसी ग्राफ़, और एक बिल्ड से दूसरे बिल्ड तक के अन्य मेटाडेटा को कैश मेमोरी में सेव करना. इससे इंक्रीमेंटल बिल्ड की स्पीड बेहतर होती है. साथ ही, build और query जैसे अलग-अलग कमांड को लोड किए गए पैकेज का एक ही कैश मेमोरी शेयर करने की अनुमति मिलती है. इससे क्वेरी बहुत तेज़ी से होती हैं. हर सर्वर एक बार में ज़्यादा से ज़्यादा एक अनुरोध को हैंडल कर सकता है. एक साथ किए गए अन्य अनुरोधों को ब्लॉक कर दिया जाएगा या वे तुरंत फ़ेल हो जाएंगे (--block_for_lock देखें).

bazel को चलाने का मतलब है कि क्लाइंट को चलाया जा रहा है. क्लाइंट, सर्वर को आउटपुट बेस के आधार पर ढूंढता है. डिफ़ॉल्ट रूप से, इसे बेस वर्कस्पेस डायरेक्ट्री के पाथ और आपके उपयोगकर्ता आईडी से तय किया जाता है. इसलिए, अगर आपने एक से ज़्यादा वर्कस्पेस बनाए हैं, तो आपके पास एक से ज़्यादा आउटपुट बेस होंगे. इस वजह से, Bazel सर्वर की एक से ज़्यादा प्रोसेस होंगी. एक ही वर्कस्टेशन पर कई उपयोगकर्ता, एक ही वर्कस्पेस में एक साथ बिल्ड कर सकते हैं. ऐसा इसलिए, क्योंकि उनके आउटपुट बेस अलग-अलग होंगे (अलग-अलग उपयोगकर्ता आईडी).

अगर क्लाइंट को कोई चालू सर्वर इंस्टेंस नहीं मिलता है, तो वह एक नया इंस्टेंस शुरू करता है. यह इस बात की जांच करके ऐसा करता है कि आउटपुट बेस पहले से मौजूद है या नहीं. इसका मतलब है कि ब्लेज़ संग्रह को पहले ही अनपैक किया जा चुका है. अगर आउटपुट बेस मौजूद नहीं है, तो क्लाइंट संग्रह की फ़ाइलों को अनज़िप करता है और उनके mtime को नौ साल बाद की तारीख पर सेट करता है. इंस्टॉल हो जाने के बाद, क्लाइंट पुष्टि करता है कि अनज़िप की गई फ़ाइलों के mtime, बहुत पुरानी तारीख के बराबर हैं. इससे यह पक्का किया जाता है कि इंस्टॉलेशन में कोई छेड़छाड़ नहीं हुई है.

अगर सर्वर पर कुछ समय तक कोई गतिविधि नहीं होती है, तो सर्वर प्रोसेस बंद हो जाएगी. डिफ़ॉल्ट रूप से, यह समय तीन घंटे होता है. हालांकि, स्टार्टअप विकल्प --max_idle_secs का इस्तेमाल करके इसे बदला जा सकता है. ज़्यादातर मामलों में, उपयोगकर्ता को यह पता नहीं चलता कि कोई सर्वर चल रहा है. हालांकि, कभी-कभी इस बात का ध्यान रखना ज़रूरी होता है. उदाहरण के लिए, अगर अलग-अलग डायरेक्ट्री में कई ऑटोमेटेड बिल्ड करने वाली स्क्रिप्ट चलाई जा रही हैं, तो यह पक्का करना ज़रूरी है कि आपके पास बहुत सारे ऐसे सर्वर न हों जिनका इस्तेमाल नहीं किया जा रहा है. इसके लिए, जब आपका काम पूरा हो जाए, तो उन्हें बंद कर दें या टाइम आउट की अवधि कम कर दें.

Bazel सर्वर प्रोसेस का नाम, ps x या ps -e f के आउटपुट में bazel(dirname) के तौर पर दिखता है. यहां dirname, आपकी वर्कस्पेस डायरेक्ट्री के रूट को शामिल करने वाली डायरेक्ट्री का बेसनेम है. उदाहरण के लिए:

ps -e f
16143 ?        Sl     3:00 bazel(src-johndoe2) -server -Djava.library.path=...

इससे यह पता लगाना आसान हो जाता है कि किसी वर्कस्पेस से कौनसी सर्वर प्रोसेस जुड़ी है. (ध्यान दें कि ps के कुछ अन्य विकल्पों के साथ, Bazel सर्वर प्रोसेस को सिर्फ़ java नाम दिया जा सकता है.) Bazel सर्वर को shutdown कमांड का इस्तेमाल करके बंद किया जा सकता है.

bazel को चलाने के दौरान, क्लाइंट पहले यह जांच करता है कि सर्वर सही वर्शन का है या नहीं. अगर ऐसा नहीं है, तो सर्वर बंद कर दिया जाता है और नया सर्वर शुरू किया जाता है. इससे यह पक्का होता है कि लंबे समय तक चलने वाली सर्वर प्रोसेस का इस्तेमाल, सही वर्शनिंग में रुकावट न डाले.