InvalidOperationException from RegisterProperty during cctor

[ajohnstone-ks]

A few of our releases ago, we updated from Csla 4.11.2 to Csla 5.3.1. After that, we have intermittently gotten errors thrown from RegisterProperty, called by the static ctor the type. When this happens, that business object is no longer usable, and we have to restart the app pool. The issue seems to happen at times when the app pool for the remote data portal host is recycled.

I think it's some kind of race condition, introduced between those two versions of Csla. I'm hoping perhaps that moving to Csla 5.4 will alleviate it, but I wanted to ask here in case this wasn't a known issue.

Here's a sample stack trace:

Csla.DataPortalException: DataPortal.Fetch failed (BusinessObjectInfo.Child_Fetch method call failed) ---> Csla.Reflection.CallMethodException: BusinessObjectList.DataPortal_Fetch method call failed ---> Csla.Reflection.CallMethodException: BusinessObjectInfo.Child_Fetch method call failed ---> System.InvalidOperationException: Cannot register property DeviceType after containing type (BusinessObjectInfo) has been instantiated
at Csla.Core.FieldManager.PropertyInfoManager.RegisterProperty[T](Type objectType, PropertyInfo1 info) at BusinessRules.BusinessObjects.BusinessObjectInfo..cctor() in C:\BuildAgent\work\55c630171023f9ba\businessrules\BusinessObjects\BusinessObjectInfo.cs:line 23 --- End of inner exception stack trace --- at Csla.Reflection.ServiceProviderMethodCaller.<CallMethodTryAsync>d__11.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Csla.Reflection.LateBoundObject.<CallMethodTryAsyncDI>d__121.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Server.DataPortalTarget.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Server.ChildDataPortal.d__9.MoveNext()
--- End of inner exception stack trace ---
at Csla.Reflection.ServiceProviderMethodCaller.d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Reflection.LateBoundObject.d__121.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Csla.Server.DataPortalTarget.<InvokeOperationAsync>d__141.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Server.DataPortalTarget.d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Server.SimpleDataPortal.d__1.MoveNext()
--- End of inner exception stack trace ---
at Csla.DataPortal1.Fetch(Type objectType, Object criteria) at Csla.DataPortal1.Fetch(Object[] criteria)

[rockfordlhotka]

This is not a known issue, so I doubt going to 5.4.0 will matter.

[ajohnstone-ks]

@rockfordlhotka Do you have any objection if a bug is created for this? I'm pretty certain there's some kind of race condition in Csla, as resetting IIS fixes it without any other code or configuration changes. We're trying to see if we can find where it might be happening and will report back when/if we find something.

[rockfordlhotka]

Yes, please do. It would be ideal to have a repro, though that's hard with concurrency issues I know.

[coder-rr]

As far as I can tell this is the only thing that changed in this area of code.

#1498 Ensure static fields are initialized once property list is created (version 5.2.0)

We started to get the error after we updated from version 4.11.2 -> 5.3.1

[ajohnstone-ks]

@rockfordlhotka Thanks, I created this issue: #2022

[ajohnstone-ks]

@coder-rr Can you check this and see if you think it will fix our issue?

[coder-rr]

Looks good to me.

…

On Tue, Jan 19, 2021 at 8:18 AM ajohnstone-ks ***@***.***> wrote: @coder-rr <https://github.com/coder-rr> Can you check this <#2051> and see if you think it will fix our issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1998 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWVTICKIJEHLZH3TIFMIJ3S2WICDANCNFSM4VES7JSQ> .

[rockfordlhotka]

@ajohnstone-ks and @coder-rr - I just pushed a prerelease of 5.4.1 to nuget. It includes the change from #2022, and so hopefully addresses your issue.

Can you test please?