Legacy CSLA app moved to Azure generates intermittent RemotingException

[geco3]

We have a very dated legacy application written using CSLA 2.1.4.2 which has worked flawless for the last 15+ years. Winforms client and DataPortal hosted with on-prem IIS. A client has now moved the DataPortal and hosted as a WebApp on Azure. The application is functioning for the most part but an intermittent exception is raised from the DataPortal_Fetch which is causing frustration for the users:

Csla.Server.CallMethodException: DataPortal_Fetch method call failed ---> System.Runtime.Remoting.RemotingException: Object '/32fa6b22_38dc_4da6_b7b2_7dbfeaad2660/rgwcgwgteddcf5meujtlyx3e_3709.rem' has been disconnected or does not exist at the server.

Server stack trace:
   at System.Runtime.Remoting.Channels.ChannelServices.CheckDisconnectedOrCreateWellKnownObject(IMessage msg)
   at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage(IMessage msg)

Exception rethrown at [0]:
   at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyEntry.IntentionalRethrow(Exception chainException, Exception originalException)
   at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyEntry.RethrowRecommended(Exception chainException, Exception originalException)
   at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyEntry.Handle(Exception exceptionToHandle)
   at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyDefinition.HandleException(Exception exceptionToHandle)
   at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionManager.HandleException(Exception exceptionToHandle, String policyName)
   at YoungLight.ExceptionHandling.Handler.HandleException(Exception exception, String PolicyName)
   at YoungLight.Gcm2.Losses.ProductionDay.DataPortal_Fetch(Criteria criteria)
   --- End of inner exception stack trace ---
   at Csla.MethodCaller.CallMethod(Object obj, MethodInfo info, Object[] parameters)
   at Csla.Server.SimpleDataPortal.Fetch(Type objectType, Object criteria, DataPortalContext context)
   --- End of inner exception stack trace ---

The user will simply retry the fetch and it will work and everything is good again until the next time. I realize that CSLA 2.1.4.2 is ancient and .NET Remoting should no longer be used but as common with these legacy applications there are no resources or budgets for an upgrade.

A few of questions:

Is anyone aware of the cause of this issue?

Are there any fixes that can be applied?

What would be the minimal amount of effort to upgrade the CSLA version to get away from .NET Remoting? It's a fairly large application - 8 main screens, 120+ forms, 50 reports all backed with CSLA objects.

Any help would be greatly appreciated.

[rockfordlhotka]

That's a challenging issue given the age of the technologies involved. I think you'd need to get to CSLA 3.8 (?) to use WCF or asmx instead of Remoting. The problem is that WCF and asmx are also effectively obsolete, so it may or may not be worth the effort.

The ideal solution would be to switch to modern CSLA and .NET 8, but you note budget constraints, and such a move wouldn't be trivial.

You might consider a low-tech solution, which would be to add code on the client, where you call the data portal. Add a try..catch block and do a retry behind the scenes so the user doesn't see the failure - at least if it only occurs once or something. I'd suggest using something like Polly to do this, but you probably can't use modern NuGet packages either (I'm guessing), so you'll have to write your own retry code instead.

[geco3]

Thanks Rocky.
We really wish we could upgrade the application to modern CSLA. Our recent new development is with CSLA 9.1 + Blazor which is an amazing combination to work with.
That's a good shout to go for Polly and/or custom retry code.

[jonnybee]

There's a couple of things to check/keep in mind:

1. Make sure that AlwaysOn is checked on the webapp. If not the WebApp may be stopped after some inactivity and the next call will be a cold start that may take a few seconds.

2. If the app rely on on long running connection - idle connections will be forcibly closed after 4 minutes in Azure. This will include that when a call takes more than 4 minutes to execute in the appservice then the connection is forcibly closed.

You should be able to use Polly for retries but might not be that straight forward - or create your own retry code as Rocky said.

[geco3]

Thanks Jonny.

1. AlwaysOn is checked.
2. No long running connections - max would be around 20-30 seconds.