7

In my Azure web role code I have a CustomIdentity class derived from System.Security.Principal.IIdentity. At some point .NET runtime tries to serialize that class and serialization wouldn't work. Trying to resolve that I searched a lot and found this answer and tried to inherit my class from MarshalByRefObject.

Now once my CustomIdentity class inherits from MarshalByRefObject there're no serialization attempts anymore and my code works. However I'd like to know the performance implications of using MarshalByRefObject class.

My code runs like this. First the request comes to IIS and is passed to the authentication code that creates an instance of CustomIdentity and attaches that instance to HTTP context. Then some time later the same HTTP context is passed to the ASP.NET handler that accesses that CustomIdentity instance at most once. The CustomIdentity object lives for the duration of request and is then destroyed.

Now with serialization my CustomIdentity would be serialized into a stream, then deserialized from that stream into a new object. With MarshalByRefObject there's no serialization but a proxy is created and the access will be marshaled via RPC to where the actual object resides.

How expensive will using MarshalByRefObject be in this scenario? Which - MarshalByRefObject or serialization - will be more costly?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979

1 Answers1

10

MarshalByRefObject means that all calls (methods, properties, etc) are proxied over the wire. This potentially means that instead of transferring the data once and then running multiple methods etc locally on the transferred data, you are making a network call every access. How many times (per request) is a role tested, for example? or the name queried? I honestly don't know, but I'm guessing it is more than 1 (all totalled). Plus the original setup costs...

The bandwidth probably won't be significant, but latency is very significant, especially if you have distributed nodes (since you mention a cloud scenario).

Personally, I would avoid MarshalByRefObject like the plague, but up to you...

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • As a side note - in my scenario the "creator" code and the "consumer" code are always on the same machine and maybe even in the same process. It's not that one node runs the "creator" code and another one runs the "consumer" code. – sharptooth Jun 28 '11 at 08:07
  • I guess I'll have to profile that code and make a careful decision. – sharptooth Jun 28 '11 at 08:09
  • @sharptooth - are they in different AppDomains, then? if not... just *why*? – Marc Gravell Jun 28 '11 at 08:17
  • 1
    @sharptooth I would focus my attention on *why does it want to serialize*, etc – Marc Gravell Jun 28 '11 at 08:19
  • Well, looks like the "creator" code is run when request is not yet authenticated and so is untrusted and the "consumer" code is run when the request is already authenticated and so is trusted and so they run in different app domains. The problem is my knowledge of app domains is very limited, so I'd rather address it sometimes later and for now I just patched the problem and am curious of how costly the patch is. – sharptooth Jun 28 '11 at 08:27
  • @sharptooth in the context of an in-process marshal, it probably isn't *too* terrible - but would need profiling. – Marc Gravell Jun 28 '11 at 08:31