ef6: Long running Code First Migration throws RemotingException: "Object has been disconnected from the server"
A code first migration of about 20 minutes causes the following exception when the Update-Database command is executed:
It appears to be something related to a timeout of the migration
In my case the migration was adding a column to a table with about 11 million records, the operation takes time but it does work when the command SQL is directly executed on the database manager
There are other people having the same issue here and here
System.Runtime.Remoting.RemotingException: Object '/7ba26d1b_81f4_4f58_8bf3_92a9b8a3a3fa/zq28jcy6udmgdh9278mbbwoy_163.rem' has been disconnected or does not exist at the server.
at System.Data.Entity.Migrations.Design.ToolingFacade.ToolLogger.Verbose(String sql)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.ExecuteSql(MigrationStatement migrationStatement, DbConnection connection, DbTransaction transaction, DbInterceptionContext interceptionContext)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatementsInternal(IEnumerable`1 migrationStatements, DbConnection connection, DbTransaction transaction, DbInterceptionContext interceptionContext)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatementsWithinTransaction(IEnumerable`1 migrationStatements, DbTransaction transaction, DbInterceptionContext interceptionContext)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatementsWithinNewTransaction(IEnumerable`1 migrationStatements, DbConnection connection, DbInterceptionContext interceptionContext)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatementsInternal(IEnumerable`1 migrationStatements, DbConnection connection, DbInterceptionContext interceptionContext)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatementsInternal(IEnumerable`1 migrationStatements, DbConnection connection)
at System.Data.Entity.Migrations.DbMigrator.<>c__DisplayClass30.<ExecuteStatements>b__2e()
at System.Data.Entity.Infrastructure.DefaultExecutionStrategy.Execute(Action operation)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatements(IEnumerable`1 migrationStatements, DbTransaction existingTransaction)
at System.Data.Entity.Migrations.DbMigrator.ExecuteStatements(IEnumerable`1 migrationStatements)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.ExecuteStatements(IEnumerable`1 migrationStatements)
at System.Data.Entity.Migrations.DbMigrator.ExecuteOperations(String migrationId, VersionedModel targetModel, IEnumerable`1 operations, IEnumerable`1 systemOperations, Boolean downgrading, Boolean auto)
at System.Data.Entity.Migrations.DbMigrator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
at System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
at System.Data.Entity.Migrations.DbMigrator.UpdateInternal(String targetMigration)
at System.Data.Entity.Migrations.DbMigrator.<>c__DisplayClassc.<Update>b__b()
at System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
at System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update(String targetMigration)
at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.Run()
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate)
at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner)
at System.Data.Entity.Migrations.Design.ToolingFacade.Update(String targetMigration, Boolean force)
at System.Data.Entity.Migrations.UpdateDatabaseCommand.<>c__DisplayClass2.<.ctor>b__0()
at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command)
Object '/7ba26d1b_81f4_4f58_8bf3_92a9b8a3a3fa/zq28jcy6udmgdh9278mbbwoy_163.rem' has been disconnected or does not exist at the server.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 40 (10 by maintainers)
Commits related to this issue
- Fixes #96 by increasing the lifetime. https://github.com/dotnet/ef6/issues/96 — committed to matthid/ef6 by matthid 4 years ago
The issue is that the ToolLogger lease lifetime (base class MigrationsLogger is a MarshalByRefObject) is at the default (5 minutes). The ToolingFacade creates the logger, which lives in the main program’s app domain. The migrations run in a different app domain. If a migration takes longer than 5 minutes, the attempt to log any further information results in this error. A solution would be to increase the lease lifetime in the main program. So… in the main program, prior to creating the ToolingFacade, set the lease lifetime to a longer time period:
using System.Runtime.Remoting.Lifetime;…LifetimeServices.LeaseTime = TimeSpan.FromHours(1);Migrations in this case can then take as long as 1 hour before this issue presents itself.
Spent half a day trying different fixes for this. I tried adding the config below to config file of ef6.exe.config, app.config of --config arg, and to the machine.config - it simply doesn’t read these settings.
The only solution is to download the source code of ef6 (https://github.com/dotnet/ef6.git), and mod program.cs;
We have also used this workaround in the past for several years by increasing the LeaseTime in our Configuration.cs file. But as @edswangren already mentioned, it no longer works.
However, i have other information for you: We have been using version 6.2 since its release. The workaround described (LeaseTime > 5min) has definitely worked with it in the past. We don’t have many long running migrations, but we have one this week and it suddenly stops working. So I do not think that the reason for this is an update to 6.3., because we still use 6.2 and it worked before! The reason must be something else.
Today I spent all day to get our migration running somehow.
My migration file to reproduce the issue:
I have tried all versions from 6.1.3 to 6.4
Unfortunately I have no solution either.
@bricelam So, is it true to say from our discussion last week that the comment here is likely a bogus solution to this issue?