L
Laura Stern
Guest
Regarding reporting this to tech support, you really don't need to provide a reproducible to tech support in order to improve the error message. As I said, there is already a bug and we also have a fairly high-priority "feature" to improve some of our error messages in order to avoid tech support calls. This fits right into that category! So the call to TS would really be to argue for increasing the priority. But of course, if you did have a way to reproduce, that would be very helpful in diagnosing your actual problem! In regards to trying to synchronize things on your own, I thing you are going down a difficult and dangerous path! I would not recommend it. I will reiterate: the CLR Bridge really does not share any data between the session threads. There is a separate AssemblyStore for each thread and as far as we know, anything that stores data has its own instance for each thread. The shared AppDomain should not affect anything. We do not interact with it/modify anything in it. Regarding the load factor: The error that started this whole discussion (Error loading the .NET runtime. (14081)) happens when we first need to initialize the CLR Bridge and that happens on the first call to anything in .NET. Are you surmising that it could fail when one session is first initializing the Bridge and another one has already initialized but is now trying to make some .NET call? I really can't comment on that. I can't offhand see why this would be a problem. But I can't say with any certainty that it isn't related. Have you tried using -preloadCLR? Maybe that would help. That will cause the initialization to occur when the session starts up.
Continue reading...
Continue reading...