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

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

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

अगर क्लाइंट को रन हो रहा कोई सर्वर इंस्टेंस नहीं मिलता है, तो वह नया इंस्टेंस शुरू करता है. इसके लिए, वह यह देखता है कि आउटपुट बेस पहले से मौजूद है या नहीं. अगर आउटपुट बेस पहले से मौजूद है, तो इसका मतलब है कि blaze आर्काइव को पहले ही अनपैक किया जा चुका है. इसके अलावा, अगर आउटपुट बेस मौजूद नहीं है, तो क्लाइंट, आर्काइव की फ़ाइलों को अनज़िप करता है और उनकी 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 सर्वर को बंद किया जा सकता है.

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