Keith Stevenson

Dan Thanks for the response. There is no standard for HTTP access to email, it just presents their own Web client. The only way to access and download email is via POP3(s)\IMAP(s) Kind Regards Keith Stevenson

Dan, Thanks for the post. Our requirements for POP3 are very simple. A route from our external IP (Listed here - https://wiki.hornbill.com/index.php?title=Hornbill_Cloud_and_Platform) to the mail Server on the given port. From the above that appears to be blocked either on your corporate firewall, on the mail servers firewall or in your mail server configuration itself. You should be able to test this, my telnet to your mail server on specified port, working out from the mail server, to LAN, to WAN to see where it stops working. Kind Regards Keith stevenson

Chris, Thanks for the post. We can inform you that no changes were made and we didnt see anything on any instance or infrastruture that would have suggested a problem. If it occurs again can you raise this via https://www.hornbill.com/support as on login it will fire a number of tests between you (or your browser) and the instance that will show where any problem may reside. Kind Regards Keith Stevenson

Stephen We can confirm that Hornbill does not require or use Flash. Kind Regards Keith stevenson

David, Thanks for the post. Can you confirm that this is now functioning. Kind Regards Keith Stevenson

Micheal, Can you confirm that this is no longer an issue. There was a new version of the front end this morning, but we have since rolled back. Kind Regards Keith Stevenson

Andy, Thanks for the post. Seems to have been missed. WIll poll internally and get something ASAP. Kind Regards Keith Stevenson

All, There appears (as reported by a number of customers) some routing issues within the UK. The problem is not with our services\data centers or applications. We did see a small network issue about 1400-1430 in which 1 our of 24 remote checks (from locations around the world) failed but nothing in the last hour and all other monitoring shows no issue. If you are experiecing issues we would request that, as above, you perform the service check (to see where the issue resides) and list your ISP as this may help others with the same problem. The below (Apart from being quite nice to look at) shows a number of remote monitors (Each dot it a check) and there responses. Kind Regards Keith Stevenson

Andrew, If you view the sent item, next to the mail address their is a little envelope item. Clicking this will show the Message delivery log and the reason for failure. Kind Regards Keith Stevenson

@Stephen Christopher Given it was OK yesterday (After the ESP release) but had issues this morning (After the Service Manager release) I wonder if something has changed in Flowcode. If you can DM me the script I can drop it on a test box and see if we can replicate. Kind Regards

@Jeremy Strange I could still see plenty of activity (it had risen but was still OK).. Now restarted Kind Regards

@Stephen Christopher Its also started again at 11:16 The times that its fired are 08:42, 09:12, 09:42, 10:12 , 11:12 ( This looks like something scheduled every 30 mins) Kind Regards

@Stephen Christopher I will have to have a look at yesterdays logs. As for this mornings it started at 07:42:12z and the offending check seems to be on h_name = 'image_1.png' and then increments the image check by 1 each time for the call reference IN01007239. It does this close to 160K times in 1 hour (seems to loop ) before the server just starts using more and more RAM and slowing down. Will need to check if its the same offending callref in the next 2 occurences (after the restarts) but this may give you something to look at Kind Regards Keith Stevenson

@Stephen Christopher At the moment it appears to have calmed down and we will continue to monitor. Im working back through the logs to see what the first occuruence of the API spam was but it created so much noise that cant see wood for trees. Kind Regards Keith Stevenson

@Jeremy What is the SD Auto Bot account used for? What scripts does it fire. Also your instance has just got to the critical point so will just have to give it a restart. This will take about 1 minute. Kind Regards Keith Stevenson

Andrew, As Mentioned above, we saw no issues yesterday that would have impacted your instance. Inorder to identify any issues we would require a copy of the Ping Check (available when you raise a call from within our portal) to see where the problem resides. Kind Regards Keith Stevenson

@Jeremy Seems to have started again in last 2 mins. This will continue to cause slowness and then eventually tie up the Instance KInd Regards Keith Stevenson

David, We saw no issues yesterday and the above effected instance was under no load. The issues on your instance this monring appears to be caused by an account on your instance (SD AUTO BOT). The two issues are unrelated. Kind Regards Keith Stevenson

Dear @Jeremy This appears to be caused by 1 of your Accounts (SD AUTO BOT) running a given API (entityAttachDoesExist) and cycling through all file attachments . Its calling this 100s of times a second. Not sure why or what you are trying to achieve but stopping this would solve your issue Kind Regards Keith Stevenson

@Martyn Houghton Just an update to say we are still working on this, and will hopefully have a confirmed date within before the end of this month. Kind Regards Keith Stevenson

All, Thanks for the posts. The above suggests a timeout on connecting to MS servers. MS did report outages impacting all their services on 2 days last week and it would them you need to contact to understand what the issue was. Kind Regards Keith Stevenson

@Alberto M Thanks for the reply. From looking at your instance you logged nearly double your typical number of requests\tasks and these came in groups and mostly before 1PM. We provision the instances for double the typical number of APIs requests for any instance in 1 day, however if you perform this in short timeperiods this can cause short delays in processing. Going forward we will be able to change the provisioning of instance resources over a shorter time frame to solve this (Currently takes upto 12 hours) Its also worth noting that logging 1 call\task may be only 1 API request from the user, but the knock on from that can be many 100s (API call ,so a burst of 9 times your typical load in short time can cause the issue you witnessed. We can see that performance and load returned to expected at around 1PM and remained as expected for the rest of the day. Kind Regards Keith Stevenson

Alberto, Thanks for the post. We have witnessed 400% increase in the number of APIs calls to your instance today. This is causing your issues. Have you made any changes that would account for an increase? Kind regards Keith Stevenson

@Martyn Houghton Thanks for the reply. Most of the work is already done as we already provide OAuth authentication in KeySafe (which is where you will store the new credentials) and this is just exposing that in the Mail Connector configuration. We dont have a firm date, however I will post back next week to confirm when we can expect this. Kind Regards Keith Stevenson

@davidrb84 No there were no issues yesterday and no unexpected load (Mondays issue was due to migration to new SQL servers and the root cause identiifed and resolved by Monday afternoon) and all our monitoring showed no issues. Were you able to obtain a copy of the System Ping check so we can see where any problem may reside. Kind Regards Keith Stevenson