Apigee की आम समस्याएं

जब cachehit फ़्लो वैरिएबल का इस्तेमाल, LookupCache नीति के बाद किया जाता है, तो कॉलबैक लागू होने से पहले LookupPolicy, DebugInfo ऑब्जेक्ट को पॉप्युलेट कर देती है. ऐसा, असाइनमेंट के साथ-साथ होने वाली प्रोसेस के लिए, डीबग पॉइंट डिस्पैच करने के तरीके की वजह से होता है. इस वजह से, गड़बड़ी होती है.

समाधान: पहले कॉल के तुरंत बाद, फिर से प्रोसेस दोहराएं (दूसरा कॉल करें).

InvalidateCache नीति में PurgeChildEntries सेट करने पर, सिर्फ़ KeyFragment एलिमेंट की वैल्यू को खाली किया जाना चाहिए. हालांकि, ऐसा करने पर पूरी कैश मेमोरी खाली हो जाती है.

इस समस्या को हल करने का तरीका: कैश मेमोरी के वर्शन को दोहराने और कैश मेमोरी को अमान्य करने की ज़रूरत को बायपास करने के लिए, KeyValueMapOperations नीति का इस्तेमाल करें.

उदाहरण के लिए, ऐसा तब हो सकता है, जब अलग-अलग रिविज़न का इस्तेमाल करके, सीआई/सीडी डिप्लॉयमेंट पाइपलाइन के एक साथ कई रन हों. इस समस्या से बचने के लिए, मौजूदा डिप्लॉयमेंट पूरा होने से पहले, एपीआई प्रॉक्सी या SharedFlows को डिप्लॉय करने से बचें.

इस समस्या को हल करने का तरीका: एक साथ कई एपीआई प्रॉक्सी या SharedFlow डिप्लॉयमेंट से बचें.

Edge API Analytics में, कभी-कभी एपीआई कॉल के लिए डुप्लीकेट डेटा हो सकता है. ऐसे में, Edge API Analytics में एपीआई कॉल के लिए दिखाई गई गिनती, तीसरे पक्ष के आंकड़े इकट्ठा करने वाले टूल में दिखाई गई वैल्यू से ज़्यादा होती है.

इस समस्या को हल करने का तरीका: Analytics डेटा एक्सपोर्ट करें और डेटा से डुप्लीकेट कॉपी हटाने के लिए, gateway_flow_id फ़ील्ड का इस्तेमाल करें.

TLS_DISABLED_ALGO और TLS_ENABLED_CIPHERS विकल्प सही तरीके से काम नहीं करते हैं. Edge यूज़र इंटरफ़ेस (यूआई) के लिए कुछ खास सिफ़र चालू करने के लिए, यहां दिया गया तरीका अपनाएं:

1. /opt/apigee/etc/edge-ui.d/SSL.sh कॉन्फ़िगरेशन फ़ाइल खोलें.
2. -Djdk.tls.server.cipherSuites प्रॉपर्टी जोड़ें. इसमें UI_OPTIONS के अंदर, IANA नोटेशन में सिफ़र सुइट की कॉमा-सेपरेटेड लिस्ट शामिल करें. उदाहरण के लिए:

   UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"

3. कॉन्फ़िगरेशन फ़ाइल में किए गए बदलाव सेव करें.
4. Edge यूज़र इंटरफ़ेस (यूआई) को रीस्टार्ट करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge, OpenAPI Specification 3.0 के साथ काम करता है. ऐसा तब होता है, जब आपके पोर्टल पर स्पेसिफ़िकेशन एडिटर का इस्तेमाल करके स्पेसिफ़िकेशन बनाए जाते हैं और SmartDocs का इस्तेमाल करके एपीआई पब्लिश किए जाते हैं. हालांकि, कुछ सुविधाओं के सबसेट अभी काम नहीं करते.

  उदाहरण के लिए, OpenAPI Specification 3.0 की ये सुविधाएं फ़िलहाल काम नहीं करतीं:

  • स्कीमा को जोड़ने और बढ़ाने के लिए allOf प्रॉपर्टी
  • रिमोट रेफ़रंस

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

  ध्यान दें: एपीआई रेफ़रंस दस्तावेज़ को रेंडर करते समय, स्पेसिफ़िकेशन एडिटर, SmartDocs की तुलना में कम पाबंदी वाला होता है. इसलिए, आपको इन टूल के बीच अलग-अलग नतीजे दिख सकते हैं.

• पोर्टल में 'इस एपीआई को आज़माएं' सुविधा का इस्तेमाल करते समय, Accept हेडर को application/json पर सेट किया जाता है. भले ही, OpenAPI स्पेसिफ़िकेशन में consumes के लिए कोई भी वैल्यू सेट की गई हो.
• 138438484: एक से ज़्यादा सर्वर इस्तेमाल नहीं किए जा सकते.

• फ़िलहाल, एक से ज़्यादा उपयोगकर्ताओं के लिए, पोर्टल में एक साथ बदलाव करने की सुविधा उपलब्ध नहीं है. जैसे, पेज, थीम, सीएसएस या स्क्रिप्ट में बदलाव करना.
• अगर पोर्टल से एपीआई रेफ़रंस दस्तावेज़ का पेज मिटाया जाता है, तो उसे फिर से बनाने का कोई तरीका नहीं है. इसके लिए, आपको एपीआई प्रॉडक्ट को मिटाकर फिर से जोड़ना होगा और एपीआई रेफ़रंस दस्तावेज़ को फिर से जनरेट करना होगा.
• कॉन्टेंट की सुरक्षा से जुड़ी नीति को कॉन्फ़िगर करने पर, बदलावों को पूरी तरह लागू होने में 15 मिनट तक लग सकते हैं.
• पोर्टल की थीम को पसंद के मुताबिक बनाने पर, बदलावों को पूरी तरह लागू होने में पांच मिनट लग सकते हैं.

• आने वाले समय में रिलीज़ होने वाले वर्शन में, Search को इंटिग्रेट किए गए पोर्टल में इंटिग्रेट किया जाएगा.

NGINX में ngx_http_rewrite_module पर असर डालने वाली एक सुरक्षा जोखिम (CVE-2026-42945) का पता चला है. सुरक्षा स्कैनिंग टूल, Apigee Edge for Private Cloud के साथ शामिल NGINX बाइनरी को फ़्लैग कर सकते हैं. ऐसा इसलिए, क्योंकि इस मॉड्यूल को NGINX में स्टैटिक तौर पर कंपाइल किया जाता है.

Apigee Edge for Private Cloud पर पड़ने वाला असर:

Apigee Edge for Private Cloud के डिफ़ॉल्ट, शिप किए गए कॉन्फ़िगरेशन पर, इस जोखिम की आशंका का कोई असर नहीं पड़ता. CVE-2026-42945 का फ़ायदा उठाया जा सकता है. हालांकि, ऐसा सिर्फ़ NGINX के कुछ कॉन्फ़िगरेशन पैटर्न के ज़रिए किया जा सकता है. खास तौर पर, किसी खास क्रम में rewrite डायरेक्टिव का इस्तेमाल करके. ये पैटर्न, Apigee Edge for Private Cloud के किसी भी स्टैंडर्ड NGINX कॉन्फ़िगरेशन में मौजूद नहीं हैं.

कार्रवाई ज़रूरी है:

• Private Cloud के लिए डिफ़ॉल्ट Apigee Edge कॉन्फ़िगरेशन के लिए: किसी पैच, अपग्रेड या ऑपरेशनल बदलाव की ज़रूरत नहीं है. डिफ़ॉल्ट इंस्टॉलेशन के लिए, CVE-2026-42945 के बारे में स्कैनर की जांच के नतीजों को गलत पहचान के तौर पर माना जा सकता है. अपने जोखिम मैनेजमेंट सिस्टम में इस अपवाद को दस्तावेज़ के तौर पर सेव करने के लिए, इस टेक्स्ट का इस्तेमाल किया जा सकता है:

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• NGINX के कस्टम कॉन्फ़िगरेशन के लिए: अगर आपने Apigee Edge for Private Cloud इंस्टॉलेशन में NGINX कॉन्फ़िगरेशन फ़ाइलों में मैन्युअल तरीके से बदलाव किया है (उदाहरण के लिए, /opt/nginx में), तो आपको खुद से यह जांच करनी चाहिए कि आपके कस्टम कॉन्फ़िगरेशन की वजह से, असुरक्षित पैटर्न तो नहीं बन गया है:
  1. रीराइट डायरेक्टिव की जांच करें: हर NGINX नोड पर, यह कमांड चलाएं:

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. नतीजों का विश्लेषण करें:
     • अगर इस कमांड से कोई आउटपुट नहीं मिलता है, तो इसका मतलब है कि आपके सिस्टम पर कोई असर नहीं पड़ा है.
     • अगर मैच मिलते हैं, तो हर इंस्टेंस की समीक्षा करें. यह जोखिम सिर्फ़ तब मौजूद होता है, जब किसी ब्लॉक के लिए यहां दी गई सभी शर्तें पूरी होती हैं:
       • rewrite डायरेक्टिव का इस्तेमाल किया गया हो.
       • इसके तुरंत बाद, उसी कॉन्फ़िगरेशन ब्लॉक में कोई दूसरा rewrite, if या set डायरेक्टिव मौजूद हो.
       • डायरेक्टिव में, बिना नाम वाले पीसीआरई कैप्चर ग्रुप (उदाहरण के लिए, $1, $2 वगैरह) का इस्तेमाल किया गया है.
       • डायरेक्टिव में मौजूद बदली जाने वाली स्ट्रिंग में सवाल का निशान (?) शामिल है.
  3. कम करना (अगर जोखिम है): अगर ऊपर दी गई सभी शर्तें, कस्टम कॉन्फ़िगरेशन के किसी भी हिस्से के लिए सही हैं, तो इन तरीकों से जोखिम कम करें:
     • बदली जाने वाली स्ट्रिंग से सवाल का निशान (?) हटाना.
     • बिना नाम वाले कैप्चर ग्रुप के बजाय, नाम वाले पीसीआरई कैप्चर ग्रुप का इस्तेमाल करना.
     • चेन किए गए निर्देशों की ज़रूरत का फिर से आकलन किया जा रहा है.

Edge for Private Cloud 4.53.00 और इसके बाद के वर्शन में, यूज़र इंटरफ़ेस (यूआई) पर "सेवा बंद होने की सूचना" (ईओएल) वाला चेतावनी पॉप-अप दिखता है. यह चेतावनी
बार-बार दिखती है. इसे रोका नहीं जा सकता और न ही इसकी फ़्रीक्वेंसी कम की जा सकती है.

फ़िलहाल, उपयोगकर्ताओं के पास इस EOL चेतावनी को बंद करने या इसकी फ़्रीक्वेंसी कम करने का कोई तरीका उपलब्ध नहीं है.

"BC" नाम का इस्तेमाल करके, Bouncy Castle क्रिप्टोग्राफ़ी प्रोवाइडर को लोड करने की कोशिश करने वाले ग्राहक के Java कॉलआउट काम नहीं कर सकते. ऐसा इसलिए, क्योंकि FIPS को सपोर्ट करने के लिए डिफ़ॉल्ट प्रोवाइडर को Bouncy Castle FIPS में बदल दिया गया है. इस्तेमाल किए जाने वाले नए प्रोवाइडर का नाम "BCFIPS" है.

"BC" नाम का इस्तेमाल करके, Bouncy Castle क्रिप्टोग्राफ़ी प्रोवाइडर को लोड करने की कोशिश करने वाले ग्राहक के Java कॉलआउट काम नहीं कर सकते. ऐसा इसलिए, क्योंकि FIPS को सपोर्ट करने के लिए डिफ़ॉल्ट प्रोवाइडर को Bouncy Castle FIPS में बदल दिया गया है. इस्तेमाल किए जाने वाले नए प्रोवाइडर का नाम "BCFIPS" है.

इस समस्या का असर सिर्फ़ उन लोगों पर पड़ता है जो MINT का इस्तेमाल कर रहे हैं या जिन्होंने Edge for Private Cloud इंस्टॉलेशन में MINT चालू किया है.

असर डालने वाला कॉम्पोनेंट: edge-message-processor

समस्या: अगर आपने कमाई करने की सुविधा चालू की है और 4.52.01 को नए इंस्टॉलेशन के तौर पर इंस्टॉल किया जा रहा है या पिछले Private Cloud वर्शन से अपग्रेड किया जा रहा है, तो आपको मैसेज प्रोसेसर से जुड़ी समस्या का सामना करना पड़ेगा. इससे ओपन थ्रेड की संख्या धीरे-धीरे बढ़ती जाएगी और संसाधन खत्म हो जाएंगे. edge-message-processor के system.log में यह अपवाद दिखता है:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

हाल ही में, एचटीटीपी/2 प्रोटोकॉल (CVE-2023-44487) के कई वर्शन में, सेवा से इनकार (डीओएस) की एक कमज़ोरी का पता चला है. इसमें Apigee Edge for Private Cloud भी शामिल है. इस जोखिम की आशंका की वजह से, Apigee API मैनेजमेंट की सुविधा में DoS हो सकता है. ज़्यादा जानकारी के लिए, Apigee का सुरक्षा बुलेटिन GCP-2023-032 देखें.

Edge for Private Cloud के राउटर और मैनेजमेंट सर्वर कॉम्पोनेंट, इंटरनेट से कनेक्ट होते हैं. इसलिए, इनमें सुरक्षा से जुड़ी समस्याएं हो सकती हैं. हालांकि, Private Cloud के लिए Edge के Edge-specific कॉम्पोनेंट के मैनेजमेंट पोर्ट पर HTTP/2 चालू है, लेकिन इनमें से कोई भी कॉम्पोनेंट इंटरनेट पर उपलब्ध नहीं है. Cassandra, Zookeeper वगैरह जैसे नॉन-एज कॉम्पोनेंट पर, HTTP/2 चालू नहीं है. हमारा सुझाव है कि Edge for Private Cloud में मौजूद जोखिम को ठीक करने के लिए, यह तरीका अपनाएं:

• Edge for Private Cloud के 4.51.00.11 या इसके बाद के वर्शन के लिए तरीका
• Edge for Private Cloud के 4.51.00.11 से पुराने वर्शन के लिए तरीका

अगर Edge Private Cloud के 4.51.00.11 या इसके बाद के वर्शन का इस्तेमाल किया जा रहा है, तो यह तरीका अपनाएं:

1. मैनेजमेंट सर्वर को अपडेट करें:

   1. हर मैनेजमेंट सर्वर नोड पर, /opt/apigee/customer/application/management-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें:

      conf_webserver_http2.enabled=false

   3. मैनेजमेंट सर्वर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-management-server restart

2. मैसेज प्रोसेसर को अपडेट करना:

   1. हर मैसेज प्रोसेसर नोड पर, /opt/apigee/customer/application/message-processor.properties खोलें
   2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें:

      conf_webserver_http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-message-processor restart

3. राउटर को अपडेट करें:

   1. हर राउटर नोड पर, /opt/apigee/customer/application/router.properties खोलें
   2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें:

      conf_webserver_http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-router restart

4. QPID अपडेट करें:

   1. हर QPID नोड पर, /opt/apigee/customer/application/qpid-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें:

      conf_webserver_http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-qpid-server restart

5. Postgres को अपडेट करें:

   1. हर Postgres नोड पर, /opt/apigee/customer/application/postgres-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें:

      conf_webserver_http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-postgres-server restart

अगर Private Cloud के 4.51.00.11 से पुराने वर्शन के लिए Edge का इस्तेमाल किया जा रहा है, तो यह तरीका अपनाएं:

1. मैनेजमेंट सर्वर को अपडेट करें:

   1. हर मैनेजमेंट सर्वर नोड पर, /opt/apigee/customer/application/management-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में, ये दो लाइनें जोड़ें:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. मैनेजमेंट सर्वर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-management-server restart

2. मैसेज प्रोसेसर को अपडेट करना:

   1. हर मैसेज प्रोसेसर नोड पर, /opt/apigee/customer/application/message-processor.properties खोलें
   2. प्रॉपर्टी फ़ाइल में, ये दो लाइनें जोड़ें:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-message-processor restart

3. राउटर को अपडेट करें:

   1. हर राउटर नोड पर, /opt/apigee/customer/application/router.properties खोलें
   2. प्रॉपर्टी फ़ाइल में, ये दो लाइनें जोड़ें:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-router restart

4. QPID अपडेट करें:

   1. हर QPID नोड पर, /opt/apigee/customer/application/qpid-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में, ये दो लाइनें जोड़ें:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-qpid-server restart

5. Postgres को अपडेट करें:

   1. हर Postgres नोड पर, /opt/apigee/customer/application/postgres-server.properties खोलें
   2. प्रॉपर्टी फ़ाइल में, ये दो लाइनें जोड़ें:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें:

      apigee-service edge-postgres-server restart

Apigee-postgresql को Edge for Private Cloud के वर्शन 4.50 या 4.51 से वर्शन 4.52 पर अपग्रेड करने में समस्याएं आ रही हैं. ये समस्याएं मुख्य रूप से तब होती हैं, जब टेबल की संख्या 500 से ज़्यादा होती है.

नीचे दी गई एसक्यूएल क्वेरी चलाकर, Postgres में मौजूद टेबल की कुल संख्या देखी जा सकती है:

select count(*) from information_schema.tables

समस्या हल करने का तरीका: Apigee Edge 4.50.00 या 4.51.00 को 4.52.00 पर अपडेट करते समय, Apigee-postgresql को अपग्रेड करने से पहले, शुरुआती चरण पूरा करना न भूलें.

149245401: LDAP संसाधन के ज़रिए कॉन्फ़िगर की गई, JNDI के लिए LDAP कनेक्शन पूल सेटिंग लागू नहीं होती हैं. साथ ही, JNDI की डिफ़ॉल्ट सेटिंग की वजह से, हर बार एक बार इस्तेमाल किए जा सकने वाले कनेक्शन बनते हैं. इस वजह से, हर बार कनेक्शन खुलते और बंद होते हैं. इससे LDAP सर्वर से हर घंटे बहुत सारे कनेक्शन बन जाते हैं.

समाधान:

एलडीएपी कनेक्शन पूल की प्रॉपर्टी बदलने के लिए, यहां दिया गया तरीका अपनाएं. इससे सभी एलडीएपी नीतियों में एक साथ बदलाव किया जा सकेगा.

1. अगर कॉन्फ़िगरेशन प्रॉपर्टी फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं:

   /opt/apigee/customer/application/message-processor.properties

2. फ़ाइल में यह कॉन्टेंट जोड़ें. साथ ही, अपनी LDAP रिसॉर्स कॉन्फ़िगरेशन की ज़रूरत के हिसाब से, Java Naming and Directory Interface (JNDI) प्रॉपर्टी की वैल्यू बदलें.

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. पक्का करें कि फ़ाइल /opt/apigee/customer/application/message-processor.properties का मालिकाना हक apigee:apigee के पास हो.
4. हर मैसेज प्रोसेसर को फिर से शुरू करें.

यह पुष्टि करने के लिए कि आपके कनेक्शन पूल JNDI प्रॉपर्टी लागू हो रही हैं, tcpdump किया जा सकता है. इससे समय के साथ LDAP कनेक्शन पूल के व्यवहार का पता चलता है.

139051927: मैसेज प्रोसेसर में प्रॉक्सी प्रोसेसिंग में ज़्यादा समय लग रहा है. इससे सभी एपीआई प्रॉक्सी पर असर पड़ रहा है. इसकी वजह से, एपीआई रिस्पॉन्स के सामान्य समय में 200 से 300 मि॰से॰ की देरी हो रही है. साथ ही, टीपीएस कम होने पर भी यह समस्या कभी-कभी हो सकती है. ऐसा तब हो सकता है, जब मैसेज प्रोसेसर 50 से ज़्यादा टारगेट सर्वर से कनेक्ट होता है.

समस्या की मुख्य वजह: मैसेज प्रोसेसर, एक कैश मेमोरी रखते हैं. यह कैश मेमोरी, टारगेट सर्वर के यूआरएल को HTTPClient ऑब्जेक्ट से मैप करती है. ऐसा टारगेट सर्वर से आउटगोइंग कनेक्शन के लिए किया जाता है. डिफ़ॉल्ट रूप से, यह सेटिंग 50 पर सेट होती है. यह ज़्यादातर डिप्लॉयमेंट के लिए बहुत कम हो सकती है. जब किसी डिप्लॉयमेंट में सेटअप के दौरान कई संगठन/एनवायरमेंट के कॉम्बिनेशन होते हैं और टारगेट सर्वर की संख्या 50 से ज़्यादा होती है, तो टारगेट सर्वर के यूआरएल, कैश मेमोरी से हटा दिए जाते हैं. इससे अनुरोध पूरा होने में ज़्यादा समय लगता है.

पुष्टि करना: यह पता लगाने के लिए कि टारगेट सर्वर के यूआरएल को हटाने की वजह से, अनुरोध पूरा होने में देरी हो रही है या नहीं, Message Processor के system.logs में "onEvict" या "Eviction" कीवर्ड खोजें. अगर ये कीवर्ड लॉग में मौजूद हैं, तो इसका मतलब है कि टारगेट सर्वर के यूआरएल को HTTPClient कैश मेमोरी से हटाया जा रहा है. ऐसा इसलिए हो रहा है, क्योंकि कैश मेमोरी का साइज़ बहुत छोटा है.

अस्थायी समाधान: Edge for Private Cloud के वर्शन 19.01 और 19.06 के लिए, HTTPClient कैश मेमोरी /opt/apigee/customer/application/message-processor.properties में बदलाव किया जा सकता है और इसे कॉन्फ़िगर किया जा सकता है:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें. सभी मैसेज प्रोसेसर के लिए एक जैसे बदलाव करें.

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

ध्यान दें: Edge for Private Cloud के वर्शन 50.00 में, डिफ़ॉल्ट सेटिंग 500 पर सेट होती है.

157933959: संगठन या एनवायरमेंट लेवल पर स्कोप किए गए एक ही कुंजी वैल्यू मैप (केवीएम) में एक साथ इंसर्ट और अपडेट करने से, डेटा में अंतर आ जाता है और अपडेट नहीं हो पाते.

ध्यान दें: यह सीमा सिर्फ़ Edge for Private Cloud पर लागू होती है. Edge for Public Cloud और हाइब्रिड के लिए, यह सीमा लागू नहीं होती.

Edge for Private Cloud में इस समस्या को हल करने के लिए, apiproxy स्कोप पर KVM बनाएं.