ब्लूमबर्ग एपीआई अनुरोध समय बाहर

Question

एक ReferenceDataRequest मैं एक EventQueue

Service refdata = _session.GetService("//blp/refdata"); 
Request request = refdata.CreateRequest("ReferenceDataRequest"); 
// append the appropriate symbol and field data to the request 
EventQueue eventQueue = new EventQueue(); 
Guid guid = Guid.NewGuid(); 
CorrelationID id = new CorrelationID(guid); 
_session.SendRequest(request, eventQueue, id); 
long _eventWaitTimeout = 60000; 
myEvent = eventQueue.NextEvent(_eventWaitTimeout); 

आम तौर पर मैं कतार से संदेश प्राप्त कर सकते हैं के साथ इसे भेजने की स्थापना करने के बाद, लेकिन मैं स्थिति मार कर रहा हूँ अब है कि अगर मैं कर रहा हूँ एप्लिकेशन (सामान्य रूप से दसवां के आसपास) के एक ही समय में अनुरोध के एक नंबर बनाने, मैं एक TIMEOUT EventType

if (myEvent.Type == Event.EventType.TIMEOUT) 
    throw new Exception("Timed Out - need to rethink this strategy"); 
else 
    msg = myEvent.GetMessages().First(); 

ये वही धागे पर किए जा रहे हैं देखते हैं, लेकिन मैं वहाँ कहीं कुछ के साथ है कि यह सोचते कर रहा हूँ वह लाइन जो मैं उपभोग कर रहा हूं और रिलीज़ नहीं कर रहा हूं।

किसी के पास कोई सुराग या सलाह है?

एसओ से बीएलपी के एपीआई पर कई संदर्भ नहीं हैं, लेकिन उम्मीद है कि हम उस स्थिति को सुधारना शुरू कर सकते हैं।

Answer 1

मैं वास्तव में कभी भी इस प्रश्न को हल करने के लिए नहीं मिला था, लेकिन हमें एक कामकाज मिला।

सर्वर एपीआई दस्तावेज में एक छोटी, स्पष्ट रूप से फेंकने, टिप्पणी के आधार पर, हमने दूसरा सत्र बनाने का विकल्प चुना। एक सत्र स्थिर अनुरोधों के लिए ज़िम्मेदार है, दूसरा वास्तविक समय के लिए। जैसे

_marketDataSession.OpenService("//blp/mktdata"); 
_staticSession.OpenService("//blp/refdata"); 

साधन एक सत्र तुल्यकालिक अन्य अधिक सदस्यता मोड में संचालित होता है, - मुझे लगता है कि इस द्वंद्व जो हमारे समस्याओं की जड़ में था।

उस परिवर्तन को करने के बाद, हमें कोई समस्या नहीं है।

Answer 2

अच्छा ब्लूमबर्ग एपीआई के दर्द का आनंद ले रहे stackoverflow पर किसी अन्य व्यक्ति को देखने के लिए :-)

मुझे लगता है मैं निम्नलिखित पैटर्न (मैं उदाहरण के कोड से कॉपी किया संदिग्ध) का उपयोग कहने के लिए शर्मिंदा हूँ। ऐसा लगता है कि यह काफी मजबूत काम करता है, लेकिन शायद कुछ महत्वपूर्ण संदेशों को अनदेखा करता है। लेकिन मुझे आपकी टाइम-आउट समस्या नहीं मिलती है। यह जावा है, लेकिन सभी भाषाएं मूल रूप से वही काम करती हैं।

cid = session.sendRequest(request, null); 
    while (true) { 
    Event event = session.nextEvent(); 
    MessageIterator msgIter = event.messageIterator(); 
    while (msgIter.hasNext()) { 
     Message msg = msgIter.next(); 
     if (msg.correlationID() == cid) { 
     processMessage(msg, fieldStrings, result); 
     } 
    } 
    if (event.eventType() == Event.EventType.RESPONSE) { 
     break; 
    } 
    } 

यह काम कर सकता है क्योंकि यह प्रत्येक घटना से सभी संदेशों को खपत करता है।

Answer 3

दस्तावेज़ों का मेरा पठन इस बात से सहमत है कि आपको "// blp/mktdata" और "// blp/refdata" सेवाओं के लिए अलग-अलग सत्रों की आवश्यकता है।

Answer 4

ऐसा लगता है जैसे आप एक ही बार में कई अनुरोध कर रहे हैं। बीबी केवल किसी भी समय प्रति कनेक्शन अनुरोधों की एक निश्चित संख्या को संसाधित करेगा। ध्यान दें कि अधिक से अधिक कनेक्शन खोलने से मदद नहीं मिलेगी क्योंकि प्रति सब्सक्रिप्शन भी सीमित है। यदि आप एक साथ बड़ी संख्या में उपभोग करने वाले अनुरोध करते हैं, तो कुछ समय समाप्त हो सकते हैं। साथ ही, आपको अनुरोध पूरी तरह से संसाधित करना चाहिए (जब तक आप RESPONSE संदेश प्राप्त नहीं करते), या उन्हें रद्द करें। बकाया आंशिक अनुरोध एक स्लॉट बर्बाद कर रहा है। चूंकि दो सत्रों में विभाजित होने से आपको मदद मिली है, ऐसा लगता है कि आप एक साथ कई सब्सक्रिप्शन अनुरोध भी कर रहे हैं। क्या आप स्नैपशॉट लेने के तरीके के रूप में सब्सक्रिप्शन का उपयोग कर रहे हैं? यह एक उपकरण की सदस्यता लेता है, प्रारंभिक मान प्राप्त करता है, और सदस्यता लेता है। यदि ऐसा है, तो आपको एक अलग डिजाइन खोजने की कोशिश करनी चाहिए। सब्सक्रिप्शन का उपयोग करने का इरादा इस तरह से नहीं है। एक उत्कृष्ट सदस्यता अनुरोध अनुरोध स्लॉट का भी उपयोग करता है। यही कारण है कि कई व्यक्तिगत अनुरोध करने की बजाय एकल सदस्यता सूची में जितनी संभव हो उतनी सब्सक्रिप्शन बैच करना सर्वोत्तम होता है। उम्मीद है कि यह आपके एपीआई के उपयोग में मदद करता है।

Answer 5

वैसे, मैं आपके नमूना कोड से नहीं कह सकता हूं, लेकिन जब आप ईवेंट कतार से संदेशों पर अवरुद्ध होते हैं, तो क्या आप मुख्य ईवेंट कतार से भी पढ़ रहे हैं (एक अलग घटना कतार में)? आपको कतार के सभी संदेशों को संसाधित करना होगा, खासकर यदि आपके पास बकाया सदस्यता है। प्रतिक्रिया वास्तव में तेजी से कतार कर सकते हैं। यदि आप संदेशों को संसाधित नहीं कर रहे हैं, तो सत्र कुछ कतार सीमाएं मार सकता है, जो आपको टाइमआउट प्राप्त कर रहे हैं। साथ ही, यदि आप संदेश नहीं पढ़ते हैं, तो आपको धीमे उपभोक्ता को चिह्नित किया जा सकता है और लंबित संदेशों का उपभोग करने तक अधिक डेटा प्राप्त नहीं किया जा सकता है। एपीआई async है। इवेंट कतार विशिष्ट संदर्भों पर अवरुद्ध करने का एक तरीका है, जिसमें मुख्य कतार से सभी संदेशों को बिना किसी संदर्भ में संसाधित किया जाता है, जहां अवरोध ठीक है, और अन्यथा अणुओं को संसाधित करने के लिए तर्क प्रवाह को बाधित करना मुश्किल होगा।

Answer 6

एक ग्राहक को एक ही समस्या दिखाई देती है। मैंने एक सत्र में सैकड़ों अनुरोधों को पारित करने के बजाय सैकड़ों सत्र बनाकर हल किया। ब्लूमबर्ग इस बीएफआई (ब्रूट फोर्स और अज्ञानता) दृष्टिकोण से खुश नहीं हो सकता है क्योंकि हम प्रत्येक सत्र के लिए फील्ड अनुरोध भेज रहे हैं लेकिन यह काम करता है।

Answer 7

मैं बस कुछ प्रारंभ करना चाहता था, आपके प्रारंभिक पोस्ट में शामिल कोड के लिए धन्यवाद।

यदि आप लंबी अवधि के लिए ऐतिहासिक इंट्राडे डेटा के लिए अनुरोध करते हैं (जिसके परिणामस्वरूप ब्लूमबर्ग एपीआई द्वारा उत्पन्न कई घटनाएं होती हैं), तो एपीआई दस्तावेज में निर्दिष्ट पैटर्न का उपयोग न करें, क्योंकि यह आपके एप्लिकेशन को बहुत धीमा कर सकता है सभी घटनाओं को पुनः प्राप्त करने के लिए। असल में, सत्र ऑब्जेक्ट पर NextEvent() को कॉल न करें! इसके बजाय एक समर्पित EventQueue का उपयोग करें।

इसके बजाय ऐसा करने का:

var cID = new CorrelationID(1); 
session.SendRequest(request, cID); 
do { 
    Event eventObj = session.NextEvent(); 
    ... 
} 

यह करें:

var cID = new CorrelationID(1); 
var eventQueue = new EventQueue(); 
session.SendRequest(request, eventQueue, cID); 
do { 
    Event eventObj = eventQueue.NextEvent(); 
    ... 
} 

यह हालांकि एपीआई विशेष रूप से निर्धारित करने योग्य नहीं माना जाता है, कुछ प्रदर्शन में सुधार में परिणाम कर सकते हैं ...