Noticed that my Smartermail IIS logs had been getting huge these days so went to investigate.
It seems to be something to do with the Bandwidth Counting Scheduled task getting stuck in an infinite loop.
When I run it, the SCP Server keeps hitting the url “/services/svcDomainAdmin.asmx” continuously over and over (we’re talking 3gb a day of logs just showing that!)
Sm 15.7 (not yet upgraded to 16)
We make the GetDomainStatistics API Call to Smartermail with the startdate and EndDate.
Would you be able to make the API call for us against your Smartermail server to see what happens if the start date is blank?
6 minutes is for the bandwidth to be collected on all hosting spaces (As a test server it has alot of different spaces and providers). If this acts as you explain i would expect it to have a large different between the first and second time it is ran as the second time the BandwidthUpdated has a value.
The start date (in the $POST SOAP value call to Smartermail svcDomainAdmin.asmx) isn’t blank, it’s 0000-00-01 and then increments over and over.
Sadly I have deleted all the traces now or I could send them to you to see.
The question is – if the bandwidth collection on an email only package hasn’t been run before, which date do you send as the StartDate?
Ok i see what you mean that there is a loop that looks at the date starting with 1/1/0001 and then increases this value by 1 day before doing the API call again.
It looks like alot of the providers do the same but they are generally checking files and not making an API call.
I think the easy solution for all is that when the package is added we set a BandwidthUpdated value. The question is should we make this date the day the package is created or something more generic like a year before to cover any imported packages?
Could it not do both? If it’s a new account set the date as today (or yesterday?) but on an import, like you said, maybe put it a year back (I think that would cover most users!)
It is still inserting NULL value for the new hosting package and causing this issue. Can you include this in next update? As mentioned by Ben, we can set the same date as package creation date to avoid this.
We have released v1.4.6 which does fix this issue. When a new plan is created it will mark the date back 1 year which should prevent the issue.
- Views8787 times
- Answers27 answers