Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
1107 errors. "The session ID XX is no ...." |
Tue, Nov 15 2022 4:23 PM | Permanent Link |
Ian Branch | Hi Team,
I am in dialog with Tim but I was wondering what others may have experienced/resolved. Every now and then the EDBServer Log shows a 'flood' of these errors that go on for multiple minutes. Up to 30 minutes once. They happen every 30 seconds. At Tim's suggestion I have checked all the Timers in the Apps and none of them are set at 30secs, 30000mS. The Customer is in Fiji so fault finding is a bit tricky. They run a LAN with multiple Usrrs, plus RDP Users, plus ThinFinity Users which are effectively RDP type Users. So, has anybody else come across this and found some other indirect cause for these errors? I am open to any suggestions att. Regards & TIA, Ian |
Tue, Nov 15 2022 5:00 PM | Permanent Link |
Terry Swiers | > They happen every 30 seconds. The default remote ping interval is 30 seconds. If the server engine gets restarted or is unavailable for a period of time, you will see one of these for each and every client connection that was active until the session is closed or reconnected on the client side. |
Tue, Nov 15 2022 5:59 PM | Permanent Link |
Ian Branch | Hi Terry,
Fair enough but this was just one session. Ian |
Wed, Nov 16 2022 3:24 AM | Permanent Link |
Teco TECHNOLOG Systems GmbH | Last time I have seen such a behavior it was caused by a faulty network switch.
|
Wed, Nov 16 2022 1:41 PM | Permanent Link |
Terry Swiers | > Fair enough but this was just one session. With the use of "flood" in the description of the problem, I assumed that this was a server restart and you seeing a huge number of these. With it being just a single session, that just shifts where the disconnect was to the client side. This isn't a problem with EDB, but just a side effect of how the remote ping works as it simply sends a request to the server to let it know that it's still there. It doesn't wait for a response and doesn't have any error handling in it so it happily keeps pumping those signals to the server until the session gets closed. What we do in our app is to create a scheduled background thread that runs approximately every 5 minutes and does a server time query via the connected session synchronized through the main UI thread. If that fails and indicates that the session is no longer available, we disconnect and reconnect the session. Any open tables will be closed and fail, but our primary functions use insert and update queries so it doesn't matter if the connection is on a new session ID. |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |