Forum Discussion
DM_GWPipeline_Gateway_MashupDataAccessError: "Timeout expired"
I´ve been having the following error during Power BI Service semantic models data refreshes via Azure Devops.
Data source error: {"error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","pbi.error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","parameters":{},"details":[{"code":"DM_ErrorDetailNameCode_UnderlyingErrorCode","detail":{"type":1,"value":"-2147467259"}},{"code":"DM_ErrorDetailNameCode_UnderlyingErrorMessage","detail":{"type":1,"value":"Timeout expired. The operation did not complete in the allotted time."}},{"code":"DM_ErrorDetailNameCode_UnderlyingHResult","detail":{"type":1,"value":"-2147467259"}},{"code":"Microsoft.Data.Mashup.HostingError.Reason","detail":{"type":1,"value":"Timed out"}}],"exceptionCulprit":1}} "
I understang that it's related to M language queries. But i would like to understand the detail ""Timeout expired. The operation did not complete in the allotted time." What does it means?
Nowadays, just one of the semantic models tables uses M language. The rest of the tables are brought via SQL to the semantic models.
If I use SQL to bring all the tables to build the semantic model, won´t i have this problem anymore?
Thanks in advance for the help.
Hi Data-eng-81,
Fair enough on the command timeout, and your one minute figure does argue against it. Two things about the retry plan before you build it, both documented and both easy to walk into.
The first is that retrying harder can be invisible. Microsoft's own note on the refresh API says Power BI might drop requests if too many arrive in a short period, that it performs one refresh, queues the next request and drops all the others, and that by design you cannot query the status of dropped requests. On top of that the service accepts only one refresh operation at a time for a given model, and a second request while one is already running returns a 400. So if the trigger really is everything firing at once out of DevOps, tighter retry intervals can produce attempts your PowerShell has no way to see, and the run will look like it failed more often than it did.
The second is that if you want to test the concurrency idea rather than infer it, the gateway is where to look, and that fits your capacity metrics showing no breach at the time of failure. The number of mashup containers is what determines how many queries can execute in parallel, and it is set by MashupDefaultPoolContainerMaxCount, which has scaled automatically from CPU capacity since the June 2019 gateway release. Counting how many Mashup container processes are alive on that host during a failing window will tell you whether you are saturating it.
One trap if you do ask your vendor to raise it. Changing those values by hand has no effect unless MashupDisableContainerAutoConfig is also set to True in the same config file. Otherwise auto scaling keeps overriding what you set and it looks like the change did nothing, which is an easy afternoon to lose.
