Forum Discussion

joel_delima's avatar
joel_delima
New Member
4 hours ago

Fabric Copy Job Timeout

I have a legacy SQL 2008 server (CDC enabled) and a SQL Server 2025, both have fabric connections and use an on prem data gateway. I'm using the Fabric copy job to incrementally transfer data from the 08 server to the 25 server. This works well for small/medium size tables, however, when I run the job for the first time on large tables (100mil+ rows), the job times out around the 40min mark and returns this error message.

'Type=System.TimeoutException,Message=Dispose resource timeout,Source=Microsoft.DataTransfer.DataContracts,'

I cannot find any reference online as to what this means, could I please get some assistance?

data engineering
data pipeline

1 Reply

  • DreamITLearn's avatar
    DreamITLearn
    Icon for Advocate II rankAdvocate II
    4 hours ago

    Hi joel_delima​,

    this looks like a gateway-side timeout, not an issue with your Copy Job logic itself. A few things point that way:

    • The error source is Microsoft.DataTransfer.DataContracts, which is the data movement/gateway layer, and "Dispose resource timeout" typically means the connection/resource couldn't be cleanly closed within the allotted time, common when a large initial load keeps a connection open far longer than smaller incremental runs.
    • It only fails on the first run on large tables (100M+ rows) because incremental runs after that only move the delta (via CDC), much smaller payloads, so the gateway connection doesn't stay open nearly as long.

    Likely causes and fixes:

    1. On-prem Data Gateway timeout settings - the gateway has its own internal query timeout separate from the Copy Job's settings. Check Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config on the gateway machine for timeout values (similar to the MashupDefaultPoolContainerMaxWorkingSetInMB type settings), these often need to be raised for very large initial loads.
    2. Gateway resource exhaustion - 100M+ row initial loads can exhaust memory/connections on the gateway VM over a 40-minute window. Check gateway machine resource usage (CPU/RAM) during the run.
    3. Split the initial load - rather than relying on the Copy Job to pull the full 100M+ rows in one shot, do a one-time manual bulk load (e.g., via a Pipeline Copy activity with partitioning, or BCP/bulk insert) to seed the table, then let the Fabric Copy Job take over for incremental CDC sync going forward. This sidesteps the timeout entirely for the problematic first run.

    Option 3 is generally the most reliable fix reported for "first full load fails, incremental works fine" patterns with CDC-based pipelines.