Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Send/Receive errors
Is there any way of retrieving any information relating to any send/receive errors other than just the number?
I had an instance yesterday where the receive error count was just incrementing continuously.
The server also displayed that I had two connections when really I only had one.
I think at one point I had to kill off my OI session via the task manager so I assume this prevented the directconnect control from disconnecting gracefully. I'm also assuming that this was then the cause of the thousands of errors being that the syncserver was expecting to receive something from a connection it thought it had but didn't.
So I can make assumptions and that's alright because this was just my local dev environment but it just started me wondering about what if, in user land....
I had an instance yesterday where the receive error count was just incrementing continuously.
The server also displayed that I had two connections when really I only had one.
I think at one point I had to kill off my OI session via the task manager so I assume this prevented the directconnect control from disconnecting gracefully. I'm also assuming that this was then the cause of the thousands of errors being that the syncserver was expecting to receive something from a connection it thought it had but didn't.
So I can make assumptions and that's alright because this was just my local dev environment but it just started me wondering about what if, in user land....
Comments
I'll let Kevin reply with a more definitive response, but I suspect the answer is "no". Errors are usually just an indicator of success/no-success and we simply do not know why. Can you confirm the version of the SRP Sync Server you are using?
Haven't got it in front of me but I downloaded it about a week ago.
I asked because we did experience problems with the counter increasing on the SRP Sync Server very rapidly but these were basically false positives. I thought these were addressed in the most recent version.
The Receive Errors count is just incrementing constantly and is fact right now as I type up to 34512.
No 34654
No. 34728
No.... I suspect you get the picture.
A quick whip around the office determines that while the "Connections" says 10, there are actually only 9 versions of the app running and connected so i would assume again that's why the receive errors are occurring.
I did have a connected app crash ( a problem for another time) so the incorrect connection count is also not so much of a mystery.
My real concern is, when this happens, is there likely to be a point at which the syncserver gives up or the other connected apps perhaps suffer in some form? Is it ok to allow everyone to continue functioning or do I need to kick everyone out in order to restart the syncserver?
I understand I can restart the syncserver without kicking everybody out but they will then lose their connection and as such, having it running is then of no real value.
As alarming as the ever increasing numbers appear it is okay to keep running. This is one of the reasons that the newer GUI for the SRP Sync Server completely hides the Receive/Send errors. However, being able to see them does help pinpoint problem code. The cause for the errors is, as you surmised, due to the crash and an orphaned connection.
The ServerValid property was designed so you can do a safety check. This could be put at the top of any routine or in an insert. Then if the check fails you can attempt to set the Server property before moving on.
I will utilise that little tidbit and it should cover off most scenarios.
The ServerValid property is not working for me in preventing issues.
Last Wednesday and again today, the syncserver reached a point whereby the application just came to a halt.
It occurred while checking the 'ServerValid' property. There may have been an instance of the same when setting the 'Server' property as well. Not 100% on that one.
In both cases, the error count was extreme; 102,249,244 last week and 69,102,637 today.
A closing and restarting of the syncserver resolved the problem both times.
As I don't yet know what is causing the errors, I was hoping a means of retrieving the error count may exist.
That way I could possibly set an arbitrary number whereby if the count exceeds that, I can programattically close the syncserver and re-start it.
Perhaps not the most elegant but better than having users not being able to log in.
As always, am open to any other suggestions.