Workaround
Inmiddels is duidelijk geworden wat de oorzaak is. Dit probleem lijkt alleen op te treden met Power Query in een deel van de Excel-versies. Het probleem lijkt zich te concentreren rond recente Excel-versies, bijvoorbeeld die van Office 365. Op oudere versies is reproductie nog niet geslaagd; de downloads lopen dan gewoon altijd netjes door.
Oorzaak
De oorzaak is vergelijkbaar met het Dining Philisopher’s-probleem (zie Filosofenprobleem - Wikipedia), waarbij er twee filosofen aan tafel zitten met daarop twee borden en in totaal twee vorken. De filosofen zijn Excel en Bridge Online; de vorken zijn twee downloads van dezelfde URL.
De Excel-filosoof wil het volgende gedrag laten zien:
- Start download 1 via de URL x.
- Wacht tot een aantal rijen ontvangen zijn of een zekere tijd is verstreken.
- Pauzeer download 1 door geen data meer binnen te halen totdat download 2 afgerond is.
- Start download 2 van exact dezelfde URL x.
- Haal alle rijen binnen via download 2.
- Sluit download 2 af.
- Voer onbekende interne magie uit.
- Zet download 2 voort.
- Haal de resterende rijen binnen.
- Sluit download 1 af.
De Bridge Online-filosoof wil het volgende gedrag laten zien:
- Ontvang een download-verzoek 1 voor de URL x.
- Noteer om alle toekomstige verzoeken voor URL x te parkeren totdat download-verzoek 1 klaar is zodat hetzelfde resultaat opnieuw gebruikt kan worden uit de OData-response cache (zie Invantive Cloud Structuur).
- Start het retourneren van data naar download-verzoek 1.
- Stuur alle rijen op.
- Sla het resultaat op in de OData-response cache.
- Ontvang een download-verzoek 2 voor dezelfde URL x.
- Retourneer de gegevens uit de OData-response cache.
Hierbij ontstaat de situatie dat download 2 van de Excel-filosoof wacht op een antwoord, terwijl de Bridge Online-filosoof wacht totdat download 1 van de Excel-filosoof zijn werk afrondt vooraleer download 2 te bedienen. Een zogenaamde "dead-lock’.
Oplossingsrichtingen
Voor de oplossingsrichtingen is het belangrijk om het gebruik van CPU en geheugen op de betrokken Bridge Online-server te beperken. Momenteel werkt Bridge Online grotendeels met “streaming data”, waardoor net zoals bij fabrieken die via stromen produceren, de totale hoeveelheid data in het werkgeheugen beperkt blijft.
Aangezien de verwerking datasets van meer dan 5 GB niet ongebruikelijk zijn terwijl het huidige geheugengebruik enkele ordes van grootte kleiner is, is het ongewenst om datasets volledig in het werkgeheugen te houden. Volledig in het geheugen vergroot het geheugenbeslag, plus kan eventueel leiden tot prestatieverlies door minder dakpangewijze verwerking van data over de gehele verwerkingsketen.
Merk op dat bij het ophalen van een dataset op een achterliggend platform vooraf niet bekend is hoe groot deze zal worden.
Workaround
Het gebruik van een Table.Buffer-stap in het Power Query-script is een snelle oplossing voor dit probleem. Download-verzoek 2 wordt dan niet door Power Query op Excel geïnitieerd. Excel Power Query zal dan eerst alle data ophalen en bufferen op de PC of Mac.
Detectie
De detectie kan gebeuren indien er (tenminste) twee downloadverzoeken bekend zijn met de volgende eigenschappen:
- Afkomstig van hetzelfde Internet IP-adres (want Excel Power Query).
- Dezelfde Invantive Cloud-gebruiker.
- Dezelfde URL.
- Dezelfde user agent “Mashup”.
- Dezelfde response data cache key, dus dezelfde compressie e.d.
- Een eerste downloadverzoek is actief en heeft tenminste 10 rijen retour gegeven.
- Een tweede downloadverzoek is gearriveerd en wacht op afhandeling.
- Het eerste downloadverzoek heeft geen rijen meer opgehaald sinds het tweede downloadverzoek is gearriveerd.
Vermijden
Een manier om de tweede download mogelijk te maken is het openen van een meerdere databasecontexten in plaats van een voor een gebruiker. Gezien de impact heeft dit niet de voorkeur.
Een andere manier is om download 1 intern alvast zijn data naar de response cache te laten schrijven als de download nog niet alle rijen ophaalt door bijvoorbeeld bij detectie (en alleen na detectie) tijdelijk de producer/consumer-buffers indien nodig intern te vergroten en resultaten weg te schrijven in de OData response cache. Zolang downloadverzoek 1 niet eindigt blijven de buffers groot (wat leidt tot extra resourcegebruik).
Zodra de cache berekend is, kan hiermee na vrijgave downloadverzoek 2 beantwoord worden. Voor downloadverzoek 1 moet de download dan voortgezet worden waar gebleven door de niet-verwerkte rest van de buffers te verwerken.
Het totale geheugengebruik in de tijd kan verlaagd worden door downloadverzoek 1 af te breken.
Afhandeling 1: e-mail sturen aan gebruiker
Een afhandelingsmethode is om een mail te sturen aan de betrokken Invantive Cloud-gebruiker met uitleg. In deze e-mail staat de tip om de download af te breken en de tip om Table.Buffer toe te voegen direct na de OData-download in Excel Power Query.
Afhandeling 2: afbreken en e-mail
Een afhandelingsmethode is om de eerste download volledig af te breken indien mogelijk vanuit de SQL-engine dataproducent. En daarna de e-mail te sturen.
Merk op dat indien de tweede download succesvol wordt afgerond, de data in de OData response cache komt. Echter, metingen geven aan dat dan nog steeds een twee downloadverzoeken door Excel gedaan kunnen worden met hetzelfde dead-lock probleem tot gevolg.