This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, Using the nightly build from 20090905 we are seeing some serious errors being triggered from inside LightSpeed. They happen intermittently, usually more regularly once a few thousand web requests have already been served by our 32bit server. I've been unable to reproduce the problem on a 64bit machine (although this may simply be because it is a faster machine than the 32bit one). The operating system and configuration is the same across both our 32 bit and 64 bit machines (CentOS 5 with latest updates, Mono 2.4.2.3). We need to deploy into production on the 32bit machines which are experiencing the error. Whether the MySQL 5.1 database sits on a 32bit or 64bit machine doesn't appear to make a difference. There appears to be a pattern in which part of LightSpeed code the exception occurs and initial investigation indicates that the problem occurs when enumerated values are involved somewhere in the queries. Two example stack traces are below. System.OverflowException: Number overflow. System.OverflowException: Number overflow. AccessionsChapter and SpeciesTextType are just simple enums. E.g. public enum SpeciesTextType and defined in the model like this: partial class SpeciesTextItem Defining them as in32, int16 or byte in the designer doesn't seem to make any difference. The designer is set to not generate the code automatically. A quick solution would be fantastic (obviously :-) ) but even just some indication of what we may have done wrong in our application to cause this would give us a useful place to start. Thanks, Chris |
|
|
|
|
As a workaround, could you try changing this line: get { return Get(ref _type); } to this: get { return _type; } The Get() call is required only for fields which may be lazy-loaded. By omitting the Get, you should avoid the call to GetInferredFieldName which is where the problem seems to be occurring. Obviously you will need to do this for all properties that are causing the issue. If any of these properties are lazy-loaded (unlikely for enums I know) then use Get(ref _type, "Type") -- specifying the field name explicitly also bypasses GetInferredFieldName while preserving lazy-load support. My suspicion is that this may be an interaction between the ActiveSharp library and Mono. ActiveSharp does some deep voodoo to figure out how fields map to properties, and subtle differences between Mono and the Microsoft CLR might be what is giving it grief. We will investigate further but hopefully the above fix will sort out the immediate problem. |
|
|
|
|
Hi Ivan, Thanks for the quick response as usual! I have implemented the workaround you suggest and after sending five times as many page requests as before, we've still not seen the exception message so it looks hopeful that this will allow us to press ahead with the deployment onto our production servers. I share your suspicions about ActiveSharp but can't find much in the way of documentation or support and it doesn't look that actively developed. Just so we can better understand the risks with our new website running on mono, can you breifly explain when and why you use this library? I.e. is it just to enable support for enumerations or for lazy loading? Could there be other parts of our code that are using this library by proxy through LightSpeed? Might there be an opportunity for future versions of LightSpeed to utilise a newer version of the ActiveSharp library or an alternative library or is that too much work? Thanks, Chris
|
|
|
|
|
The main reason for using ActiveSharp is to avoid magic strings in non-designer scenarios. It allows users to write: Set(ref _myProperty, value); instead of Set(ref _myPropety, value, "MyProperty"); so that if they rename MyProperty they don't need also to update the magic string. (The name is needed for the PropertyChanged event.) I am not 100% sure of the role of ActiveSharp in getters -- I believe it is used to locate the field metadata so that we can mark the lazy field as loaded but I'm not very familiar with that part of the code. I can investigate further if required. Now, in modern C# the magic string could be replaced with a lambda expression. However, another motivation of the original design was to minimise the amount of typing you had to do, so we would probably still want to retain the auto-infer overload. "Could there be other parts of our code that are using this library through LightSpeed?" LightSpeed calls ActiveSharp from certain overloads of the Entity.Get and Entity.Set methods. Any part of your code that is not getting or setting entity properties will not invoke ActiveSharp. If you always pass a property name to Get or Set, you will never invoke ActiveSharp. |
|
|
|
