Eric Wikman, one of Epicom’s engineers, forwarded me this email from SugarCRM support recently. Turns out that the servers we use in our SugarCRM Performance Hosting Platform are just too fast! They exploited a weakness in the SugarCRM software that had to be fixed in a new release.
Does this mean we’ll have to get slower servers????? 
Here’s the text of the email we received from our SugarCRM support engineer, Chris Raffle:
Chris Raffle has created a new Note:
Case Number: 50768
Case Name: Inconsistant and wrong subordinates list
Subject: Bug # 25864
Note: Hi Eric,
I attached your case to closed bug # 25864 (http://bugs.sugarcrm.com/?bug_number=25864). This bug is resolved in our 5.5 release. Prior to that release, the bug was most prevalent on powerful servers running Linux. In the file:
./include/ytree/Node.php
Around line 57, was the following code:
$this->uid=microtime();
The issue with microtime is that on powerful, fast servers, multiple items could have the same value thus only showing a small section of the records that should be shown in the record trees as seen in Studio, Forecasts, Product Catalog, etc.
In 5.5, we changed the code to:
$this->uid = create_guid();
This ensures that each element has it's own unique identifier and will be shown in the tree.
I am closing this case but if you have any additional questions regarding this issue, please post a follow up note.
Kind regards,
Chris
One Response to Epicom’s Performance Hosting Platform Is Too Fast!!!
Post Comment
Find Us Elsewhere
Bill,
I suppose they were trying to get a unique number using the microtime(); function. Am not sure but I think microtime(); returned a number based on seconds/milliseconds. As the servers are too fast, the microtime(); method failed to return a unique number in the next immediate call to the method.
They replaced it with create_guid(); function which returns a GUID.
The term GUID usually, but not always, refers to Microsoft’s implementation of the Universally Unique Identifier (UUID) standard. The primary purpose of the GUID is to have a totally unique number. Ideally, a GUID will never be generated twice by any computer or group of computers in existence. The total number of unique keys (2128 or 3.4×1038) is so large that the probability of the same number being generated twice is extremely small, and certain techniques have been developed to help ensure that numbers are not duplicated.
In other words changing the function doesn’t mean you will get slower servers
Regards,
DP